"8tip-of-the-day" Posts

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.

Tip of the Day – Tools of the freelancer

So I ran across this blog post this morning, brought to us by themikej. He discusses some tools he uses in his everyday life as a freelance contractor.

Everything he mentions in this post I personally use, and he sums it up well.

So for today’s tip, I recommend reading it.

Oh… and I stole my blog theme from him.

Tip of the Day – Using Fireworks to skin those Flex Applications

Today I was going to post about using flashvars and widget development. However, as I started to document the process, it became too much information for a single tip. So I’m going to do a separate post walking you through my widget development process. Now on to today’s tip!

To be honest with you guys, I’ve never really been a huge fan of Fireworks. I’m a Photoshop guy, and I have been since version 5.5 (hooray ImageReady). However, at our last SeaFlex meeting Marty gave a quick introduction into Flex skinning using Fireworks. My eyes were opened! So here is the basic run down of creating Flex skins using Fireworks CS4.

  1. Within Fireworks go to Commands > Flex Skinning > New Flex Skin
    fwskin_01
  2. Select the components you want to skin.
    fwskin_02
  3. Skin to your heart’s desire.
    fwskin_03
  4. When you’re finished, go to Commands > Flex Skinning > Export Flex Skin
    fwskin_04
  5. I created a new folder called testSkin and saved to that.
    fwskin_05
  6. Now in Flex Builder. File > Import > Skin Artwork
    fwskin_06
  7. Browse to the folder we just exported our assets to.
    fwskin_07
  8. Make sure the image to component mappings are correct.
    fwskin_08
  9. And…. you’re done.
    fwskin_09

Amazing.

:: UPDATE ::

Marty just posted a PC (and more in depth version) of the skinning your Flex applications with Fireworks. Read it here!

Tip of the Day – Widget personalization is important!

Some people call it skinning, others call it customization, for this post we’re going to call it personalization. Having sat in many focus groups… I’ve learned this following pearl of wisdom.

Adding personalization to your widget is incredibly important.

Social Network users spend HOURS customizing their profile to… express themselves. If your widget doesn’t “gel” with their Dwight Schrute bobble head photo, then it’s not going to work for them.

But… what is personalization?

Take a look at Snapvine’s VoicePlayer skins page.

Snap skins

You’ll notice that the widget here has many different flavors or “skins”.

Your widget doesn’t have to be as complex as the Snapvine widget, and frankly it shouldn’t be. One corner that you can easily back yourself into is by making your skins so customizable, that it makes it difficult to add new features or UI components.

Imagine if you will, a widget that allows users to move any button they want, anywhere they want. Then later on, you want to add 3 new buttons to the interface. You have to go back through all of your skins and make the changes to all of them. If you have over 100 different skins that are unique, you have to change and test all of them. Not fun.

When your go down the path of TOO MUCH customization, the widget quickly becomes far too complex, and a burden to maintain. So use KISS methodology when dealing with personalization.

Here are some easy ways to add personalization:

  • Allow an image path as a flashvar to be used as the background.
  • Point to different external CSS files.
  • Allow for colorization of components.
  • Custom information – Name, tagline, etc…

Tomorrow’s tip I will discuss how to use flashvars for customized widget information.