Blog

One of the new features of Flex 2 is states. It allows you to declaratively define the state of a component. Flash Developers used to do this by using different frames for MovieClips in Flash. Since the timeline paradigm doesn’t exist in Flex, you had to use copious amounts of Effect ActionScript and/or ViewStacks to have a component have multiple states. Programmers would do the same thing in Flash too, using Tween engines like Animation Package and Laco Tween, abandoning the timeline entirely. Still, it was clear that Flash Developers had the edge.

The biggest issue here is that MXML offers a way to significantly increase code portability, reduce the amount of code written, and cleanly separate concerns. Once you started to fallback into pure ActionScript, you started to lose those benefits that MXML offered. You didn’t really have a choice before Flex 2.

For example, the typical ActionScript class has an import statement up top identifying the View control you wish to use. It then has some sort of init function to create the control and assign it default properties and add events. In another area is additional code to size the control based on it’s parent form resizing. Finally, there may be changes to it such as loading a new image into an image control as the result of a button click. This is 4 different places in code each operating on the same control. MXML helps centralize this into 1 tag.

For example, here is a common ActionScript 3 UIComponent class (psuedo code).

package
{
        import mx.controls.Button;
        import mx.containers.Canvas;
        import flash.events.MouseEvent;
        
        public class MyForm extends Canvas
        {
                
                protected var my_pb:Button;
                
                public function MyForm()
                {
                }
                
                override protected function createChildren():void
                {
                        super.createChildren();
                        my_pb = new Button();
                        addChild ( my_pb );
                        my_pb.addEventListener ( MouseEvent.CLICK, onClick );
                }
                
                override protected function updateDisplayList( unscaledWidth:Number,
                                                                                      unscaledHeight:Number):void
                {
                        super.updateDisplayList(unscaledWidth, unscaledHeight);
                        my_pb.width = width;
                }
                
                protected function onClick ( event : MouseEvent ) :void
                {
                        // do something
                }
        }
}

The thing that I think most ActionScript programmers have gotten their eyes trained to do is all “things used” are up top, defined in the imports. All things created GUI wise are somewhere near the top. All things initialized are usually in the same place as where they are being created. Finally, event handlers to respond to such things are near the bottom, mired with the rest of them.

MXML enters the picture, and throws a few for a loop. For example, the above, only done in MXML instead:

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.macromedia.com/2005/mxml">

   <mx:Script>
   <![CDATA[

      protected function onClick ( event : MouseEvent ) :void
      {
         // do something
      }

   ]]>
   </mx:Script>

   <mx:Button id="my_pb" width="100%" click="onClick(event)" />

</mx:Canvas>

Significantly more compact. Additionally, it’s a lot easier to rip out the Button, and replace it with, say, a DateField all in 1 line of code. The only thing I DID keep was my event listener. However, again, the imports are gone… so who’s used? The creation is implied by putting the tag, so suddenly, you don’t have that comfort zone of seeing things clearly created. Finally, there is no sizing code; it’s relative to what container the control is in and what his x, y, width and height properties, if any, say.

Again, though, it’s really hard to have an appreciation for how much more centralized this model is if you haven’t written it by hand in AS for a long time. Changing the type, id (like an instance name), position, size, and event handlers are all done in the same place. This is a big change.

However, one thing you’ll notice is it is implied that the button is, forever after “there” and in the same state. Yes, you can apply effects to it, but it never disappears, and unless you bind, say, it’s label property to something, for the most part it never changes. …and that, my friends is what a lot of HTML interfaces do. Rarely if ever changes. They are a lot of times stateless, there for the explicit purpose of gathering data.

…but this is running atop the Flash Platform, and ultimately the Flash Player. We have room to move, grow, and the ability to change the GUI while keep the data intact and easily attainable. AJAX has helped significantly improve this for HTML without negatively affecting the rest of the HTML page, or app. It can be applied, even gregariously, and still be self-contained to improve certain portions of an app.

Flex 1.5 and AJAX still both suffer from the need of copious amounts of scripting to handle more than your average GUI change such as toggling DIV visibility or ViewStacks in Flex. To make a certain control / component have multiple states usually involves making it up of other smaller controls… or a lot of code whose intent is immediately apparent.

Enter states in Flex 2. Now you can significantly reduce the amount of code required to have a GUI control have many states, the intent of the MXML is clear, and centralized enough that it is orthogonally designed. States in MXML are declarative, meaning you write tags that clearly name their state, and what they are based on if any. You have the option of defining transitions, which are like effects, that allow you to more eloquently and clearly change from one state to the other. Taking advantage of the centralized nature of MXML, you can also change the GUI without affecting the states or transitions. You can change the states without affecting your core GUI. You can change your transitions without negatively affecting your GUI or states. Pimp.

This gives you a lot of flexibility, and lessens the need for in house Flash talent to get those challenging state changes… or hours of Herculean coding.

There are 4 basic ways to states in Flex allow you to change the component. You can add additional components, remove existing ones, change property values, change styles, and change event handlers. This is included with all the existing abilities to bind controls’ properties to data as well as having control of their creationPolicy. You even get events of when a state has started to change, when it’s done, and while it’s changing. You can use this to make sub-states for complex changes to allow one state change being completed to start the GUI automatically to change to another state. For example, if you minimize a window, you can have your GUI automatically change to the “hidden” state for example.

Transitions are cool because writing effects to handle the above usually involved registering for completion events, and ignoring the potential race conditions of a Fade maybe finishing after a Resize. While Effects do have the Sequence and Parallel classes to help this, you still have to setup functions to respond in the correct order after a specific state change.

Transitions are built for the sole purpose of melding state changes and effects easily and flexibly. You can create them explicitly to happen when one specific state changes to another, or when any state changes at all.

The example I did was re-creating the old Macromedia Central ExpandingPod. I originally did this last December to see how the new Flash 8 effects worked in Flex. You’ll notice there was really no point of me using MXML at all since the entire component is created via code. I redid it this weekend, ExpandingPod2, to utilize states. I originally thought that compared to say, ViewStacks, that it’d actually make MXML verbose and worse than the ActionScript, but in practice, I was wrong. It feels really good to have these things clearly separated; my state change from my transitions. In the ActionScript example they are all intertwined, and not very flexible, nor is it very clear where you can play to tweak things. The MXML version ended up being less code overall, too, which is nice.

This example also showcases Scale9 usage in Flex 2. The background pod image is 1 bitmap that does not scale the borders nor the corners. That way, I can have 1 bitmap instead of 1 sliced up into 9 pieces. Waldo Smeets has a better image example here.

All this example shows state wise is the change property state change tag. I did not add any other controls, nor remove them, nor change styles, nor change any event handlers. I think I’ll save the more complex sample for a later week; the most cliché control that every Flex developer tweaks… the Panel. Since everyone views them as windows, I’ll try to build an example that uses a more advanced example of adding and remove children.

In conclusion, the thing to look at here is the amount of ActionScript used in ExpandingPod.mxml, and compare to the way states are declaratively used in ExpandingPod2.mxml. Same control, different way to get the same result using the new “states” feature in Flex 2. If you click on View, you can also right click and View Source.

ExpandingPod (Requires Flash Player 8.5 beta)
View | Source