"2actionscript" Posts

Tip of the Day – Tricks of the microphone settings panel

I have an extensive background using the Microphone class within Flash Player. Anytime you try to connect to a user’s microphone, Flash Player displays a privacy dialog box that alerts the user to choose whether to allow or deny access to the microphone.

I’m sure you’ve seen it, this is what it looks like:
micpermission

You widget (or app) MUST be a minimum of 216 x 138 (some people will argue you can do 215 wide, but in my testing sometimes 215 pixels wide can cause issues). When the player window is too small, the settings panel will either:

  1. Not show up at all, or
  2. Show up clipped and in some browsers mouse events will not register in Flash

You cannot disable the settings panel.

Here are a few helpful tips that I have figured out:

  • The widget needs to be 216 x 138 ONLY when you’re asking for permission to the microphone. If you have control of Javascript on the page, you can change the size of the flash object on the page temporarily while you show the settings panel.
  • You can use “Security.showSettings(SecurityPanel.PRIVACY);” to control when you want the settings panel to show up. Using the Security.showSettings method is helpful because there is a Remember button on that panel. If the user chooses “Remember”, then you never have to show the Settings panel again.
  • micsettings

  • The Microphone status events get dispatched when a user changes a Microphone setting within the settings panel. ( _mic.addEventListener(StatusEvent.STATUS, onMicStatus); )
  • On your Microphone class, the “muted” property will tell you if you have access to the microphone or not.

These tips can be adapted for the camera settings panel as well.

Tip of the Day – When to use include

A little while ago I posed the following question to the flexcoders mailing list,

I just wanted to ping everyone and get their opinion on something. Why would anyone ever want to use the include directive? I’ve recently been working on poorly designed project where at the top of every module there is an “include Header.as” statement that has 30 include statements within it. To give a datagrid additional functionality, you give it an id=”myDataGrid”, and the include statement takes care of the rest. It’s really bad.

I just don’t see a good use for the include statement anymore. In my opinion, it just promotes bad programming practices.

I mean, can’t everything be taken care of using OOP methodologies? Thoughts?

I’d like to thank everyone who responded, you all gave me quite a bit of insight.

After thinking about this for a while now, here is my list of the common reasons people incorrectly use include (include directive).

I have common functionality that I want shared across multiple components.

That’s great that you’re using DRY philosophy! However, it’s much better to combine the DRY philosophy with object-oriented programming practices. Instead of using the include directive, abstract out common functionality into a parent class. Then you can create children of your parent component, and add additional functionality as needed.

I’m building a framework.

Great… don’t use include. See above reason.

I want to use Code-Behind.

Ted Patrick wrote a wonderful post on Code-Behind in Flex 2. He accomplishes Code-Behind, and does so in an object-oriented manner without using include statements.

Adobe doesn’t natively allow multiple inheritance in AS3, and using the include directive is the only way to fake it.

Frankly, if you understand that statement… you’re advanced enough to know what you’re doing, and you don’t need this tip.

== Conclusion ==

There are rare occasions where include is exactly what you need. However, if you still feel you have a valid reason to use the include directive on a regular basis, please leave a comment below and explain yourself.

Tip of the Day – When to use try… catch… finally

A wise Adobean once told me to use try / catch / finally statements sparingly. It didn’t mean much to me at the time since I honestly don’t use them very often. Instead, I opt to check conditions prior to executing “at risk” statements.

So… here’s my advice that when it comes to try / catch statements.

Preventing errors from occurring is far better than generally handling them.

Take a look at this example.

var goodObj:Object = {foo: "bar"};
var badObj:Object = null;
 
tryErrors(goodObj);
tryErrors(badObj);
 
function tryErrors(obj:Object):void {
 
	// DO THIS
	if(obj)
		trace(obj.foo);
	else
		trace("doing something else");
 
	// NOT THIS
	try {
		trace(obj.foo);
	} catch (e:TypeError) {
		trace("error occurred");
	}
 
}
 
/*** OUTPUT ***************
bar
bar
doing something else
error occurred
***************************/

Do not use blanket try / catch statements.

You gain nothing by catching an exception that your application can’t deal with at that point.
For example, if you’re trying to convert a string to a number, and you know it might fail, but you have a default value, you should catch the exception, set the default value, and allow execution to continue.

Another example, if you try to call a Web Service and the call fails, and that particular call isn’t critical to your application, you could catch the exception, warn the user that some information is not available, and continue execution.

Only use try / catch when you have to.

I don’t have any specific benchmarks, but I do know that using excessive try/catch statements will degrade performance of your flash application. Probably because Flash Player is single threaded, but an Adobe person would probably have more information on that than I do.

An application I worked on a while ago used a try catch block around every single function… not my fault, it’s code that I inherited… anyways, it’s performance and execution times were horrendous.

Tour de Flex… It’s no rubygems, but it’s a start.

Mike Chambers has a blog post asking, “How can adobe make the as3 learning curve easier”?

As I talked about in my Why YOU should contribute to Flex post, Adobe wants our input. Here they are again asking the community, “What do you think”?

I commented on Mike’s post.

I think that a more centralized component library and delivery system would make the lives of many developers much easier.

Take RubyGems for example. It’s extremely easy for developers to benefit from the work of others. This has increased the value of Ruby in my eyes tenfold.

As a developer, there isn’t a uniform place that I can go check to see if someone has done this before. So I have to scour the net for a while trying to find a solution by looking through blogs, articles, googlecode, etc…

I know there are a few places out there that make this easier. RIAForge, Adobe Developer Connection, Project Sprouts, Adobe TV, flexcoders.

Most of these sites (blogs especially), have a way to externally interact with them. I think that an Adobe sponsored site or program that would allow a developer to quickly see what’s out there would be an amazing asset to brand new ActionScript developer and veterans alike.

However, I didn’t realize until now, that Adobe is already doing this. This dream “site or program” does exist as the Tour de Flex. Which if you haven’t installed yet, I highly recommend it.

As the title of this post says, it’s no rubygems (not yet anyways)… but it’s a start. Go Adobe!