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:
1 2 3 4 5 | [SkinState( "normal" )] [SkinState( "input" )] [SkinState( "final" )] public class ContactForm extends SkinnableComponent |
SkinState metadata specifies what states the skinnable component has, linking them with the states declared in the skin class that looks like this:
1 2 3 4 5 | <s:states> <mx:State name="normal"/> <mx:State name="input"/> <mx:State name="final"/> </s:states> |
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:
1 2 3 4 5 6 7 8 | [SkinPart( required="true" )] public var openInputButton:Button; [SkinPart( required="true")] public var inputTextArea:TextArea; [SkinPart( required="true" )] public var submitButton:Button; |
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:
1 2 | private var isInput:Boolean; private var isFinal:Boolean; |
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:
1 2 3 4 5 6 7 8 | override protected function getCurrentSkinState():String { if( isFinal ) return "final"; else if( isInput ) return "input"; else return super.getCurrentSkinState(); } |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | override protected function partAdded( partName:String, instance:Object ):void { super.partAdded( partName, instance ); if( instance == openInputButton ) openInputButton.addEventListener( MouseEvent.CLICK, openInputButtonClickHandler ); else if( instance == submitButton ) submitButton.addEventListener( MouseEvent.CLICK, submitButtonClickHandler ); } override protected function partRemoved( partName:String, instance:Object ):void { super.partRemoved( partName, instance ); if( instance == openInputButton ) openInputButton.removeEventListener( MouseEvent.CLICK, openInputButtonClickHandler ); } |
And here are the event handlers that rule out the transitions between component states:
1 2 3 4 5 6 7 8 9 10 11 12 | private function openInputButtonClickHandler( e:MouseEvent ):void { isInput = true; invalidateSkinState(); } private function submitButtonClickHandler( e:MouseEvent ):void { isInput = false; isFinal = true; invalidateSkinState(); } |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | package com.ayone.examples.contactForm.ui { import flash.events.MouseEvent; import spark.components.Button; import spark.components.TextArea; import spark.components.supportClasses.SkinnableComponent; [SkinState( "normal" )] [SkinState( "input" )] [SkinState( "final" )] public class ContactForm extends SkinnableComponent { //------------------------------------------------------------ // // Properties // //------------------------------------------------------------ //------------------------------ // Skin Parts //------------------------------ [SkinPart( required="true" )] public var openInputButton:Button; [SkinPart( required="true")] public var inputTextArea:TextArea; [SkinPart( required="true" )] public var submitButton:Button; //------------------------------ // State Related Logic //------------------------------ private var isInput:Boolean; private var isFinal:Boolean; //------------------------------------------------------------ // // Methods // //------------------------------------------------------------ //------------------------------------------------------------ // Skinning //------------------------------------------------------------ override protected function getCurrentSkinState():String { if( isFinal ) return "final"; else if( isInput ) return "input"; else return super.getCurrentSkinState(); } override protected function partAdded( partName:String, instance:Object ):void { super.partAdded( partName, instance ); if( instance == openInputButton ) openInputButton.addEventListener( MouseEvent.CLICK, openInputButtonClickHandler ); else if( instance == submitButton ) submitButton.addEventListener( MouseEvent.CLICK, submitButtonClickHandler ); } override protected function partRemoved( partName:String, instance:Object ):void { super.partRemoved( partName, instance ); if( instance == openInputButton ) openInputButton.removeEventListener( MouseEvent.CLICK, openInputButtonClickHandler ); } //------------------------------------------------------------ // Event Handling //------------------------------------------------------------ private function openInputButtonClickHandler( e:MouseEvent ):void { isInput = true; invalidateSkinState(); } private function submitButtonClickHandler( e:MouseEvent ):void { isInput = false; isFinal = true; invalidateSkinState(); } } } |
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:
1 2 3 4 5 | <s:states> <mx:State name="normal"/> <mx:State name="input"/> <mx:State name="final"/> </s:states> |
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:
1 2 3 | <s:SparkSkin xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" width="400" height="30" height.input="200"> |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | <s:Group includeIn="normal" width="100%" height="100%"> <s:layout> <s:HorizontalLayout verticalAlign="middle"/> </s:layout> <s:SimpleText text="Click here to get in touch with us"/> <s:Button label="Contact" id="openInputButton"/> </s:Group> <s:Group includeIn="input" width="100%" height="100%"> <s:layout> <s:VerticalLayout horizontalAlign="right"/> </s:layout> <s:TextArea id="inputTextArea" width="100%"/> <s:Button id="submitButton" label="Send"/> </s:Group> <s:SimpleText includeIn="final" text="Thank you for contacting us"/> |
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.


7 Comments to 'Architecting a Flex 4 component'
June 29, 2009
Thanks for the interesting article.
One comment – I disagree with you on this point :
“Adding boolean properties for ruling out in what state the component should be is a good practice.”
Using this approach it’s possible (though not valid) for your component to have both inInput == true & isFinal == true.
Instead, I’d suggest that it’s the job of the getCurrentSkinState() method to calculate the current state (without the use of external booleans). If you did want to store the calculated value, you should use a single state var ( string / int ) and a set of constants to avoid multiple states being active.
You could always retain the isInput / isFinal, (to improve readibility) but write them as getters :
private function get isInput() : Boolean
{
return getCurrentSkinState() == MySkinState.INPUT
}
Just my $0.02
That aside, I found the write up on states very informative. Thanks!
Marty
June 29, 2009
[...] This post was Twitted by adobeInc [...]
June 29, 2009
You are right Marty, the declarative code written when using constants would be the same but the state logic code would be simpler. Another situation to be taken in count is where you need to have the concept of sub-states. I encountered this in one of my projects where the component is in a state but needs to declare different behavior inside that state depending on some extra logic. But then mixing constants with bit wise operators to know in what state/sub-state will do the work properly. I’ll check on this issue and come back with an update if new ideas come to life.
Adrian.
July 3, 2009
[...] 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 … See the original post here: Architecting a Flex 4 component | Ayone Blog [...]
July 4, 2009
[...] 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 … Read the rest here: Architecting a Flex 4 component | Ayone Blog [...]
July 30, 2009
[...] integration and other SpringSource technologies. As an example it is linked with the previous post Architecting a Flex 4 component, building the backend services for the contact [...]
August 30, 2009
[...] Architecting a Flex 4 component | Ayone Blog ayonesoftware.com/blog/2009/06/architecting-a-flex-4-component – view page – cached #Ayone Blog RSS Feed Ayone Blog ยป Architecting a Flex 4 component Comments Feed Ayone Blog We are back in the blogosphere, with a little extra Flex 4 Memory Optimizations Spring BlazeDS Integration on top of SpringSource dm — From the page [...]
Leave a comment