The challenge in learning a new language is that you don’t know what you don’t know. Very often when I look at older code I’ve written I realize that there’s a far better way of solving the problem, I just wasn’t aware of it at the time.
The purpose of this post is to cover a bunch of random things about Flex that I’ve learned along the way. For many of you I’m sure this list will be more of a review, but if you’re new to Flex hopefully you’ll find something which you didn’t know you were looking for.
mx_internal
Essentially, it’s a namespace (similar to public, private, protected and internal) used by the framework to protect code.
Some properties and methods in the framework need to be accessible from other places while still being hidden from the casual user. Using ‘protected’ would require that the class is a subclass, and ‘internal’ requires that it’s in the same package. This way any class can access a ‘hidden’ property or method of another class.
While this can be used to hack the framework, in general using the mx_internal namespace to access hidden properties should be avoided as it’s very easy to cause unexpected side effects (the property/method is probably hidden for a reason).
callLater()
Let me start by saying if using this function is fixing your problem but you’re not sure why you’re probably doing something else wrong. The callLater function is used to tell the Flash Player to call the function on the next frame.
Here’s a valid use of this function. If you set the dataProvider property of a list and then want to set an item as being selected you’d want to use the callLater. This gives the Flash Player a chance to setup the new dataProvider before you select your item.
So… why is this. When you set most properties the values aren’t actually set right away. The component will generally store the new value and mark that it’s been changed. It will then wait until the next validation to actually set the new value.
Using the callLater gives the component a chance to validate itself first. Because of this, you can often call validateNow instead of using a callLater but by doing so you’re forcing the class validate sooner than it’d like which could introduce performance issues.
This topic touches upon a key Flex idea, work with the framework not against it. The framework has a specific order in which things happen, the more familiar you are with how the framework operates the better off you’ll be.
initialize vs creationComplete
This topic is a good follow up to the last one. To really understand the difference you need to study up on the component lifecycle . In a nutshell initialize is called when the component’s children exist but aren’t yet measured/positioned, while creationComplete is called once the component has finished setting itself up.
The take away point here is you want to avoid placing code which will change the size/layout of a component’s children in the creationComplete handler. Doing so will force the Flash Player to size/layout the children a second time (which decreases the performance).
It’s good to be able to spot this issue by looking at how your application renders itself. Ideally, when the window is shown it should already be fully created but if you use creationComplete event handler on a slower machine you can visibly see the application resize its children.
masks
When I started to learn Flex I read all of the Flex books I could get my hands on, what I was missing however were the ActionScript books. Being an expert in Flex requires two sets of knowledge: the Flex Framework as well as a good understanding of ActionScript.
I obviously can’t cover all the cool things that you can do with ActionScript in this post but one item that I find handy is the mask property. This can be used to define a section of a component to be visible. Before I knew about masks I was adding white boxes to my applications to cover up the parts that I wanted to hide. Masks are a much more elegant solution to this problem.
suspendBackgroundProcessing
One of the greatest aspects of Flex is how easy it is to create really cool effects (as a side point, remember to use them where they make sense… every item on the screen doesn’t need to slide into place). The catch is sometimes the effects can get slowed down by other things happening in the background. I find that hurky-jurky effects can be somewhat painful to watch.
A possible solution is to set the suspendBackgroundProcessing property to true. This will tell the Flash Player to focus all of it’s resources on making the effect run smoothly. Another technique which I’ve found sometimes helps is to delay the effect slightly.
relatedObject
There are a number of different event types in Flex which each have their own special properties. It’s a good idea to glance at the full list to see what’s out there but here’s one property which I find particularly useful.
The FocusEvent class has a property called relatedObject which will tell you where the focus is going to/coming from. This can be really handy when creating focus event handlers.
ObjectUtil.toString()
Next to the trace function, this is the single most important function for debugging. This will dump an object to a string. While debugging I’ll very often write something like.
trace( ObjectUtil.toString( myVariable ) );
DefaultListEffect
This one’s just eye candy. Using this effect will cause the list to fade in/out items which are added or removed. When using this effect you need to remember to set variableRowHeight property on the List component to true.
That about wraps it up. Hopefully you learned something new while reading the post, or at the very least feel good about yourself because you were already familiar with everything mentioned here.
Best,
Hillel
Hillel Coren 