Ayone Blog

One of the biggest improvement in the new version of Flex SDK is the methodology by which you design and implement a component. If in Flex 3 you would probably mix skin mxml code with actionscript logic code, a Flex 4 component has 2 main parts: skin and model/controller. Each of these represent a different object managed by the component itself. The skin part contains mostly the mxml pieces defining the visual elements of the component while the model component handles all the logics and controlling. At the core of a component are the states, which were in Flex 3 also but are way better handled and improved in 4. When starting designing a component, it’s states need to be ruled out and logic that handles them. This is achieved on the actionscript side of code, declaring variables by which states are popped into the stage. Lets get this on one example. Suppose we need a contact form for customers to get feedback. Thinking of it’s functionality it’s clearly that it needs 3 states: default state where initial text is displayed, input state where client has controls for inserting code and final state where thank you and such message is displayed.
Let’s call this component ContactForm, the class definition would then look like this:

SkinState metadata specifies what states the skinnable component has, linking them with the states declared in the skin class that looks like this:

The next thing would be to declare in the model class all the logic-enabled controls. Logic enabled controls refer to controls that play a role in a component’s lifecycle, such as buttons that trigger state change, text control that offer text for submitting and so on. So lets go ahead and add the skin parts to our component:

Ok. Once we have all the visual elements defined it’s time to work on the logic part of it. Adding boolean properties for ruling out in what state the component should be is a good practice. For the contact form demo component we have only 2, isInput which should tell the component that currentSkinState should be input, and isFinal which reflects the final state where thank you message is displayed. So two new lines to the class:

The main skinning method that is overridden is “getCurrentSkinState” which gets called when skin state is invalidated thru “invalidateSkinState”. Basically this method returns the current skin based on the logic properties. Pretty straightforward:

Now skin parts need a little handling in terms of adding/removing event listeners and other data related computations. These are very handy when designing the component for memory optimization as you can remove event listeners and decouple the component from data area of an application (more on this here). Here they are:

And here are the event handlers that rule out the transitions between component states:

What happens under the hood is that when “invalidateSkinState()” gets called, framework will eventually call “getCurrentSkinState” and based on the state received it invalidates the skin and update based on that value.
These is pretty much it on the model class. It should look like this:

But wait there’s more. We still didn’t rule out the skin class. First thing to be added is the state declaration which links the states from the main class to skin class:

Nothing new here. The newly addition to the state management in Flex 4 is the state-related properties that enables one to set let’s say height for a skin depending on what state it is. Something like this:

Notice the two height declaration that are translated like this: height in “input” state should be 200 and 30 in any other state. All we need to do now is declaring the visual elements that forms the skin:

Note that actual skin parts declared in main class don’t have any property related to state management. Instead those are wrapped in Group components and those are state-enabled thru “includeIn” property. “includeIn” basically states that a visual element should be present only in that specific state (or state group, more on that in a future post). And this is the beauty of it, once the main class has defined the skin parts that it requires for a functional component, you can mix and play with the skin as much as you want.

That would be pretty much it. You can download the source code from here.

One of the most problematic and discussed area in Flex development is garbage collection and memory optimization. Even with new tools added to Flex Builder (now Flash Builder) like Profiling, struggling to obtain a memory clear application is not easy. One of the methods is the undocumented hack with LocalConnection
where you connect two of them and do nothing at all after.

This will trigger the internal garbage collection and clear everything that is decoupled from application.
But doing just this doesn’t mean your code will work as expected. The whole architecture needs to be ruled out with GC in mind and here is where the Flex 4 framework came in big help. Offering methods like partAdded() and partRemoved() to skinnable components is a path that assures every listener added to skin parts is removed in partRemoved(). This means if you show/hide some parts without removing the whole component from stage, all you need to do is call partRemoved() and partAdded() on the part you need to garbage collect. Make sure you call theese methods only if the part exists first as the first partAdded() is called from withing the component. This technique applies mostly to DataGroup where itemRenderers are used and bound with data that might have a longer lifespan than the renderer itself. Another critical time where some extra logic for memory should be added is when renderer is removed from stage, aka when “data” property is set to null. Here is where you might want to call detachSkin() to make sure all parts are decouples from the external resources and available for garbage collection.

Another handy method relates to images, components that are very problematic when comes to garbage collecting, where there is a new functionality inserted in Flash Player 10. SWFLoader has an unloadAndStop method that takes “invokeGarbageCollector” as a param which eventually result in calling “unloadAndStop” method available in Flash Player 10.

Working on a data intensive project in Flex 4 i’ve noticed that the framework better supports memory optimization that it did before so kudos for SDK guys. Will get back here with any interesting idea related to garbage collector in Flex 4 and where is the next critical place where you need to do extra work for it.

You might know the person who is writing here from the old blog at http://blogs.eyepartner.com/adrian or from the twitter page http://twitter.com/aadrian. Same as before, this blog will cover RIA seen from the Adobe’s area, using AIR/Flex 4/Catalyst along with topics of SpringActionscript, Cairngorm and BlazeDS. The newly addition is Andrei, who will cover the Java part, posting about SpringSource related projects, SpringDM server, LCDS, BlazeDS, Hibernate and such topics. Together we form the base start of Ayone, a software company focused on Rich Internet Applications, offering solutions and consultancy in this area. If you want to contact just drop us a line and we’ll get in touch in no time.
That should be it for the introductory post, stay tuned for articles and news about what we do and how we do it.