Flex Developers & Development | flexdevelopers.com

Flex Examples - Binding a Value to a ComboBox

2010-02-22T21:27:00.011-07:00

When working with the ComboBox component, I have found that I pretty much always want to bind a value to the ComboBox so that it automatically selects a corresponding record in the dataProvider. The most straight forward example of this is with a ComboBox on an address form to select a state. If you load an address into the form, the ComboBox should automatically select the state associated to that address.

To accomplish this I followed a post by Ben Forta to extend the ComboBox, and have made some changes over the years to fine tune it. The principle idea of the approach is to add a selectedValue property to the ComboBox and then loop through the dataProvider to look for a match whenever the selectedValue or the dataProvider is changed. I added dataProperty for specifying the property in the dataProvider that the value should map to, and an additional override to the collectionChangeHandler to catch any updates to the dataProvider.

I settled on naming the component VBComboBox, with VB standing for Value Bound. I have it implemented as an actionscript class in my projects, but wrapped in mxml for this blog post to avoid having to specify a package name. I've included an example of the component at the bottom of this post with viewable source, so I'll just walk though some of the highlights.

All the “magic” happens in the commitProperties method. This method is executed anytime the properties of the class are invalidated. The setter for the dataProvider in the ComboBox calls invaidateProperties() as does the setter for the selectedValue in VBComboBox. Each setter also sets a flag that the value has changed. The following is a rough breakdown of the functionality that was added.

The first if statement in the commitProperties method checks these flags to see if the dataProvider or selectedValue have changed.
If a change is detected, then loop through all the objects in the dataProvider.
The if statement in the loop checks the dataProperty (defaulted to “data”) of the current object against the selectedValue. If they match the idx var is set with the current position and the loop is broken.
The selectedIndex is set to the position that was found or -1. Setting it to -1 if no match is found will cause the prompt value assigned to the ComboBox to be displayed.

override protected function commitProperties():void
{
    super.commitProperties();

    //If the selectedValue and dataProvider are set, find the selectedIndex of the value.
    if ((selectedValueChanged == true && dataProvider != null) ||
        (dataProviderChanged == true && selectedValue != undefined))
    {
        dataProviderChanged=false;
        selectedValueChanged=false;

        var idx:int=-1;

        //Loop through data provider until a record with the value is found.
        for (var i:int=0; i < dataProvider.length; i++)
        {
            if (this.dataProvider[i] != null &&
                this.dataProvider[i].hasOwnProperty(dataProperty) &&
                this.dataProvider[i][dataProperty] == selectedValue)
            {
                idx=i;
                break;
            }
        }

        //Set the selectedIndex with the index found or -1 if not found.
        this.selectedIndex=idx;
    }
}

There is also an override of the collectionChangeHandler to catch changes to the dataProvider that happen outside of the setter. This can happen records are added, removed, or if the source of an ArrayCollection is reset for example. In this case, the dataProviderChanged flag is set to true, and the properties are invalidated to re-check the selectedValue against the dataProvider.

override protected function collectionChangeHandler(event:Event):void
{
    super.collectionChangeHandler(event);

    dataProviderChanged=true;
    invalidateProperties();
}

To view the entire source, right click on the example and select “View Source”.

Flex Basics - Local Shared Object

2010-01-28T13:09:00.007-07:00

From Wikipedia, a browser cookie is a "small piece of text stored on a user's computer by a web browser. A cookie consists of one or more name-value pairs containing bits of information".

A web application uses cookies for session management, personalization and tracking. Most browsers restrict the size of a cookie to 4 kb.

In a Flex application, storing data on a user's computer for later use is accomplished using Local Shared Objects rather than cookies. A Local Shared Object can store up to 100 kb of data without asking permission of the user. Unlike cookies that are capable of storing only text values, Local Shared Objects can store many data types including Number, String, Boolean, XML, Date, Array & Object. Instances of a custom class can also be stored in a Local Shared Object when the custom class is registered using the [RemoteClass] metadata tag.

Create / retrieve a Local Shared Object

The process for creating a new Local Shared Object or retrieving an existing Local Shared Object is identical. In both cases, the static method getLocal() is used.

public static function getLocal(name:String, localPath:String = null, secure:Boolean = false):SharedObject

First, perform a call to the static method getLocal() of the SharedObject class, and then save the reference in a variable.

var myNewLocalSharedObject:SharedObject = SharedObject.getLocal("myNewLocalSharedObject");

Flash Player will look in a local directory on the user's computer for a Local Shared Object named myNewLocalSharedObject. More specifically, it will look in a directory unique to the SWF's domain for a file named myNewLocalSharedObject.sol. If myNewLocalSharedObject.sol is found, a reference to the existing Local Shared Object is returned. Otherwise, myNewLocalSharedObject.sol is created and a reference is returned to the newly created Local Shared Object.

To determine whether a new or existing Local Shared Object was returned, query the size property.

var myNewLocalSharedObject:SharedObject = SharedObject.getLocal("myNewLocalSharedObject");

if (myNewLocalSharedObject.size > 0)
{
    trace("Existing Local Shared Object");
}
else
{
    trace("New Local Shared Object");
}

The getLocal() method has three parameters. They should be used as follows:

The name parameter is required to assign a name to the Local Shared Object.

The localPath parameter is optional and should be used if you anticipate multiple SWF files from the SAME domain needing access to one Local Shared Object, or if the SWF file responsible for creating the Local Shared Object may be moved to another location within the SAME domain.

The secure parameter is optional and is used to create a secure Local Shared Object. Once created, any subsequent calls to the secure Local Shared Object must be made by a SWF delivered over HTTPS.

Access / update a Local Shared Object

A Local Shared Object may have many attributes. For example, customer data may include name, age, address and order IDs. Each of these attributes is represented by a property of the Local Shared Object's data property. These values can be accessed, updated or deleted.

// retrieve a reference to the existing Local Shared Object (customerData.sol)
var so:SharedObject = SharedObject.getLocal("customerData");

// accessing the values of the Local Shared Object
var name:String = so.data.name;
var age:int = so.data.age;

// updating the values of the Local Shared Object
so.data.name= "John Smith";
so.data.age = 23;
so.data.orderIds = [23456, 24444, 25432];

// a custom class must be registered and marked serializable using the [RemoteClass] metadata tag
var address:Address = new Address();
address.street = "125 Foo Lane";
so.data.address = address;

// deleting values of the Local Shared Object
delete so.data.age;
delete so.data.orderIds;

Persist a Local Shared Object

Use the flush() method to immediately write a Local Shared Object to the user's computer.

public function flush(minDiskSpace:int = 0):String

A call to flush() returns one of two possible values, SharedObjectFlushStatus.PENDING or SharedObjectFlushStatus.FLUSHED. If more space is needed on the user's computer to persist the Local Shared Object, SharedObjectFlushStatus.PENDING is returned and a dialog box is presented to the user to obtain permission to allocate more space.

When the user selects "Allow" or "Deny" a NetStatusEvent.NET_STATUS event is dispatched targeting the Local Shared Object. Register an event listener to handle this event.

so.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);

If the Local Shared Object is successfully written to the user's computer, SharedObjectFlushStatus.FLUSHED is returned and the user is not notified.

The flush() method has one parameter. It should be used as follows:

The minDiskSpace parameter is optional and is used to allocate additional space (over 100 kb) on the user's computer for the Local Shared Object. If used, a dialog box is presented to the user asking for permission to allocate additional space.

private function writeSharedObject():void
{
    var so:SharedObject = SharedObject.getLocal("mySO");
    so.data.name = "Jeremy Mitchell";
    try
    {
        // wrap in a try to handle a scenario where local storage has been disallowed
        so.flush(500000);
    }
    catch (e:Error)
    {
        trace("Local storage has been disabled for this domain");
    }
}

Note: The flush() method is not required to persist a Local Shared Object. When the application SWF closes, an attempt is made to persist all Local Shared Objects on the user's computer. However, if adequate space is not allocated for the Local Shared Object, the attempt will fail silently. Use the flush() method to ensure success and recover from any possible failure.

Delete a Local Shared Object

To purge the data of a Local Shared Object and delete it from the user's computer call the clear() method.

public function clear():void

var so:SharedObject = SharedObject.getLocal("loginInfo");
so.clear();

Flex Basics - Creating a Popup Window with PopUpManager

2009-12-07T11:27:00.000-07:00

Popup windows serve as a handy tool for data collection or display. Popup windows in Flex are frequently implemented as a TitleWindow or a subclass of TitleWindow. TitleWindow is a popular choice as it inherits the capabilities of a Panel (title bar, control bar, border & content area) while adding a nifty close button.

With built-in modal support, popup windows can demand the user's attention or force interaction when necessary. This is possible because windows below a modal popup window cannot receive mouse events until a modal popup window is dismissed.

The PopUpManager class is used to manage popup windows in Flex. You can create, center and remove popup windows by using the static methods of the PopUpManager class.

addPopUp()

public static function addPopUp(window:IFlexDisplayObject, parent:DisplayObject, modal:Boolean = false, childList:String = null):void

createPopUp()

public static function createPopUp(parent:DisplayObject, className:Class, modal:Boolean = false, childList:String = null):IFlexDisplayObject

centerPopUp()

public static function centerPopUp(popUp:IFlexDisplayObject):void

removePopUp()

public static function removePopUp(popUp:IFlexDisplayObject):void

Creating a popup window

Flex provides two distinct, yet very similar, methods for creating a popup window and placing it on a layer above all other visible windows – addPopUp() and createPopUp(). The difference between each method is subtle and determining which to use is mostly a matter of preference.

Note: Adobe documentation states that "using the addPopUp() method may be preferable to using the createPopUp() method if you have to pop up a simple dialog box that is never used elsewhere."

Looking closely at each method signature (addPopUp & createPopUp), the difference dictates how to use the method rather than when to use it. (or so it seems)

Method characteristic	addPopUp()	createPopUp()
Requires a popup window instance as an argument	Yes	No
Returns a value that can be stored in a variable	No	Yes

Here are some guidelines I tend to follow:

If you want to create a quick and dirty simple popup window that you don't plan to reuse, use addPopUp().

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="openTitleWindow(event)" >

    <mx:Script>
        <![CDATA[
            import mx.events.CloseEvent;
            import mx.controls.Label;
            import mx.events.FlexEvent;
            import mx.containers.TitleWindow;
            import mx.managers.PopUpManager;

            // method to open the TitleWindow on creationComplete
            private function openTitleWindow(evt:FlexEvent):void {
                // create and configure the TitleWindow
                var tw:TitleWindow = new TitleWindow();
                tw.title = "Title Goes Here";
                tw.showCloseButton = true;
                tw.addEventListener(Event.CLOSE, closeTitleWindow);
                // create and configure a Label
                var label:Label = new Label();
                label.text = "This is a very simple popup window";
                // add the Label to the TitleWindow
                tw.addChild(label);
                // open the TitleWindow as a modal popup window
                PopUpManager.addPopUp(tw, this, true);
            }
            
            // method to close the TitleWindow targeted by a close event
            private function closeTitleWindow(evt:CloseEvent):void {
                PopUpManager.removePopUp(TitleWindow(evt.target));
            }
        ]]>
    </mx:Script>
    
</mx:Application>

If reuse of a popup window is a priority, use createPopUp() and store the returned object in a variable for later use.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="openPopUpWindow(event)" >

    <mx:Script>
        <![CDATA[
            import comps.MyPopUpWindow;
            import mx.events.FlexEvent;
            import mx.managers.PopUpManager;
            
            // declare a variable for the reusable custom PopUp Window
            private var popup:MyPopUpWindow;

            // method to open the PopUp Window on creationComplete
            private function openPopUpWindow(evt:FlexEvent):void {
                // open the PopUp Window as a modal popup window
                // and store it in a variable for later use
                popup = PopUpManager.createPopUp(this,MyPopUpWindow,true) as MyPopUpWindow;
            }
        ]]>
    </mx:Script>
    
</mx:Application>

<?xml version="1.0" encoding="utf-8"?>
<!-- custom popup window component - comps/MyPopUpWindow.mxml -->
<mx:TitleWindow xmlns:mx="http://www.adobe.com/2006/mxml" 
        layout="vertical" 
        title="My Custom PopUp Window"
        showCloseButton="true">
         
        <mx:Form>
        
            <mx:FormHeading label="User Login"/>
            
            <mx:FormItem label="Username">
                <mx:TextInput id="un"/>
            </mx:FormItem>
            
            <mx:FormItem label="Password">
                <mx:TextInput id="pd"/>
            </mx:FormItem>
            
            <mx:ControlBar>
                <mx:Button id="save" label="Login"/>
                <mx:Button id="cancel" label="Cancel"/>
            </mx:ControlBar>
             
        </mx:Form>
        
</mx:TitleWindow>

Centering a popup window

A popup window can be centered in relation to any DisplayObject. When creating a popup window using addPopUp() or createPopUp(), it is important to understand that the parameter named "parent" (datatyped as DisplayObject) will be used to determine the reference point for centering a popup window. In most cases, you’ll want a popup window to be centered over the Application.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="openPopUpWindow(event)" >

    <mx:Script>
        <![CDATA[
            import comps.MyPopUpWindow;
            import mx.events.FlexEvent;
            import mx.managers.PopUpManager;
            
            // declare a variable for the reusable custom PopUp Window
            private var popup:MyPopUpWindow;

            // method to open the PopUp Window on creationComplete
            private function openPopUpWindow(evt:FlexEvent):void {
                // open the PopUp Window as a modal popup window
                // and store it in a variable for later use
                popup = PopUpManager.createPopUp(this,MyPopUpWindow,true) as MyPopUpWindow;
                // center the PopUp window
                PopUpManager.centerPopUp(popup);
            }
        ]]>
    </mx:Script>
    
</mx:Application>

In the previous example, notice that the DisplayObject used to center the popup window was this. In this case, this refers to the Application container, and therefore, the popup window was centered nicely over the Application. In many cases this will not refer to the Application container (i.e. inside custom components). When opening a popup window from within a custom component, use the following code to ensure the popup window is centered over the Application container and not the custom component.

popup = 
PopUpManager.createPopUp(DisplayObject(this.parentApplication),MyPopUpWindow,true) as MyPopUpWindow;

Removing a popup window

Once our popup window has been created, displayed and optionally centered, there are a couple of options for removing it from display.

1. A parent removes a popup window from display

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="openPopUpWindow(event)">

    <mx:Script>
        <![CDATA[
            import mx.events.FlexMouseEvent;
            import comps.MyPopUpWindow;
            import mx.events.FlexEvent;
            import mx.managers.PopUpManager;
            
            // declare a variable for the reusable custom popup window
            private var popup:MyPopUpWindow;

            // method to open the popup window on creationComplete
            private function openPopUpWindow(evt:FlexEvent):void {
                // open the popup window as a modal popup window
                // and store it in a variable for later use
                popup = PopUpManager.createPopUp(this,MyPopUpWindow,true) as MyPopUpWindow;
                // register event listeners for closing the popup window
                // when the popup window close button is clicked...
                popup.addEventListener(Event.CLOSE, closePopUpWindow);
                // or when an area outside the popup window is clicked...
                popup.addEventListener(FlexMouseEvent.MOUSE_DOWN_OUTSIDE, closePopUpWindow);
                // center the popup window
                PopUpManager.centerPopUp(popup);
            }
            
            // method to close the popup window on close or mousedownoutside event
            private function closePopUpWindow(evt:Event):void {
                PopUpManager.removePopUp(popup);
            }
        ]]>
    </mx:Script>
    
</mx:Application>

2. A popup window removes itself from display

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    creationComplete="openPopUpWindow(event)">

    <mx:Script>
        <![CDATA[
            import mx.events.FlexMouseEvent;
            import comps.MyPopUpWindow;
            import mx.events.FlexEvent;
            import mx.managers.PopUpManager;
            
            // declare a variable for the reusable custom popup window
            private var popup:MyPopUpWindow;

            // method to open the popup window on creationComplete
            private function openPopUpWindow(evt:FlexEvent):void {
                // open the popup window as a modal popup window
                // and store it in a variable for later use
                popup = PopUpManager.createPopUp(this,MyPopUpWindow,true) as MyPopUpWindow;
                // center the popup window
                PopUpManager.centerPopUp(popup);
            }
        ]]>
    </mx:Script>
    
</mx:Application>

<?xml version="1.0" encoding="utf-8"?>
<!-- custom popup window component - comps/MyPopUpWindow.mxml -->
<mx:TitleWindow xmlns:mx="http://www.adobe.com/2006/mxml" 
        layout="vertical" 
        title="My Custom PopUp Window"
        showCloseButton="true"
        close="PopUpManager.removePopUp(this)">
        
        <mx:Script>
            <![CDATA[
                import mx.managers.PopUpManager;
            ]]>
        </mx:Script>
         
        <mx:Form>
        
            <mx:FormHeading label="User Login"/>
            
            <mx:FormItem label="Username">
                <mx:TextInput id="un"/>
            </mx:FormItem>
            
            <mx:FormItem label="Password">
                <mx:TextInput id="pd"/>
            </mx:FormItem>
            
            <mx:ControlBar>
                <mx:Button id="save" label="Login"/>
                <mx:Button id="cancel" label="Cancel"/>
            </mx:ControlBar>
             
        </mx:Form>
        
</mx:TitleWindow>

I hope that gives you some ideas about how to use PopUpManager & TitleWindow in your Flex apps. Have fun!

Flex Tips - Using Bindable Metadata Events

2009-11-03T11:16:00.001-07:00

One powerful feature of Flex is data binding. On the surface, data binding is simple to implement.

1. Mark a class as bindable to activate data binding on all public properties of the class

[Bindable]
public class Order

Or, mark individual properties as bindable

public class Order
{
    public function Order()
    {
    }
   
    [Bindable]
    public var orderNumber:int;
   
    [Bindable]
    public var orderName:String;
}

2. Declare an instance of the class preceded with the [Bindable] metadata tag

[Bindable]
private var order:Order = new Order();

3. Use a bindable property as the source of a data binding association. 3 techniques exist:

Wrap the source property in curly brackets

<mx:Label id="myLabel" text="{order.orderName}"/>

Use a Binding tag

<mx:Binding source="order.orderName" destination="myLabel.text"/>

Create the data binding association at runtime

BindingUtils.bindProperty(myLabel, "text", order, "orderName");

The most common practice includes the use of curly brackets. The following example demonstrates data binding in its simplest form.

// Value object class marked bindable
    
[Bindable]
public class Order
{
    public function Order()
    {
    }
   
    public var orderNumber:int;
    public var orderName:String;
}

<!-- Application file -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
        layout="vertical">
    
    <mx:Script>
        <![CDATA[
            import comps.Order;
            
            [Bindable]
            private var order:Order = new Order();
        ]]>
    </mx:Script>
    
    <!-- binding #1 -->
    <mx:Label  text="{'Order #: ' + order.orderNumber}"/> 
    
    <!-- binding #2 -->
    <mx:Text text="{'Order Name: ' + order.orderName}"/>
    
    <mx:HBox>
    
        <mx:Button label="Change Order #" click="order.orderNumber = Math.floor(Math.random()*50)+1"/>
        <mx:TextInput id="ti" text="Enter name..." enter="order.orderName = ti.text" />
        
    </mx:HBox>
    
</mx:Application>

In most scenarios, this approach is acceptable. However, there are times when another technique is recommended. It involves explicitly defining which event type to dispatch when a source property changes. Let's review what we did previously.

We marked an entire class as bindable

[Bindable]
public class Order

Or, marked individual properties as bindable

public class Order
{
    public function Order()
    {
    }
   
    [Bindable]
    public var orderNumber:int;
   
    [Bindable]
    public var orderName:String;
}

This is equivalent to:

[Bindable(event="propertyChange")]
public class Order

public class Order
{
    public function Order()
    {
    }
   
    [Bindable(event="propertyChange")]
    public var orderNumber:int;
   
    [Bindable(event="propertyChange")]
    public var orderName:String;
}

Data binding includes a lot of code generation. This is part of it. When using the [Bindable] metadata tag without explicitly defining the event type, the default event type is used – propertyChange.

Using the default event type (propertyChange) is fine except when you mark the entire class as bindable and the class contains several public properties (see Cairngorm's ModelLocator class). In this case, each public property will dispatch the same event type (propertyChange) when their value changes. This can be problematic.

To understand why this is a problem, let's take a closer look at what happens behind the scenes when data binding is used.

Note: This is a very high-level analysis of the inner-workings of data binding. For a detailed description of data binding, check out Michael Labriola's presentation entitled Diving in the Data Binding Waters

To accomplish data binding, here's what is required of you:

First, mark a class as bindable to activate data binding on all public properties of the class:

[Bindable]
public class Order

Or, mark individual properties as bindable

public class Order
{
    public function Order()
    {
    }
   
    [Bindable]
    public var orderNumber:int;
   
    [Bindable]
    public var orderName:String;
}

By doing this, the Flex framework does the following by generating more code:

Turns your class into an "event dispatcher" by implementing IEventDispatcher

Implements the methods required of the IEventDispatcher interface (addEventListener, removeEventListener, dispatchEvent, etc)

Creates implicit getters and setters for each bindable property

Converts [Bindable] to [Bindable(event="propertyChange")]

Adds code to your setter method required to dispatch the propertyChange event when the property value changes.

Why does the Flex framework do all of this? In a nutshell, so your class can:

Broadcast an event when a bindable property value changes

Allow interested parties to register an event listener triggered when a bindable property changes

But wait, there's more! When you actually use a bindable property as the source of a data binding (via curly brackets, Binding object or BindingUtils.bindProperty), the Flex Framework generates even more code required to:

Create an array of Binding objects

One Binding object is created for each data binding association. Each Binding object is responsible for updating a destination property when the corresponding source property changes.

Create an array of PropertyWatcher objects

One PropertyWatcher object is created for each data binding association. Each PropertyWatcher object is responsible for "listening" for an event to occur that signifies a change in the source property value. The event type is determined by the value defined in the [Bindable] metadata tag. Again, if no type is defined, propertyChange is used.

Failure to specify an event type in the [Bindable] metadata tag forces every public property to dispatch a propertyChange event when their value changes, and, in turn, every PropertyWatcher is "listening" for a propertyChange event. However, only the PropertyWatcher tasked with watching the property that actually changed is required to respond to the event and notify the Binding object responsible for updating the destination property.

The extra work involved with triggering multiple PropertyWatcher objects when only ONE source property changes can be expensive and can be avoided by simply defining a unique event for each bindable property. The following example demonstrates this technique.

// Value object that dispatches unique events for each bindable property

package comps
{
    import flash.events.Event;
    import flash.events.EventDispatcher;
    
    public class Order extends EventDispatcher
    {
        public function Order()
        {
        }
       
        private var _orderNumber:int;
       
        [Bindable(event="orderNumberChange")]
        public function get orderNumber():int {
            return _orderNumber;
        }
       
        public function set orderNumber(value:int):void {
            if ( _orderNumber !== value ) {
                _orderNumber = value;
                // remember to dispatch the unique event
                dispatchEvent(new Event("orderNumberChange"))
            }
        }
       
        private var _orderName:String;
        
        [Bindable(event="orderNameChange")]
        public function get orderName():String {
            return _orderName;
        }
       
        public function set orderName(value:String):void {
            if ( _orderName !== value ) {
                _orderName = value;
                // remember to dispatch the unique event
                dispatchEvent(new Event("orderNameChange"))
            }
        }

    }
}

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
    xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="vertical">
   
    <mx:Script>
        <![CDATA[
            import comps.Order;
           
            [Bindable]
            private var order:Order = new Order();
        ]]>
    </mx:Script>
   
    <!-- binding #1 -->
    <mx:Label id="myLabel" text="{'Order #: ' + order.orderNumber}"/>
   
    <!-- binding #2 -->
    <mx:Text text="{'Order Name: ' + order.orderName}"/>
   
    <mx:HBox>
   
        <mx:Button label="Change Order #" click="order.orderNumber = Math.floor(Math.random()*50)+1"/>
        <mx:TextInput id="ti" text="Enter name..." enter="order.orderName = ti.text" />
       
    </mx:HBox>
   
</mx:Application>

Adobe Flex Rates - What do you charge?

2009-10-05T10:17:00.001-06:00

Important: This poll is not limited to Flex developers in the US. Please read the comments associated with this blog entry to get a sense of where the votes are coming from.

Obviously, many factors must be considered when determining a Flex developer's hourly rate. These may include:

Experience (i.e. less than 1yr, 1-2yrs, 2-4yrs, 4+yrs)

Skill level (i.e. junior, intermediate, advanced, expert)

Role (employee, contractor (or subcontractor), consultant)

Responsibilities (i.e. Flex dev only, Flex + Java dev, etc)

Developer's track record

Additional factors may include:

Market size (small, medium, large)

Market forces (supply and demand)

Geography

Client's budget

Project urgency

The list goes on and on, but it's still interesting to know what other Flex developers are charging. It gives us a basis for our own calculations. So go ahead, take the poll and share with the world. We're all dying to know. Comments encouraged.

Note: If you're an employee with a salary and benefits, someone once told me your hourly rate can be determined by (salary / annual hours) * 1.4. (annual hours typically equals 2000)

Flex Examples - Creating a Custom Event

2009-08-22T14:01:00.000-06:00

Flex applications consist of a component hierarchy starting with the Application root. Components are built-in or custom.

Interaction between components may occur down the component hierarchy (parent to child) or up (child to parent).

When a parent component interacts with a child component, the parent utilizes the child component's interface (API). This interface includes the component's public properties and methods.

For example, a parent component may hide a child component by setting its visible property to false.

<!-- parent component -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"> 

    <mx:Script>
        <![CDATA[
            private function doSomething(event:MouseEvent):void {
                lbl.visible = false; // parent (Application) interacting with child (Label)
            }
        ]]>
    </mx:Script>
    
    <!-- child component -->
    <mx:Label id="lbl" text="Hello there"/> 
    
    <!-- child component -->
    <mx:Button label="Hide Label" click="doSomething(event)"/>
    
</mx:Application>

Note: The Label's visible property is actually marked private but is publicly exposed through an implicit getter and setter.

Conversely, when a component wants to interact with a parent (or ancestor) component, it does so by dispatching events. Events are dispatched to signify an occurrence has taken place and include the details of the occurrence wrapped inside an event object.

Components may express an interest in a particular event by registering an event listener. Event listeners map an event to a method. This method is referred to as an event handler and is designed to perform one or more actions in response to an event.

Because an event (built-in or custom) propagates down through the display hierarchy during the Capturing phase of the event flow and back up during the Bubbling phase, ancestor components have two opportunities to register event listeners.

Note: Events do not bubble by default. All events extend the flash.events.Event class which requires 3 constructor arguments (type, bubbles and cancelable). Set bubbles to true and override the clone method to activate event bubbling.

In addition to the details of the event (target, currentTarget, type, eventPhase, etc), custom event objects can carry a "payload" used to transfer data. The payload is nothing more than a storage variable declared as a property of the event object.

In this short video, I will create a custom event designed to carry user information (username / password) captured when the user logs in.

Correction: In the video, I failed to override the clone method. Without overriding the clone method, a custom event will not be capable of bubbling.

View the source code of the custom event example.

After watching the video, it may still not be obvious why this approach is considered a best practice. Following the principles of encapsulation, we want our components to represent a "black box". We interact with a component via its public interface (API) and it broadcasts information about itself using events. If you find the event and the information it contains to be interesting, listen for the event and act on it.

Interaction between components in this fashion promotes loose coupling which ultimately provides greater flexibility.

Flex Examples - Creating a Custom Visual Component

2009-07-31T14:10:00.000-06:00

The Flex SDK includes a compiler, debugger, profiler and a class library. The Flex Class Library is commonly referred to as the Flex Framework and includes hundreds of ActionScript classes and interfaces used to develop Flex applications.

The classes serve as the basis for Flex's visual and non-visual components:

Visual component classes:

Containers for layout (HBox, VBox, Canvas, Panel) and navigation (Accordion, Tab Navigator, ViewStack)

Controls for data input (TextInput, TextArea, DateField, CheckBox, etc) and data presentation (List, DataGrid, Tree, etc)

Controls for user interaction (Button, LinkBar, etc)

Components for charting (BubbleChart, LineChart, PieChart, etc)

Non-visual component classes:

Components for data access (HTTPService, WebService, RemoteObject, etc)

Components for data collection (ArrayCollection, XMLListCollection)

Components for data validation (EmailValidator, NumberValidator, RegExpValidator, etc) and data formatting (DateFormatter, PhoneFormatter, etc)

Components for animation effects and state transitions (Move, Resize, Fade, etc)

Skin and Style classes (Border, ProgrammaticSkin, CSSStyleDeclaration)

Manager classes (BrowserManager, HistoryManager, CursorManager, LayoutManager, etc)

Utility classes (ArrayUtil, ColorUtil, GraphicsUtil, etc)

Language feature support classes (BindingUtils, ChangeWatcher, etc)

Shipped with the Flex SDK, most of these classes produce "built-in" components available for use immediately. Utilization only requires instantiation and an understanding of each component's API (the accessible properties and methods and the applicable events, styles and effects). API details are found in the Flex Language Reference and exposed through Flex Builder's code completion (hit control-space bar while in an MXML tag or after a dot in ActionScript when using dot notation to see the accessible members of the class).

Note: Some of these classes are created for you at application start up (i.e. Manager classes) or do not require instantiation for use (i.e. Utility classes).

The following example demonstrates utilization of a built-in Button component by way of a public property (label) and style (color) while registering a handler on the buttonDown event (aka event listener).

<mx:Button id="myButton" label="Hello" color="0xFF0000" buttonDown="doSomething(event)" />

90% of your Flex development will require built-in components. The rest will require custom components.

Note: The remainder of this entry will focus on visual components. Visual components eligible for participation in the Flex Framework descend from the UIComponent class which descends from the DisplayObject class. The DisplayObject class is the base class for all objects that can be placed on the display list.

A custom visual component is required in the following scenarios:

You want to customize the functionality of a built-in visual component to meet your specific requirements

Nothing in the Flex Class Library comes close to the functionality you want so you need to build a custom visual component from scratch

You want to package multiple components into one custom visual component for the sake of modularity and/or reusability

We'll cover each scenario below:

Scenario #1: You want to customize the functionality of a built-in visual component to meet your specific requirements

In many instances, built-in components satisfy most of your needs. For example, you may need a control to render data as a vertical list while capturing the value of an HSlider's value property. The HSlider's value property will help determine the font color of each item in the vertical list.

Note: This custom component was built in a previous blog entry entitled Flex Examples - Item Renderers in Practice to demonstrate a technique used to facilitate real-time communication between a list-based control's item renderer and an external component.

Extending the capabilities of a built-in component

Since Flex already provides a control capable of rendering data as a vertical list - List, we'll start with that and extend the functionality to include our new property. This can be done in MXML or ActionScript.

Note: Extending an existing class for the purpose of customization follows a fundamental object-oriented design principle - The Open-Closed Principle. This principle says that classes should be open for extension, but closed for modification.

First, navigate to the desired package (directory) in Flex Builder where you'd like your custom component to reside.

If using MXML...

From the context menu (right-click), select File > New MXML Component. Set the 'Based on' field to 'List' and give your MXML component a name starting with a capital letter (to distinguish classes from objects, classes start with a capital letter whereas objects (instances of a class) do not).

The content of your new MXML component is as follows:

<?xml version="1.0" encoding="utf-8"?>
<mx:List xmlns:mx="http://www.adobe.com/2006/mxml">
    
</mx:List>

We're using a List as our base class (so List is our root tag), and we're going to extend its capabilities by adding any properties and methods we see fit. Here we will add a new property to the List control exposed publicly through a getter and setter.

<?xml version="1.0" encoding="utf-8"?>
<mx:List xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:Script>
        <![CDATA[
            private var _newProperty:Number;
            
            // property accessible via a public getter & setter
            // make it bindable if you anticipate its use as the source of a data binding
            [Bindable]
            public function get newProperty():Number{
                return _newProperty;
            }
            
            public function set newProperty(value:Number):void {
                _newProperty = value;
            }
        ]]>
    </mx:Script>
    
</mx:List>

If using ActionScript...

Again, from the context menu select File > New ActionScript Class. Set the 'Superclass' field to mx.controls.List (or hit browse and type in List) and give your ActionScript class a name starting with a capital letter. Flex Builder will create your class with the following contents:

package comps
{
    import mx.controls.List;

    public class MyList extends List
    {
        public function MyList()
        {
            super();
        }
        
    }
}

List is the base class we'd like to extend. Our new class (MyList) inherits the capabilities of a basic List control by extending it while providing an opportunity to customize the properties and methods to meet our needs.

package comps
{
    import mx.controls.List;

    public class MyList extends List
    {
        private var _newProperty:Number; // new property
        
        public function MyList()
        {
            super();
        }

        // getter and setter for our new property marked as bindable
        [Bindable]       
        public function get newProperty():Number {
            return _newProperty;
        }
        
        public function set newProperty(value:Number):void {
            _newProperty= value;
        }
        
    }
}

Now we can create an instance of our new, customized list and utilize our new property.

<comps:MyList newProperty="2" />

Or, we can use it as we intended based on our previous requirements.

<!-- Bind to the HSlider's value property -->
<comps:MyList newProperty="{myHSlider.value}" />

Overriding the behavior of a built-in component

In addition to extending the capabilities of a built-in component, we can change the way it currently behaves.

For example, a Label component is a perfect candidate for an Item Renderer. However, we may want to change the Label's text color when our Label is used as an Item Renderer and certain conditions apply.

Looking closely at the Label class' source file (ctrl-click a Label tag in Flex Builder) and knowing a thing or two about Item Renderers, we settle on the set data method. This method passes the data for an item to the Item Renderer.

Note: The Label class is eligible for item rendering based on the implementation of the IDataRenderer interface which enforces implementation of a data property getter and setter method. Without these methods, there would be no way to pass an item's data to the Label instance.

We would like to add some additional logic to the set method to meet our requirements, therefore, we will extend the Label class and override this existing method.

<!--- MyLabel.mxml used as an Item Renderer --->

<?xml version="1.0" encoding="utf-8"?>
<mx:Label xmlns:mx="http://www.adobe.com/2006/mxml"
    text="{data.name + ' (' + data.age + ')'}">
    <mx:Script>
        <![CDATA[            
            override public function set data(value:Object):void {
                // this is critical since we only want to inject additional logic
                super.data = value; 
                // new behavior
                var minAge:Number = 40;
                if (data.age < minAge) {
                    setStyle("color",0xFF0000);
                } else {
                    setStyle("color",0x000000);
                }
            }
        ]]>
    </mx:Script>
    
</mx:Label>

Note: In most cases, it is critical that we preserve the base class' implementation of the method we wish to override. Therefore, in this example, we need to call super.data.

9 times out of 10, you can enhance a built-in component by extending or modifying its capabilities to fit your needs. Extend an existing class, add a new property or method, override an existing method, or even add new styles, effects or events....

Scenario #2: Nothing in the Flex Class Library comes close to the functionality you want so you need to build a custom visual component from scratch

On occasion, you may have the need to create a component from scratch. This approach is warranted when nothing is gained by extending the functionality of an existing, built-in component (container or control).

For example, you may choose to extend a VBox when you wish to "contain" child components while inheriting the built-in top-to-bottom layout capabilities. However, if layout for your component is dynamic and determined by a style setting, the layout rules of a VBox may not always apply.

As mentioned previously, all visual components eligible for participation in the Flex Framework descend from the UIComponent class. The UIComponent class implements 5 methods required of a visual component. These methods are known as the component lifecycle methods and they include:

createChildren

commitProperties

measure

layoutChrome

updateDisplayList

The Flex Framework depends on these methods and every visual Flex component implements them directly or indirectly (through class inheritance).

Each method plays a particular role and makes a component unique to itself. For components added to the display list, these methods are called by the Flex Framework on application startup and may be called during the lifetime of a component as needed.

createChildren()

Implementation of the createChildren method is required if the visual component is a composite component. Composite components contain child objects. The createChildren method is only called once when the component is added to the display list.

commitProperties()

By coordinating property changes and ensuring expensive calculations are not performed unnecessarily, the commitProperties method can help developers achieve optimal application performance.

measure()

The logic required to determine the custom component's default size and, optionally, default minimum size is contained within the measure method.

layoutChrome()

Container components utilize the layoutChrome method to define border area.

updateDisplayList()

The sizing and positioning of child components is calculated within the updateDisplayList method.

For more information, Adobe has provided a more detailed description of each component lifecycle method.

The following example demonstrates the use of a custom visual component. This component consists of 2 child objects - a TextArea and a Button. The TextArea can be enabled/disabled programatically or by clicking the button. The layout can also be changed at runtime using the radio buttons.

View source is also enabled to provide insight into the structure of the custom component.

Scenario #3: You want to package multiple components into one custom visual component for the sake of modularity and/or reusability

Rather than creating an application consisting of one monolithic file, it is common practice to break an application down into pieces. This technique promotes code reuse and better organization.

Creating custom components to encapsulate distinct application views

Most Flex applications contain multiple views. A view consists of the components required to satisfy a particular task or objective. Each view could be constructed quite easily in the main application file. For example, the following application consist of 2 views - a Login View and a Search View.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="vertical">
    
    <mx:Script>
        <![CDATA[
            private function login(event:MouseEvent):void {
                vs.selectedIndex = 1;
            }
        ]]>
    </mx:Script>

    <mx:ViewStack id="vs"> <!-- navigation containers typically manage views -->
    
        <!-- Login View -->
        
        <mx:Panel title="Login">
            <mx:Form>
                <mx:FormItem label="Username">
                    <mx:TextInput/>
                </mx:FormItem>
                <mx:FormItem label="Password">
                    <mx:TextInput/>
                </mx:FormItem>
            </mx:Form>
            <mx:ControlBar>
                <mx:Button label="Login" click="login(event)"/>
            </mx:ControlBar>
        </mx:Panel>
        
        <!-- Search View -->
        
        <mx:VBox>
            <mx:HBox>
                <mx:TextInput/>
                <mx:Button label="Search"/>
            </mx:HBox>
            <mx:DataGrid/>
        </mx:VBox>
        
    </mx:>
    
</mx:Application>

However, as the application inevitably grows, so does the amount of code in the main application file. Before you know it, it is hard to tell where one view ends and another one begins.

To prevent duplicate code and unwieldy file sizes, consider breaking your application into pieces designed to perform a singular task (for example, "login" is a task represented by a unique view and warrants its own component). This is done by creating custom components like we did before.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:views="views.*"
    layout="vertical">
    
    <mx:Script>
        <![CDATA[
            private function login(event:Event):void {
                vs.selectedIndex = 1; // navigate to the search view
            }
        ]]>
    </mx:Script>

    <mx:ViewStack id="vs">
    
        <!-- Login View -->
        
        <views:LoginView loggedIn="login(event)"/> <!-- custom component -->
        
        <!-- Search View -->
        
        <views:SearchView/> <!-- custom component -->
        
    </mx:ViewStack>
    
</mx:Application>

<!-- LoginView.mxml extends Panel -->

<?xml version="1.0" encoding="utf-8"?>
<mx:Panel xmlns:mx="http://www.adobe.com/2006/mxml">

    <!-- this component dispatches a loggedin event -->
    <!-- that you can now listen for in MXML or ActionScript -->
    <mx:Metadata>
        [Event(name="loggedIn", type="flash.events.Event")]
    </mx:Metadata>

    <mx:Form>
        <mx:FormItem label="Username">
            <mx:TextInput/>
        </mx:FormItem>
        <mx:FormItem label="Password">
            <mx:TextInput/>
        </mx:FormItem>
    </mx:Form>
    <mx:ControlBar>
        <mx:Button label="Login" click="dispatchEvent(new Event('loggedIn'))"/>
    </mx:ControlBar>
    
</mx:Panel>

<!-- SearchView.mxml extends VBox -->

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:HBox>
        <mx:TextInput/>
        <mx:Button label="Search"/>
    </mx:HBox>
    <mx:DataGrid/>
</mx:VBox>

This becomes essential as your views become more complex (i.e. more internal (child) components, view states, events, etc).

Note: Because our Login view was packaged into a LoginView component, access to the application's login method was no longer available. Communication between components should always be accomplished using events, therefore, the LoginView component now dispatches an event. A listener is created in the main application file to handle the event.

<views:LoginView loggedIn="login(event)"/>

In this example, we've created two custom components (LoginView and SearchView) for the purpose of packaging multiple components together. We didn't reduce the amout of code but we did reduce clutter, and if we want, we can reuse these components without copying/pasting code.

Whether you're looking to extend the capabilities of an existing component, create a component from scratch or group components into views, Flex provides the mechanism to do so. Have fun!

Flex Examples - Item Renderers in Practice

2009-06-27T12:19:00.000-06:00

List-based controls (DataGrid, List, TileList & HorizontalList) render the data assigned to their dataProvider property.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="vertical">

    <mx:ArrayCollection id="ac">
        <mx:Array>
            <mx:Object name="tom" age="12" hair="brown"/>
            <mx:Object name="sally" age="21" hair="green"/>
            <mx:Object name="kate" age="16" hair="yellow"/>
            <mx:Object name="bill" age="22" hair="brown"/>
            <mx:Object name="chriss" age="23" hair="green"/>
            <mx:Object name="yarb" age="34" hair="yellow"/>
        </mx:Array>
    </mx:ArrayCollection>
    
    <mx:List id="myList"
        dataProvider="{ac}"
        labelField="name"/>

</mx:Application>

With the help of an Item Renderer, list-based controls can customize the appearance of the data provider's data.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    layout="vertical">
    
    <mx:ArrayCollection id="ac">
        <mx:Array>
            <mx:Object name="tom" age="12" hair="brown"/>
            <mx:Object name="sally" age="21" hair="green"/>
            <mx:Object name="kate" age="16" hair="yellow"/>
            <mx:Object name="bill" age="22" hair="brown"/>
            <mx:Object name="chriss" age="23" hair="green"/>
            <mx:Object name="yarb" age="34" hair="yellow"/>
        </mx:Array>
    </mx:ArrayCollection>
    
    <!-- Using an Item Renderer to control the display of data -->
    <mx:List width="100%"
        dataProvider="{ac}"
        itemRenderer="com.flexdevelopers.ListIR"/>

</mx:Application>

<!-- Item Renderer (ListIR.mxml) -->

<mx:Label xmlns:mx="http://www.adobe.com/2006/mxml"
    text="{data.name + ' (' + data.age + ')'}"
    color="0xFF0000"/>

In addition, the custom appearance can be controlled by conditional logic processed by an Item Renderer. We'll look at this a bit later.

A single instance of your Item Renderer class (ListIR) is created for each visible item of the list-based control.

As the user scrolls through the items of a list-based control, Item Renderer instances are recycled rather than creating new instances.

Example: When Data Item #1 is removed from the list-based control's display due to a scrolling action, the Item Renderer instance previously used to render Data Item #1 is recycled and used to display the data for Data Item #6.

Item Renderers must directly or indirectly (through class inheritance) implement the IDataRenderer interface which enforces the implementation of 2 very important methods: get data() & set data(). With an implicit getter and setter in place for the data property, the Item Renderer instance can receive a data object passed from the host component (the list-based control) which represents the data for the item it is responsible to render (i.e. Data Item #6).

Example: If instance #1 of the Item Renderer is rendering the data for Data Item #6, the data for Data Item #6 is passed to instance #1 of the Item Renderer via the Item Renderer's set data setter method.

When an instance of an Item Renderer is recycled due to scrolling, the set data method is called and the applicable data object is passed. This is the point in which conditional logic can be applied to control the appearance of an Item Renderer.

<!-- Item Renderer (ListIR.mxml) with conditional logic -->

<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Script>
        <![CDATA[
            private var minAge:Number = 21;
                        
            override public function set data(value:Object):void {
                super.data = value; // set the Item Renderer's data object
                // inject additional logic
                if (data.age < minAge) {
                    listLabel.setStyle("color",0xFF0000);
                } else {
                    listLabel.setStyle("color",0x000000); // default value
                }
            }
        ]]>
    </mx:Script>
    <mx:Label id="listLabel"
        text="{data.name + ' (' + data.age + ')'}"/>
</mx:HBox>

Note: It is important to remember that Item Renderers are recycled and as such, their property values may reflect a condition met by the previous "user" of the Item Renderer instance (i.e. the Data Item). Therefore, it is important to reset properties to the default value when conditional logic fails. In the previous example, the reset is accomplished by setting the label's font color back to black (0x000000) when data.age >= 21.

In the previous example, we utilized a property of the data object (data.age) and a hard-coded value (21) to dictate the item's appearance. However, certain scenarios may require access to property values outside of an Item Renderer's scope to determine the appearance.

Example: The value of an HSlider in conjunction with the age property of the data object (data.age) should dictate the font color of each item's label.

This scenario requires the following:

1. Create a new public property for the list-based control exposed via a getter and setter

By extending an existing class and adding a new public property, our list-based control will have a place to store the value of an external property (i.e. the value of the HSlider's value property).

// MyList.as extends List

package com.flexdevelopers
{
    import mx.controls.List;

    public class MyList extends List
    {
        private var _minAge:Number; // new property
        
        public function MyList()
        {
            super();
        }

        // new property getter and setter methods
       
        public function get minAge():Number {
            return _minAge;
        }
        
        public function set minAge(value:Number):void {
            _minAge = value;
        }
        
    }
}

2. Bind the new list-based control's public property (MyList.minAge) to the value of the desired external property utilizing Flex's data-binding utility

Data-binding will provide real-time synchronization of the new public property (minAge) with the external property's value (i.e. the HSlider's value property)

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:comps="com.flexdevelopers.*"
    layout="vertical">
    
    <mx:Script>
        <![CDATA[
            import com.flexdevelopers.MyList;
        ]]>
    </mx:Script>

    <mx:ArrayCollection id="ac">
        <mx:Array>
            <mx:Object name="tom" age="12" hair="brown"/>
            <mx:Object name="sally" age="21" hair="green"/>
            <mx:Object name="kate" age="16" hair="yellow"/>
            <mx:Object name="bill" age="22" hair="brown"/>
            <mx:Object name="chriss" age="23" hair="green"/>
            <mx:Object name="yarb" age="34" hair="yellow"/>
        </mx:Array>
    </mx:ArrayCollection>
    
    <comps:MyList width="100%"
        dataProvider="{ac}"
        itemRenderer="com.flexdevelopers.ListIR"
        minAge="{hslider.value}"/> <!-- minAge is bound to hslider.value -->
    
    <mx:HBox>

        <mx:HSlider id="hslider"
            minimum="10" maximum="50"
            value="20"
            snapInterval="1"
            liveDragging="true"/>
            
        <mx:Label text="Minimum Drinking Age: {hslider.value}"/>
        
    </mx:HBox>

</mx:Application>

3. Provide the Item Renderer with access to a ListData object

To access the value of our new public property from within an Item Renderer instance, our Item Renderer must implement the IDropInListItemRenderer interface. This ensures a reference to the Item Renderer's owner (the list-based control) is available to the Item Renderer, and consequently, so is our new public property.

<!-- ListIR.mxml -->

<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml"
       implements="mx.controls.listClasses.IDropInListItemRenderer">
    <mx:Script>
        <![CDATA[
            import mx.controls.listClasses.BaseListData;
            import mx.controls.listClasses.ListData;
            import com.flexdevelopers.MyList;
            
            // property required of IDropInListItemRenderer exposed thru a public getter & setter
            private var _listData:BaseListData;
            
            // getter & setter methods
            public function get listData():BaseListData {
                return _listData;
            }
            
            public function set listData(value:BaseListData):void {
                _listData = value;
            }
            
            override public function set data(value:Object):void {
                super.data = value;
                // retrieve the value of the list-based control's new public property
                var minAge:Number = (listData.owner as MyList).minAge;
                if (data.age < minAge) {
                    listLabel.setStyle("color",0xFF0000);
                } else {
                    listLabel.setStyle("color",0x000000);
                }
            }
        ]]>
    </mx:Script>
    
    <mx:Label id="listLabel"
        text="{data.name + ' (' + data.age + ')'}"/>
    
</mx:HBox>

4. Make a call to the invalidateList method when the source of our new, bounded public property is changed (i.e. the HSlider value property changes)

By calling MyList.invalidateList() each time the HSlider value changes, we ensure that the conditional logic of the Item Renderer is re-evaluated. InvalidateList forces each Item Renderer instance of a list-based control to call the data setter method.

// update the new property's setter method to include invalidateList()
// IMPORTANT: Without calling invalidateList, a change to the HSlider will not impact 
// the appearance of the currently visible list items

public function set minAge(value:Number):void {
   _minAge = value;
   invalidateList();
}

See it in action (view source is enabled):

Flex Basics - XMLListCollection

2009-05-22T08:39:00.000-06:00

Depending on the characteristics of a data set, data can be modeled in a linear or hierarchical fashion.

Linear data (aka flat or list-based data) typically represents the attributes (or properties) of an individual entity (item).

In turn, multiple items can be aggregated into a list and stored in an Array. An Array provides a mechanism for storage, manipulation and retrieval of linear data within a Flex application.

Note: Arrays can also store hierarchical data (i.e. objects composed of other objects or simple xml objects) but you'll find linear data to be more common.

Other data sets represent nested levels of information (hierarchical data). ActionScript provides two native datatypes for working with hierarchical data – XML and XMLList. The contents of each can be accessed and manipulated as needed utilizing the public API (properties and methods) corresponding to the supporting ActionScript class – XML or XMLList.

XML was designed to support the transport, storage and description of hierarchical data using custom markup. The XML class contains methods and properties for working with a single, well-formed XML document.

As one might guess, an XMLList is simply a list of XML objects. Looking closely at the methods of the XML class, you’ll notice that many operations potentially result in a match against multiple XML nodes (i.e. attributes(), children(), descendants(), etc). With each matching node representing the format of a well-formed XML document, it makes sense to provide a class designed to hold one or more XML objects. That class is the XMLList class.

Note: XML and XMLList classes support E4X operations that may also return a list of XML objects (XMLList). This includes shorthand operations such as (.) or (..) used for retrieving children or descendant nodes respectively or predicate filtering.

As a Flex developer, your intent, most likely, is to eventually render some, if not all, of your data on the screen. Whether your data is linear or hierarchical in nature, Flex provides the following “data provider” components suited for the task at hand:

List-based controls (DataGrid, List, TileList and HorizontalList) for linear or flat data structures (Arrays)
Trees and menu-based controls (Tree, Menu, MenuBar, PopUpMenuButton) for hierarchical data structures (XML or XMLList)

Data provider components require a reference to the data for display. This reference is captured in the dataProvider property of the data provider component instance.

<!-- MXML -->

<List id=”myList” dataProvider=”{myArray}” />
<Tree id=”myTree” dataProvider=”{myXMLList}” />

// ActionScript

var myList:List = new List();
myList.dataProvider = myArray;

var myTree:Tree = new Tree();
myTree.dataProvider = myXMLList;

At first glance, this appears to be an acceptable use of data binding. However, using raw data objects (Array, XML and XMLList) as a data provider for a UI control is not considered a best practice.

Instead, it is recommended that collections are used in place of raw data objects for the following reasons:

Changes to the data stored in a collection are immediately reflected in the UI control
Collections provide a "view" of the underlying data that can be sorted or filtered

Therefore, an ArrayCollection should be used in place of an Array (see related blog entry) and an XMLListCollection should stand in for an XMLList object.

XMLListCollection

Similar to an ArrayCollection, XMLListCollection extends the ListCollectionView class which implements the ICollectionView and IList interfaces. 3 members of the ICollectionView interface play an integral role in the implementing class' ability to support data binding:

2 methods: addEventListener() & dispatchEvent()
1 event: collectionChange

When the [Bindable] metadata tag is used with a collection, Flex generates code behind the scenes required to make the collection "bindable". This code is dependent on the ability to register an event handler triggered by a event dispatched when the data object changes (aka event listener). By extending ListCollectionView which implements ICollectionView, XMLListCollection becomes an eligible participant in the data binding game.

For a more detailed look at the guts of data binding, check out Michael Labriola's presentation entitled Diving in the Data Binding Waters

To create an XMLListCollection, 3 techniques are available:

// creating an empty XMLListCollection
private var myXMLListCollection:XMLListCollection = new XMLListCollection();

// passing an existing XMLList into an XMLListCollection via the constructor
private var myXMLListCollection:XMLListCollection = new XMLListCollection(myXMLList);

// assigning an existing XMLList to the source property of an XMLListCollection
private var myXMLListCollection:XMLListCollection = new XMLListCollection();
myXMLListCollection.source = myXMLList;

After being "wrapped" by an XMLListCollection, the majority of the XMLList methods are still available including (but not limited to):

- attributes
- child
- children
- copy
- descendants
- elements

Note: E4X shorthand operations also apply to an XMLListCollection

But now your plain old hierarchical data storage container (XMLList) has been infused with new powers including data binding (as mentioned previously) and new properties / methods.

New properties:

- filterfunction
- sort

New methods:

- addAll
- addAllAt
- addEventListener
- addItem
- addItemAt
- getItemAt
- getItemIndex
- refresh (for use with filterfunction and sort properties)

Note: These are the same properties and methods employed by an ArrayCollection. Sharing the same super class (ListViewCollection), ArrayCollection and XMLListCollection behave in a very similar manner, however, it is typically the UI control that will dictate the type of collection required as a data provider. Remember, list-based UI controls (DataGrid, List, TileList and HorizontalList) require linear (or flat) data structures (ArrayCollection) while tree or menu-based controls (Tree, Menu, MenuBar, PopUpMenuButton) require hierarchical data structures (XMLListCollection).

In addition to the enhanced API provided by a collection, wrapping an XMLList inside an XMLListCollection provides 2 very powerful features:

filtering
sorting

A collection provides a "view" of the underlying data (Array or XMLList) that can be filtered and sorted without affecting the underlying data. It is this "view" in which UI controls are bound to. Alter the "view" using the filterfunction or sort properties along with the refresh() method and the changes are immediately reflected in your UI control.

View Sorting & Filtering an XMLListCollection Example

Flex Principles - Application Development

2009-04-28T08:45:00.001-06:00

I became a developer so I could build things. I was tired of attending misguided meetings, writing requirements documents that nobody read and talking about what a group of uninformed individuals thought needed to be built. I just wanted to build cool stuff and provide immediate value.

Unfortunately, I quickly learned that application development involves more than writing code. Successful application development is a process involving multiple phases and multiple participants with a range of skills.

To succeed, it’s important to adopt a development process that works for your team, your company and the types of projects you’re involved with. Without a process, the risk of project failure is high. The ideal process doesn’t get in your way, covers only the necessary bases and gives you the best chance for success.

In my experience, I’ve found a "front-end first" approach coupled with small design and development cycles (iterations) to be enjoyable, effective and efficient.

In this blog entry, I will outline the process, tools and platform I use to define, build and deploy small to medium-sized rich internet applications (RIA) using Adobe Flex, ColdFusion and MySQL. This process is neither revolutionary nor specific to RIA development. In fact, many of the steps I follow may also be applied to traditional web development (HTML, CSS, JavaScript, PHP, ColdFusion, .NET, etc).

In addition, to effectively demonstrate the process, I will reference the project artifacts created for each phase of a recently completed Flex project: FlexWire Demo App.

Process

The steps involved to create an application cross 5 phases:

Application planning
Application user interface (UI) layout and structure
Application design and development
Application testing
Application deployment

Application Planning

Entrance criteria: An idea, a directive, an opportunity, a problem, whatever...

Tool(s): Project Profile Form

It’s difficult to create anything without a basic understanding of the business objectives. During the planning phase, it’s important to identify these objectives at a high-level.

Step#1: Define the business objectives

Example: Provide a mechanism to organize and distribute related news articles to newsletter subscribers via email.

To satisfy the business objectives, an application must support a range of user and system scenarios. User scenarios help define the functionality required of an application from a user perspective. Think about the tasks involved in achieving the business objectives. These become your user scenarios.

Step#2: Define user scenarios

It is important to group or categorize user scenarios in a logical manner to minimize confusion and support the UI layout and structure phase. These categories may turn out to be synonymous with user roles.

Example: Manage Newsletters (user role) - Create Newsletter, Modify Newsletter, Delete Newsletter

Exit criteria: Completed Project Profile Form

Application UI layout and structure

Tool(s): Balsamiq Mockups, writemaps.com

After the planning phase, we should have a good understanding of the application’s purpose. However, the UI layout and structure phase will help us flesh out additional requirements while designing each view of the UI.

A view represents a unique combination of Flex UI components (containers and controls) and business logic utilized to perform a group of related tasks. By organizing our user scenarios into logical groupings (i.e. user roles) during the planning phase, the characteristics of each UI view should be somewhat evident.

Preliminary design of each view is attained through mockups. Iterations occur until each mockup accurately reflects the layout and structure of the proposed view and visually demonstrates the functionality required to perform the desired tasks.

Step#1: Create UI mockups

By following this approach, we design the UI while uncovering functional requirements overlooked in the planning phase. New user scenarios discovered during this step should be documented.

Each mockup should represent a unique view of your UI. However, as the number of permutations increase (through view states or navigation containers), this may not be feasible. Use your best judgment.

Example: FlexWire mockups - newsletters view, issues view, articles view, subscriptions view, categories view, roles view, templates view

Note: It may be necessary to supplement your mockups with notes to provide details that may be difficult to capture in a visual mockup. For example: "The contents of ComboBox #2 (US Cities) depend on the selectedValue of ComboBox #1 (US States)."

In addition to UI mockups, it is important to discuss the relationship of each view to one another. This can often be accomplished by building a simple wireframe. Wireframes may also be used to dictate application workflow if applicable.

Step#2: Create application wireframe

Once a wireframe is complete with the supporting mockups, we will have a solid understanding of the project’s scope and the flow of the application. Only now can an accurate development estimate be derived.

Example: FlexWire wireframe

Exit criteria: wireframe, mockups

Application design and development

Tool(s): CFEclipse, Flex Builder, Subclipse, MySQL Admin, FlexUnit, MXUnit, Stax.net

Additional Resources: Tour De Flex, Flex Style Explorer, Flex Skins, Flex Language Reference, Cairngorm, Transfer, ColdSpring

Thanks to our wireframe and mockups, we know what needs to be created and how the features are organized within the application. However, before any code can be written, a suitable application platform must be in place.

Step#1: Set up your application platform

A suitable platform includes a separate environment to support your development, testing and production activities. At a minimum, I would recommend 3 environments:

Development environment (created locally for each designer / developer)
Staging (testing) environment
Production environment

To maintain consistent and predictable results, it is important to ensure that each environment is identical from a configuration, code and data perspective.

Note: Environment setup includes, among other things, configuration of a web server, application server and a database server. Initial setup, frequent synchronization and ongoing maintenance of each environment can prove to be very time consuming. I prefer to offload these activities if possible. Maybe you have a server engineer at your disposal. If not, I've found Stax.net to be a great option for quickly and easily setting up and replicating Java server configurations (including ColdFusion) across multiple environments. Stax is a fully-managed platform deployed and hosted on top of Amazon's EC2 cloud computing service.

With each environment in place, a source code repository is required. I won't go into the benefits of source control, however, suffice it to say that without source control you are taking an unnecessary risk while limiting developer productivity. Whether you are working with a team or not, setup a Subversion (SVN) repository and start importing source code from the start.

Note: For RIA development, it is only necessary to import source code files into your SVN repository. The files generated from a Flex release build (release build artifacts such as the application SWF and the wrapper HTML) should not be captured in source control.

With a platform in place, a foundation for development must be established. Architectural frameworks provide a starting point for development and enforce consistent development practices. Many architectural frameworks also support an MVC architecture. MVC is a standard for building RIA applications.

Step#2: Establish an architectural framework

Without a framework, developers can spend a lot of time on the “plumbing” of an application. This is no longer necessary as there are a number of free solutions available. For RIA development, I choose to use Cairngorm on the client-side and ColdSpring & Transfer on the server-side.

With a framework in place, we are ready to finally write some code.

Step#3: Architect and design the user interface (the V in MVC)

Sticking with the "front-end first" approach, build the UI layout and structure by replicating each mockup in Flex using MXML and ActionScript. You'll find that most of the code written in this step will include MXML as it is the preferred method for defining application layout and structure. Also, apply any necessary UI effects and transitions.

Once the layout and structure of the UI is in place, style and/or skin the user interface via CSS and/or ActionScript. This may involve multiple iterations to secure the right look and feel.

UI development should occur within the development branch of SVN (typically SVN trunk) - specifically in trunk >> Flex according to this example.

While building the UI, additional requirements may be uncovered. This is unavoidable. Be sure to document them as they may have an impact on your delivery schedule.

Note: During this step, use of ActionScript should be limited to view logic (i.e. navigating and/or changing view states) and/or styling/skinning. Business logic should be implemented during the next step. Also, in some instances, your UI may require data to achieve the proper look and feel. Hard-coded data structures can help populate data provider controls (i.e. ComboBox, DataGrid, List, Tree, etc) with little effort.

Once the user interface is in place and approval has been obtained, it is time to build out the features of the application.

Step#4: Develop and unit test application features (the M&C in MVC and the application services (the service layer))

Each user scenario defined during the planning phase or discovered subsequently represents a feature of your application. Features should be packaged into short iteration cycles (2 weeks or less) and prioritized. It’s important to identify dependencies as well when determining iteration schedules. For example, Feature B depends on Feature A.

With an iteration schedule in place, feature development can begin. Feature development typically requires use of:

ActionScript and MXML for the controller and model layer within the Flex client

ColdFusion (or any other server-side scripting language) and SQL for the application service layer (Note: Transfer will take care of the majority, if not all, of the SQL required to perform basic CRUD operations)

SQL in the form of DDL (Data Definition Language) and DML (Data Manipulation Language) required to build and populate the database

Each feature will include a set of classes - ActionScript classes and/or ColdFusion classes (CFCs). A unit test for each class is required to validate expected behavior. It is much easier to identify and resolve errors at the class level rather than the feature or application level. FlexUnit and MXUnit can help with ActionScript and ColdFusion unit testing respectively. Unit tests should be performed locally in the development environment. Once all unit tests are successful, "developer" testing should occur to verify the overall behavior of each new feature.

The completion of each iteration delivers a set of fully-functional features from the UI all the way to the database. At this point, code should be copied from the development branch (SVN trunk) to a new branch created specifically for the current iteration. The contents of this new branch should be deployed to the staging environment for additional testing (see next phase).

Each development cycle (iteration) yields a new SVN branch. For example:

Exit criteria: MXML, ActionScript, CSS, CFML, SQL, DDL / DML committed to SVN trunk and copied to an iteration branch; Unit tests and results

Application testing

Tool(s): FlexMonkey, Selenium-Flex API, Trac

A former boss of mine once asked me why testing was necessary. He told me "if you built it right in the first place, testing was unnecessary and only a waste of time." Technically, he's correct. Unfortunately, most (if not all) developers rarely get everything "right" out of the gate so I'll dismiss his ignorant comment.

Although each class has been tested at an atomic level via unit testing and the functionality of each feature has been verified, unforeseen behavior can and does occur once ALL of the pieces are put together.

Test each feature in the context of the entire application in the staging environment. Also, regression testing is often required to ensure that new functionality does not break existing functionality. Regression testing can be time-consuming and mind-numbing. Therefore, automated test tools are essential. Look into FlexMonkey and the Selenium-Flex API.

Bugs found in the staging environment will need to be logged in Trac and fixed immediately. Fixes should be applied directly to the code found in the iteration branch. Once bug fixes are verified and testing of the iteration is complete, merge the changes back into the development branch and create an SVN "tag" (snapshot) representing a clean and functional version of the iteration branch. Each tag represents a candidate for release and, if appropriate, may be deployed to production (see next phase).

Note: Development should never occur within a tag.

Staging is also a good place to perform User Acceptance Testing (UAT) if desired.

Exit criteria: Test cases and results; a tag for each successfully-tested iteration; bug fixes merged back into the development branch (SVN trunk)

Application deployment

Tool(s): Ant, Maven

With each iteration complete and tested, it is time to deploy your application to production. Automation of this phase can save time and minimize errors. Build scripts (ANT or Maven) can perform the following deployment activities:

Checkout code from the appropriate SVN tag

Filter out irrelevant files (i.e. SVN core files)

Run SQL scripts (DDL and/or DML) to create the required database structure and generate seed data

Copy/Move files to the production server

Exit criteria: A fully-functional application inline with the user requirements, deployed to a production environment, and backed-up in a source code repository

Afterthought: In an attempt to redefine the designer / developer workflow, Adobe is proposing an approach to application layout and design involving a designer's use of existing Adobe tools (Photoshop, Illustrator, Fireworks) to generate the design and layout of each view and, with the release of Flash Catalyst, supplement these design assets with visual effects and transitions. The output being the front-end of a Flex application inline with the designers vision, ready for development and abstracted from the application code in the form of design components. I have yet to explore this approach and currently rely on mockups, MXML, publicly-available themes and styles / skins implemented through conventional CSS and ActionScript to create the layout, structure and style of a Flex application. See related blog entry – Application Design.

Where to go from here: Go get a beer...or two

Flex Basics - ArrayCollection

2009-03-13T08:29:00.001-06:00

Arguably one of the most useful constructs available to a Flex developer is an Array. Designed to store data of various types accessible via a numbered index, the Array class provides a useful mechanism for data storage and retrieval.

As such, an Array would appear to satisfy the data provider needs of any list-based control. However, it does not. Incompatibility with data binding makes an Array a poor choice of data provider. Fortunately, Flex provides a suitable alternative - ArrayCollection. An ArrayCollection provides all the features of an Array plus more.

To understand an ArrayCollection, one must first understand an Array.

Array

From Wikipedia, an Array "is a data structure consisting of a group of elements that are accessed via indexing". Arrays can store simple data types (primitives) such as number, boolean or string or complex data types such as other Arrays or objects.

In fact, Arrays defined in ActionScript (or MXML) are not strongly-typed and can store various types of data.

private var myArray:Array = new Array();
myArray[0] = "Tom"; // string
myArray[1] = 2; // number
myArray[2] = new Object(); // object

Array elements can be retrieved or set using array access notation utilizing the zero-based index value of the desired element.

// retrieving the value of an array element
private var name:String = myArray[0];

// setting the value of an array element
myArray[0] = "Bill";

Note: Arrays are designed to use a numbered index. If you intend to retrieve data via a named index (i.e. Associative Array or HashMap), you may want to consider using an object as a data container. Unlike other classes, the Object class is dynamic - meaning arbitrary properties can be added to serve as keys.

var myObject:Object= new Object();
myObject.name = "Tom";
myObject.age = 27;

If your HashMap keys include spaces, use array access notation.

var myObject:Object= new Object();
myObject["first name"]= "Tom";

HashMap values can be retrieved or set using dot notation (if no spaces in the key) or array access notation.

// retrieving the value of an object via an named index using dot notation
private var name:String = myObject.name;

// setting the value of an object property using dot notation
myObject.name = "Bill";

// retrieving the value of an object via an named index using array access notation
private var firstName:String = myObject["first name"];

// setting the value of an object property using array access notation
myObject["first name"] = "Bill";

Arrays are dynamic and, therefore, can be resized simply by adding or removing elements.

// adds an element to the end of an array and increases the array length by one
myArray.push("Phil");

// removes the last element from an array and decreases the array length by one
myArray.pop();

ActionScript supports two methods for creating Arrays, each with a variety of syntaxes:

Method #1 – Create an Array by defining (or not defining) the number of elements

// creates an array with zero elements (this is the default when no argument is passed 
to the Array constructor)
private var myArray:Array = new Array();

// creates an array with 10 elements
private var myArray:Array = new Array(10);

// creates an array with zero elements using literal notation
private var myArray:Array = [];

Method #2 – Create an array by defining the array elements and their values

private var myArray:Array = new Array("red",2);
private var myArray:Array = ["red",2];

Note: The Array class can support both initialization techniques by providing two class constructors. The appropriate constructor is used based on the argument value(s) (or lack thereof).

Arrays can also be built using MXML:

<mx:Array id="myArray"/> <!--creates an array with zero elements-->

<mx:Array id="myArray"> <!--creates an array with three elements-->
   <mx:String>myString</mx:String> <!--string-->
   <mx:Number>98</mx:Number> <!--floating-point number-->
   <mx:Object name="Phil" age="27"/> <!--object-->
</mx:Array>

Like everything in Flex, an Array is an object and as such it contains a handful of useful properties and methods.

One property familiar to all developers is the length property. The length property represents the number of array elements.

private var myArray:Array = new Array(10);
private var numberOfArrayElements:uint = myArray.length; // 10

Note: Although each Array element contains an undefined value in this scenario, the length is still 10.

The length property can be very handy. One popular technique involves using the length property to dictate the number of loops included in a For Loop.

for (var i:uint; i < myArray.length; i++) {
   trace(myArray[i]);
}

Note: You can truncate an Array by setting the length property to a value less than the number of array elements. This is not true of an ArrayCollection as the length property is read-only.

By utilizing the methods of the Array class, you can perform a number of operations on the Array elements or the Array itself. Popular Array methods include:

* filter
* indexOf
* join
* push
* reverse
* slice
* sort
* toString

However, despite all of an Array's powerful features, the inability to support data binding is a significant shortcoming. Fortunately, Flex provides an ArrayCollection.

ArrayCollection

Per the Flex Language Reference, an ArrayCollection is a "wrapper class that exposes an Array as a collection that can be accessed and manipulated using the methods and properties of the ICollectionView or IList interfaces".

Two members of the ArrayCollection class are integral to the ArrayCollection's ability to support data binding - The collectionChange event and addEventListener method. To participate in data binding, an object must be able to:

1. dispatch an event when something changes
2. allow other objects to listen and respond to events

The ArrayCollection satisfies both thanks to the collectionChange event and the addEventListener method and will support data binding when given a compiler directive to do so using the [Bindable] metadata tag.

// creates a bindable ArrayCollection with zero elements
[Bindable] private var myArrayCollection:ArrayCollection = new ArrayCollection();

An ArrayCollection can be created in one of three ways:

// creating ArrayCollection with zero elements
private var myArrayCollection:ArrayCollection = new ArrayCollection();

// passing an existing Array into an ArrayCollection via the constructor
private var myArrayCollection:ArrayCollection = new ArrayCollection(myArray);

// assigning an existing Array to the source property of an ArrayCollection
private var myArrayCollection:ArrayCollection = new ArrayCollection();
myArrayCollection.source = myArray;

Either method successfully wraps an Array inside an ArrayCollection and as such, extends the capabilities of an Array.

Note: In Flex, ActionScript classes can have optional constructor parameters only. MXML does not enforce required constructor parameters, therefore, if a constructor parameter is required to create a new instance of a class, provide a default value. In the case of an ArrayCollection, the default argument for the source parameter is NULL, hence, an empty ArrayCollection is created when the source parameter is omitted.

Extending the ListCollectionView class that implements the ICollectionView and IList interfaces, an ArrayCollection inherits a handful of properties, methods and events. Therefore, your plain old Array now has a new set of functionality.

New properties include (but not limited to):

* filterFunction
* length
* list
* sort
* source

New methods include (but not limited to):

* addEventListener
* addItem
* addItemAt
* contains
* getItemAt
* getItemIndex
* refresh
* removeAll
* removeItemAt
* setItemAt

Once an Array is wrapped inside an ArrayCollection, the properties and methods of the Array class are no longer accessible unless you access them through the Array object directly. For example, if you really want to use the Array's push method, you could do the following:

myArrayCollection.source.push("new element");

This would require using the ArrayCollection's refresh method to trigger data binding.

myArrayCollection.source.push("new element");
myArrayCollection.refresh();

However, you could always use the ArrayCollection's addItem method instead.

myArrayCollection.addItem("new element");

Realize that every ArrayCollection contains an Array as the data source. If you create an empty ArrayCollection and add elements using the methods of the ArrayCollection rather than assigning an Array to the source property of an ArrayCollection, an Array is created for you.

Any data manipulation performed on an ArrayCollection will be reflected in the underlying Array and vice-versa, however, it is important to note that manipulating an Array directly will not be reflected inside an ArrayCollection until you perform a refresh of the ArrayCollection using the ArrayCollection's refresh method.

Using an ArrayCollection in place of or in tandem with an existing Array provides Flex developers with a valuable and responsive data storage and retrieval mechanism.

Flex Basics - Item Renderer

2009-02-13T14:05:00.001-07:00

One characteristic of a well-designed Flex application is the ability to present data in a visually-compelling manner. Outside of the database and within the model layer of a Flex application, data is stored in a flat or hierarchical fashion (i.e. ArrayCollection or XMLListCollection). Although a great format for data storage or transport, flat or hierarchical data structures lack significant meaning to the average user.

Fortunately, Flex provides a handful of UI controls designed to render flat or hierarchical data in an intuitive, meaningful and compelling manner within the UI. These UI controls include those that extend the ListBase class and are commonly referred to as list-based controls. Since a collection of data can also be referred to as a list, the name makes sense.

List-based controls include DataGrid, List, Tree, Menu, TileList and HorizontalList. Each list-based control contains a public dataprovider property. The value of the dataprovider property represents the data collection (or list) that requires the list-based control to render its contents in the UI.

Just as a list has items, so does a data collection. An item is analogous with a row or a record in a flat data set or a node within a hierarchical data set (i.e. XML). Data collections contain one or more items. In turn, each item may contain one or more properties.

The following example illustrates storage of flat data:

By default, list-based controls render the contents (properties) of each item (row or record) as simple text. In many scenarios, a textual rendering is sufficient. In others it is not.

Let's examine a scenario where you've selected a DataGrid control to render data stored in an ArrayCollection. In this scenario, your ArrayCollection houses a "list" of 10 employees. Each employee "record" has 4 properties - firstName, lastName, age, photo. Each employee property with the exception of the photo property fits nicely with the DataGrid's default textual rendering.

To customize the rendering format of an item property (i.e. employee photo), utilize the itemrenderer property. Item Renderers control the display of data for each item property. If you do not specify an Item Renderer, the default is used and the item property is displayed as simple text.

Since simple text is not an acceptable display for the employee photo property in our previous example, a custom Item Renderer is required.

3 types of custom Item Renderers exist:

1. Drop-In Item Renderers
2. Inline Item Renderers
3. External Item Renderers

Each type requires access to the data in which it will render and, therefore, any component acting as an Item Renderer must implement the IDataRenderer interface. The IDataRender interface enforces the implementation of a public getter and setter method for the data property. Without these methods, the list-based control that contains the data (host component) cannot pass item data to the component acting as an Item Renderer.

Fortunately, all Flex containers and many Flex controls implement the IDataRenderer interface and contain the required data property. To be sure, you may want to check the inheritance tree of the component you are considering as an Item Renderer. The inheritance tree can be found for each Flex component at the Flex 3 Language Reference.

Drop-In Item Renderers

Several UI controls within the Flex SDK were designed to serve as Drop-In Item Renderers - Button, CheckBox, DateField, Image, Label, NumericStepper, Text, TextArea, and TextInput. These controls all implement the IDropInListItemRenderer interface.

Drop-In Item Renderers are generic in nature and don't rely on specific data fields to render data. This allows them to be used with a wide range of data sets, hence, the term “drop-in”. Drop-In Item Renderers can be “dropped-in” to any list-based control regardless of the dataprovider’s data properties.

In our previous example, the employee photo property requires use of a custom Item Renderer to render properly in the UI. In this scenario the Image component satisfies our rendering needs out of the box. Implemented as a Drop-In Item Renderer, the Image component takes any data property regardless of name and uses it as the Image component's source property value. Assuming our employee photo property contains a valid image path, the Image Drop-In Item Renderer will work perfectly and resolve the image path as an image in the UI.

<!-- Drop-in Item Renderer: Image control -->
<mx:DataGridColumn dataField="photo" 
                   headerText="Employee Photo" 
                   itemRenderer="mx.controls.Image"/>

Drop-In Item Renderers are simple and easy to use and satisfy specific use cases nicely. However, they provide no flexibility whatsoever. If your needs are not satisfied by a Drop-In Item Renderer, you must create your own Item Renderer as an inline component or an external component.

Inline Item Renderers

Generally used for simple item rendering requiring minimal customization, inline Item Renderers are defined as a component nested within the MXML of your list-based control.

It is important to note that Item Renderers nested within the itemrender property of a list-based control occupy a different scope than the list-based control. Any attempt to reference members (properties or methods) of the parent component from the nested Item Renderer component will result in a compile-time error. However, references to the members of the parent component can be achieved by utilizing the outerDocument object.

<mx:DataGrid id="myGrid" dataProvider="{gridData}">
   <mx:columns>
      <mx:DataGridColumn headerText="Show Relevance">
         <mx:itemRenderer>
            <mx:Component>
               <mx:Image source="{'assets/images/indicator_' + data.showRelevance + '.png'}" 
                         toolTip="{(data.showRelevance == 1) ? 'On' : 'Off'}"
                         click="outerDocument.toggle()" />
            </mx:Component>
         </mx:itemRenderer>
      </mx:DataGridColumn>
   </mx:columns>
</mx:DataGrid>

Remember, rules of encapsulation still apply. Mark all properties or methods public if you want them accessible by your inline Item Renderer. In the previous example, the toggle() method must have a public access modifier to expose itself to the inline Item Renderer.

public function toggle():void

Inline Item Renderers can also be reusable by creating a named component instance outside of the list-based control. This component must have an id property and contain the rendering logic of the Item Renderer. Using data bindings, the component is assigned to the itemrenderer property of one or more data properties of a list-based control.

<!-- Reusable inline Item Renderer -->
<mx:Component id="ImageRenderer">
   <mx:VBox width="100%" height="140"
            horizontalAlign="center" verticalAlign="middle">
      <mx:Image source="{'assets/'+data.image}"/>
      <mx:Label text="{data.image}" />
   </mx:VBox>
</mx:Component>

<!-- Used within a list-based control-->
<mx:DataGridColumn headerText="Image"
                   dataField="image" width="150"
                   itemRenderer="{ImageRenderer}"/>

In the previous example, note that the Item Renderer component contains 2 UI controls – Image and Label. When using multiple controls within an Item Renderer, a layout container is required. In this example, a VBox was used.

External Item Renderers

As the complexity of your Item Renderer increases, you may want to create a custom MXML component or ActionScript class to encapsulate the Item Renderer.

Once built, the Item Renderer component is assigned to the itemrenderer property of the appropriate list-based control property. Note that the path to the Item Renderer component is not relative to the current file but rather is relevant to the MXML file containing your Application tags.

<!-- Custom Component: ImageRender.mxml -->
<mx:VBox width="100%" height="140"
         horizontalAlign="center" verticalAlign="middle">
   <mx:Image source="{'assets/'+data.image}"/>
   <mx:Label text="{data.image}" />
</mx:VBox>

<!-- Used within a list-based control-->
<mx:DataGridColumn headerText="Image"
                   dataField="image" width="150"
                   itemRenderer="components.ImageRenderer"/>

There is very little difference between an external Item Renderer and an inline Item Renderer. However, external Item Renderers are ideal for modularity, reuse and maintainability.

To continue the discussion of Item Renderers and take a much closer look, read Peter Ent's 5 part article entitled Understanding Flex itemRenderers or see an example of an Item Renderer in practice.

Flex Principles - Application Design

2009-01-11T20:34:00.001-07:00

Today application developers face an ever-increasing challenge of quickly building robust, feature-rich applications that look great.

At a high-level, an application has two fundamental components - application design and application functionality. While each represent a broad category of subjects, application design can be summarized as the style and layout of your application while application functionality includes the features offered.

As developers, we tend to put a lot of emphasis on the features of an application. This is understandable. Developers develop; designers design; and a few exceptional individuals do both. However, in most cases, developers lack design skills and not all projects can afford the luxury of a professional designer. Therefore, developers are left with the arduous task of developing highly-functional applications with attractive and user-friendly interfaces.

Fortunately, for the design-challenged developer, Flex ships with a number of attractive themes (Aeon Graphical, Haloc, HaloClassic, Ice, Institutional, Smoke, Wooden) consisting of default styles and skins for all of your application components. Furthermore, each style and skin can be customized with relatively little effort using Flex Builder's CSS Explorer.

If your design needs are still not met, check out ScaleNine's library of Flex themes or hire a designer with an eye for fonts, colors and the subtle details required to achieve a professional design and differentiate or brand your application.

Equally important, if not more so, to the style of your application is the layout. Application layout contributes to the usability of your application. Successful applications are usable applications.

Application layout helps developers:

1. organize and group functionality relevant to specific business tasks
2. dictate work flow through the use of complimentary application views
3. enforce a standard and consistent display of application components throughout your application

There are many tools available to help you define the layout of your application. Some are free (or almost free) - pencil / paper, whiteboard, etc; others are not - Visio, Photoshop, etc.

Unfortunately, with the majority of a developer's time committed to building the features of an application, little time remains to design the layout of an application. Therefore, the layout design process must be efficient.

To ensure efficiency, I would recommend finding a simple tool designed for one thing - creating layout mock ups.

Balsamiq Mockups fits the bill nicely. Mockups provides a clean and intuitive interface designed for creating fast and informal layout mock ups. Plus, it is fun, easy to use and cheap. It was also built using Flex!

A desktop version of Mockups deployed using AIR is FREE with the ability to unlock additional features for only $79.

Referred to as a "fast tracking prototype tool", you'll find all the essential features required to "mock up" your user interface and nail down your application layout...FAST.

Features include (but not limited to):

- component look up (quick search)
- component drag & drop
- component positioning
- component resizing
- component formatting
- mock up printing
- mock up importing
- mock up exporting
- mock up saving

The Mockups interface is comprised primarily of 2 components:

1. a scrollable library of mock up components
2. a canvas where you will build your layout mock up

Once complete, your mock ups will look similar to this:

After your layout concepts have been finalized and approved, you must architect the view using Flex Builder. This involves selecting the appropriate Flex components (containers and controls) or building your own custom components.

Your mock ups will serve as your guide to the placement and positioning of your Flex components.

Remember, an application is ultimately judged by both its design and its functional capabilities. Neglecting one or the other will most likely result in project failure, so allocate your time wisely and use the right tools for the job.

Flex Basics - Data Binding

2008-11-23T20:45:00.000-07:00

There are many reasons to choose Flex as your development platform for web-based software applications. Everyone is already familiar with Adobe's claim of a superior user experience delivered via Flex's rich client (aka fat or thick client). However, developers and project sponsors alike are drawn to features of the Flex SDK which promote rapid development of feature-rich, robust applications.

Data binding is a great example of one of these features.

Exposed through the MXML API, data bindings allow developers to "bind" the value of one object property (destination property) to the value of another object property (source property) using MXML or MXML + inline ActionScript.

<mx:Binding source="source.text" destination="destination.text" />

<mx:TextInput id="source" />
<mx:TextInput id="destination" />

OR 

<mx:TextInput id="source" />
<mx:TextInput id="destination" text="{source.text}" />

By utilizing data bindings, any change to the value of the source property is immediately reflected in the destination property. It is important to note that data bindings are "one way". Source property changes affect the destination property value but not vice versa.

One benefit of using the <mx:Binding> tag instead of inline ActionScript is the ability to bind a property to multiple source properties. If any of the source properties change so does the destination property.

<mx:Binding source="source.text" destination="destination.text"/>
<mx:Binding source="source2.text" destination="destination.text"/>

<mx:TextInput id="source"/>
<mx:TextInput id="source2"/>

<mx:TextInput id="destination"/>

However, both methods allow you to perform operations on a source property value or derive a value from the combination of multiple source properties. See Binding Expressions discussed later.

Note: a source property can only be identified for data binding if the object to which it belongs has an id property.

Although it is possible to bind the text property of one TextInput control to the text property of another TextInput control as demonstrated in the previous example, data binding is not limited to such a scenario.

Properties of visual elements may be bound to non-visual elements and vice versa. In fact, an predominant Flex architecture, MVC, relies on the ability to bind visual elements in the "view" to non-visual elements in the "model".

Also, you could bind the text property of a TextInput control to the selectedIndex property of a ComboBox control if you so choose.

Data bindings are not limited to the binding of "like" properties or "like" elements.

Note that data bindings are, however, limited to properties of identical data types or scenarios where type casting is possible. For example, you can bind a property with a data type String (i.e. text property) to a property with a data type of Int (i.e. selectedIndex) since an Int can be implicitly cast to a String. However, the reverse is not true - a property with a data type of Int cannot be bound to a property with a data type of String.

Data binding could also be accomplished by using ActionScript to add an event listener to the source object which listens for a specified event and calls a specified event handler method responsible for changing the destination object's property value to the source object's property value.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="init()">

<mx:Script>
  <![CDATA[
    private function init():void {
      source.addEventListener(KeyboardEvent.KEY_UP,updateValue);
    }
  
    private function updateValue(event:KeyboardEvent):void {
      destination.text = source.text;
    }
  ]]>
</mx:Script>

<mx:TextInput id="source" />
<mx:TextInput id="destination" />

MXML data binding just allows you to do it easier and with less code.

While some may refer to such capabilities as nothing more than "syntactic sugar", most developers can appreciate the convenience and accessibility demonstrated by Flex's MXML implementation of data bindings.

Keep in mind that using MXML to bind data binds the properties to one another at compile time. If you want to bind data at runtime based on a condition, you will have to use ActionScript.

Binding Expressions

A data binding is the simplest form of a binding expression.

More advanced binding expressions combine the use of data bindings with ActionScript operations. Since binding expressions define the value of an MXML attribute, they must return a value and be wrapped in curly braces. Without curly braces, your binding expression will be interpreted as a literal value.

Binding expression are most commonly used to accomplish the following:

Bind the value of one object property to the property of another object (simple data binding)
String concatenation that includes one or more binded properties
Calculations on one or more binded properties
Conditional operations on one or more binded properties

Simple data binding:

<mx:ComboBox id="c" dataProvider="{myArray}" />

<mx:ViewStack id="v" selectedIndex="{c.selectedIndex}">
  <mx:Canvas>
    <mx:Label text="1"/>
  </mx:Canvas>
  <mx:Canvas>
    <mx:Label text="2"/>
  </mx:Canvas>
</mx:ViewStack>

OR 

<mx:ComboBox id="c" dataProvider="{myArray}" />

<mx:Binding source="c.selectedIndex" destination="v2.selectedIndex" />

<mx:ViewStack id="v2">
  <mx:Canvas>
    <mx:Label text="1"/>
  </mx:Canvas>
  <mx:Canvas>
    <mx:Label text="2"/>
  </mx:Canvas>
</mx:ViewStack>

String concatenation:

<mx:TextInput id="fname" />
<mx:TextInput id="lname" />

<mx:Label text="{'First Name: ' + fname.text}" />
<mx:Label text="{'Full Name: ' + fname.text + ' ' + lname.text}" />

OR

<mx:TextInput id="fname" />

<mx:Binding source="{'First Name: ' + fname.text}" destination="destination.text" />

<mx:Label id="destination"/>

Calculations:

<mx:NumericStepper id="quantity" />

<mx:TextInput id="price" />

<mx:Label text="{'Total: ' + quantity.value * Number(price.text)}" />

OR 

<mx:NumericStepper id="quantity" />

<mx:TextInput id="price" />

<mx:Binding source="{'Total: ' + quantity.value * Number(price.text)}" destination="destination.text" />

<mx:Label id="destination"/>

Conditional:

<mx:NumericStepper id="quantity" />

<mx:Label text="{(quantity.value % 2) ? 'Odd' : 'Even'}" />

OR 

<mx:NumericStepper id="quantity" />

<mx:Binding source="{(quantity.value % 2) ? 'Odd' : 'Even'}" destination="destination.text" />

<mx:Label id="destination"/>

Flex Basics - UI Controls

2008-10-23T21:03:00.001-06:00

A Flex application's user-interface (UI) is composed of two component types — containers and controls. Containers define application layout and navigation; controls represent a broad category of UI objects required of a fully functional and interactive application.

Flex user interface controls are found in the mx.controls package of the Flex Class library.

Similar to the controls found on a traditional "Control Panel" (gauges, buttons, dials, indicators, etc), most Flex UI controls provide users control of your application.

However, despite the term, some Flex controls are not interactive and provide no control whatsoever. Examples of noninteractive controls include Label and ProgressBar.

The remainder are interactive controls and as such "can participate in tabbing and other kinds of keyboard focus manipulation, accept low-level events like keyboard and mouse input, and be disabled so that it does not receive keyboard and mouse input." Interactive controls provide the level of interaction required for users to perform desired tasks or business functions.

Common control types include text-based controls, button-based controls, and data provider controls (which include both list-based controls and menu-based controls).

Text-based controls are designed to display text and/or receive text input. Examples include Label, Text, TextArea, TextInput, and RichTextEditor.

Button-based controls receive user input in the form of keyboard or mouse events. Examples include Button, LinkButton, CheckBox, RadioButton and PopUpButton.

Data provider controls display data from a variety of sources, both internal and external to your application. All data provider controls require designation of a "data provider".

List-based controls (a subset of data provider controls) visually represent hierarchical or non-hierarchical (flat) data structures. Examples include ComboBox, List, HorizontalList, DataGrid, TileList and Tree.

Menu-based controls (another subset of data provider controls) enable user-initiated navigation through use of a static menu (always visible) or a popup menu (visibility is initiated by a user or system event). Examples include Menu, MenuBar and PopUpMenuButton.

All Flex controls subclass (or extend) the UIComponent class, and therefore, inherit the following key behaviors:

- resizing capabilities
- positioning capabilities
- ability to dispatch events
- ability to accept keyboard focus and mouse input
- ability to control visibility

Like all Flex UI components, controls can be sized, positioned and styled according to your needs.

Sizing requires the use of height and width properties - either explicitly (by setting the height and width properties to numeric pixel values) or relatively (using percentage values in relation to the parent container).

In many instances the positioning of a control is determined by the layout property (horizontal or vertical) of the parent container in conjunction with the hierarchical sequence of the control. For example, if a control represents the 3rd child element of a parent container with the layout property set to horizontal, the control will be positioned 3rd from the left.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:Panel title="Panel Container with Horizontal Layout"
        layout="horizontal" 
        paddingBottom="5" paddingLeft="5" paddingRight="5" paddingTop="5">
       
        <mx:Button label="One"/>
        <mx:Button label="Two"/>
        <mx:Button label="Three"/>
       
    </mx:Panel>
   
</mx:Application>

However, when the parent container uses absolute positioning, the X and Y properties of the control specify the horizontal and vertical pixel coordinates within the parent container. Absolute positioning enables overlap of controls if necessary.

Also, the appearance of a control can be customized through the use of styles and skins utilizing the CSS Explorer.

Fortunately, Flex ships with a number of pre-built controls ready for inclusion in your application. Most controls are accessible via MXML (or ActionScript) during the development phase of your Flex application. MXML provides a mechanism for creating (instantiating) control components (objects) and setting control properties (including registration of event handlers with control events).

At runtime, the same control properties (including event handlers) are accessible via ActionScript only. ActionScript also provides access to the methods (or functions) of a Flex control. Runtime access to Flex controls provides the dynamic capabilities required of highly interactive and responsive application.

Flex Basics - UI Containers

2008-09-19T15:15:00.000-06:00

Flex containers serve as a mechanism for defining application layout and navigation. Common layout containers include VBox, HBox, Canvas, Tile and Form. Navigation containers include Accordion, Tab Navigator and View Stack. Each container descends from the Container Class, serves a unique purpose and is available for use at the discretion of the application developer.

Layout Containers

Layout containers dictate the layout of child elements (containers or controls) through the use of absolute or relative positioning. Absolute positioning requires definition of X and Y coordinates and permits overlap of elements. Relative positioning lays child elements next to each other either horizontally or vertically. Layout containers include:

- Application: default container provided at the root of your Flex application. There is no need to explicitly define the Application container as it comes part of any Flex application courtesy of the <mx:Application> tag. Organizes child containers vertically, horizontally or absolutely depending on the value of the layout attribute (horizontal, vertical or absolute)

- HBox: organizes child containers or controls horizontally

- VBox: organizes child containers or controls vertically

- HDividedBox: similar to an HBox with the distinction of a draggable divider in between each child container

- VDividedBox: similar to an VBox with the distinction of a draggable divider in between each child container

- Canvas: lays out child containers or controls based on absolute positioning (X and Y coordinates)

- Tile: lays out child containers or controls in columns or rows depending on the value of the direction attribute (horizontal or vertical)

- Panel: Similar to an HBox, VBox or Canvas container depending on the value of the layout attribute (horizontal, vertical or absolute) with the added benefit of a title bar

- Grid: similar to an HTML table it allows organization of child containers as rows and columns of cells

Control Containers

Control containers are used to manage the layout of controls (buttons, combo boxes, etc) only. Control containers include:

- ControlBar: only for use within a Panel or TitleWindow container, the ControlBar manages the layout of controls only (not child containers)

- ApplicationControlBar: one or more ApplicationControlBars may exist in a Flex application, however each must be a direct child of the Application container. Child components are limited to controls.

Navigation Containers

Navigation containers manage the navigation between containers by controlling the visibility of child containers. This visibility control can either be implemented by a nav bar (LinkBar, TabBar, ToggleButtonBar, etc) or by custom event handlers. Navigation containers include:

- Accordion: contains a collection of child containers and manages the visibility of each through the use of accordion headers (similar to nav buttons)

- View Stack: contains a collection of child containers stacked on top of each other. A View Stack is not tied to a particular component responsible for managing visibility but many options exist (i.e LinkBar, TabBar, ToggleButtonBar) for the developer's use

- Tab Navigator: identical to a View Stack except for a built-in navigation feature, TabBar

Containers may serve as a parent container, a child container or both a parent and child container in relation to another container.

The following example demonstrates the simultaneous use of a Canvas container as both a a parent container and a child container.

<mx:VBox width="100%" height="54">
   <mx:Image source="assets/logo.png" />
   <mx:Canvas height="30">
      <mx:Label x="9" y="7" text="Manage Athletes" />
      <mx:Label y="6" text="[ Log Out ]" right="5" />
   </mx:Canvas>
</mx:VBox>

In most cases, a layout container is not limited to a certain context. Exceptions include the Application container, the ApplicationControlBar container and the ControlBar container.

- Application container: as the root of the Flex application, only one instance of the Application container may exist and can ONLY be a parent container.

- ApplicationControlBar container: as the name suggests, the ApplicationControlBar container defines an area intended to house a control bar for your Flex application. As such, this container can only be defined as a direct child to the Application container.

- ControlBar container: intended to dock a toolbar to a Panel or TitleWindow container, a ControlBar container must be defined as a direct child to a Panel or TitleWindow container

All other containers are available for use in any context. For example, a Canvas container may be defined as a child to a parent VBox, HBox, Tile or even another Canvas container.

Given the hierarchical (parent/child) nature of application layout (containers), best practices suggest the use of MXML (an XML derivative) instead of ActionScript.

Toggling between Design mode and Source mode of Flex Builder, the hierarchical nature of your Flex application will be clear. In Design mode, your Flex application is arranged as nested containers and controls. This arrangement represents a hierarchy (or parent / child structure) and can be verified using the Outline View (Window >> Show View >> Outline). In Source mode, your Flex application is represented in MXML which by nature is hierarchical.

When your Flex application is ultimately translated into ActionScript, another type of hierarchy will emerge - an Object hierarchy. Afterall, a Flex application is nothing more than one Application object composed of other objects composed of other objects...and so on...and MXML is a mapping of your Flex application's object hierarchy to XML.

Flex Basics - UI State Transitions

2008-08-11T21:13:00.001-06:00

Software applications contain a large number of unique views. A view is comprised of structural elements and content arranged according to the designer / developer's preference (layout) and rendered on the user's screen.

Traditional web applications encapsulate each view within an HTML page. In a static website, the number of views correlates directly with the number of HTML pages. For example, a static HTML website with five HTML pages contains five views.

However, the number of views increases exponentially when dynamic capabilities are introduced into the mix. Dynamic capabilities are typically implemented through the use of server-side scripts (ColdFusion, PHP, JSP, .NET, etc).

Server-side scripts analyze data against a predefined set of rules (logic) and generate the view elements (HTML) accordingly. Data may include database data, web services data, cookie data, etc. Therefore, web applications dependent on data for presentation as well as content are commonly referred to as "data-driven" web applications. As the data grows and the number of rules increase so does the number of unique views.

Asynchronous technologies (AJAX) and DOM manipulation via JavaScript (DHTML) also contribute to the increasing number of views.

Flex applications are no different.

However, within the Flex framework, the term "View" refers to the User Interface (UI) as a whole and represents an aggregate of all visual permutations of an application. This naming convention mirrors the convention adopted by a popular Flex architecture, MVC (model-view-controller).

The "View" is comprised of view components (containers & controls) and each structural (or layout) variance to a view component is referred to as a View State. View States apply to all components (controls or containers) that extend the UIComponent class and consequently inherit the states property. The states property is an array of View States for that view component. With a default value of NULL, components start out with only one state, the base state. The base state is the root state of the component and consists only of the properties, styles, event handlers and children that you've originally defined for the component.

Adding View States involves adding one or more State objects to the states property of the component. Each State object requires a name and optionally the name of another state in which it is based on. Exclusion of the basedOn property will base your new state on the base state.

The purpose of a state is to alter the appearance of a component in response to a user or system-initiated event (i.e. click of a button). Altering the appearance of a component involves the use of overrides via a State. Valid overrides include:

AddChild

RemoveChild

SetEventHandler

SetProperty

SetStyle

When using MXML to define states, overrides are implied and the override tag is not required.

The following example demonstrates the use of an event handler to change the View State of the Application container:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

<!-- Define State -->
<mx:states>
    <mx:State name="newButton">
        <mx:AddChild relativeTo="{h1}" position="firstChild">
            <mx:Button id="buttonNew" label="New Button"/>
        </mx:AddChild>
    </mx:State>
</mx:states>

<!-- Apply State via event handler -->
<mx:Button id="b1" label="Add a Button" click="currentState='newButton'"/>

The transition from one state to another can be visually enhanced by the use of Transitions. Transitions consist of one or more effects grouped together to play when a state change occurs. Like the states property of a component (control or container), the transitions property is also inherited from the UIComponent class and is data-typed as an array of Transition objects.

Each transition is triggered by a change in a component's state as defined in the fromState and toState properties of a Transition object. Valid values include:

A state name

An empty string representing the base state

An asterisk (*) representing a wildcard matching ALL states

As previously mentioned, the purpose of a transition is to map one or more visual effects to one or more state changes.

Effects come in a variety of flavors and as expected extend the Effect class. Effect types include mask effects (MaskEffect class), sound effects (SoundEffect class) and tween effects (TweenEffect class).

Mask effects include:

Iris

WipeDown

WipeLeft

WipeRight

WipeUp

Tween effects include:

Blur

Dissolve

Fade

Glow

Move

Pause

Resize

Rotate

Zoom

Sound effects allow you to play an MP3 in response to an event.

Effects can be played in isolation, sequentially (one after another) or in parallel (at the same time). Multiple effects require the creation of a composite effect (CompositeEffect class). Variations of a composite effect may include sequential effects, parallel effects or a combination of both. In either scenario, the component to apply the effects must be defined (target component).

Additional control of each effect is provided through the use of the effect properties. Effect properties include duration, alphaFrom, alphaTo, etc. The details of each effect can be found at the Adobe Flex 3 Language Reference.

The following example demonstrates the use of a state transition:

<mx:transitions>
    <mx:Transition id="myTransition" fromState="*" toState="Advanced">
        <mx:Parallel target="{myVBox}">
            <mx:WipeDown duration="2000"/>
            <mx:Dissolve alphaFrom="0.0" alphaTo="1.0" duration="2000"/>
        </mx:Parallel>
    </mx:Transition>
    <mx:Transition id="yourTransition" fromState="Advanced" toState="*">
        <mx:Sequence target="{myButton}">
            <mx:Zoom duration="1000" zoomHeightTo=".9" zoomWidthTo=".9" />
            <mx:Zoom duration="1000" zoomHeightTo="1" zoomWidthTo="1" />
        </mx:Sequence >
    </mx:Transition>
</mx:transitions>

Note that the use of an effect is not limited to a state transition. Effects can be applied to components in the following manner to create behaviors:

<!-- Define Effect -->
<mx:Zoom id="shrink" duration="100" zoomHeightTo=".9" zoomWidthTo=".9" />

<!-- Apply Behavior -->
<mx:Button id="myButton" label="Resize" mouseDownEffect="{shrink}" />

In the previous example, an effect was registered with a trigger (mouseDownEffect) creating a behavior. Trigger + effect = behavior.

As always, the implementation of these Flex features can be achieved via MXML or ActionScript. The decision is yours.

Flex Elements - CSS Explorer

2008-07-16T13:56:00.001-06:00

Skinning and styling a Flex application may be necessary for a number of reasons. The most common reason being the need to satisfy branding requirements. In many instances, styling will be sufficient to establish a unique look and feel for your Flex application, however, we will take a look at both techniques.

Visual components that extend the UIComponent class have skins. These visual components include buttons, layout containers, form controls, navigation elements, etc. Refer to the Flex 3 language reference for additional visual components that subclass the UIComponent class.

A skin represents the visual appearance of a component's state. Many components have only one state while others have many states. Each state has a unique skin. For example, a button component has 8 states (up, over, down, disabled, selected up, selected over, selected down, selected disabled). Each button state has a skin referenced by skin name: upSkin, overSkin, downSkin, disabledSkin, selectedUpSkin, selectedOverSkin, selectedDownSkin, selectedDisabledSkin.

Each component's state has a default skin. The look and feel of your Flex application's default skins is dictated by the application theme. The default theme, Halo, is a combination of skins and style properties. Additional themes included in the Flex 3 SDK include Aeon Graphical, HaloClassic, Ice, Institutional, Smoke and Wooden.

More about included application themes can be found at the Adobe Help Resource Center. To modify the theme color of the default theme (Halo) utilize the themeColor attribute of the Application tag. Valid values include haloOrange, haloBlue, haloSilver, haloGreen as well as valid hexadecimal values (i.e. #FF000). The default theme color is haloBlue.

Custom skins can be applied to components in one of 2 ways:

- graphically
- programatically

Graphical skinning is the most common technique and involves associating an image or SWF with a component's skin. This association can be achieved inline via an MXML attribute or through the use of a style declaration (either embedded in an MXML Script tag or referenced externally in a CSS stylesheet).

Programmatic skinning requires the use of ActionScript and typically requires a developer to create a new class or extend an existing class. If you are comfortable with ActionScript and writing ActionScript classes, you may find programmatic skinning a better approach. The benefits include increased control over component styles and reduced memory usage.

In addition to skins, components have a wide range of style properties that contribute to their look and feel. Unlike a skin, these style properties are not correlated with a component's state but rather persist across all states of a component. Style properties are defined at the component level in one of 4 ways:

1. Inline MXML
2. Embedded Script tag
3. External CSS Stylesheet
4. SetStyle() method

Flex Builder 3's CSS Explorer provides the tools necessary to skin and style components. With both a Design mode and a Source mode, the CSS Explorer facilitates rapid skinning and styling.

As implied by the name, the CSS Explorer allows a developer to create or modify CSS files. Those familiar with the Flex Style Explorer have experience with CSS editing for Flex using a WYSIWYG editor. The CSS Explorer is very similar with the added benefit of the ability to create or edit component skins.

Creating a CSS stylesheet requires nothing more than selecting a component in CSS Explorer, applying the necessary styles, saving the generated CSS and recompiling your Flex application. The process of applying styles is as follows:

1. Create a CSS file
2. Open the CSS file in Flex Builder 3 (this will launch CSS Explorer)
3. Click on the 'New Style' button
4. Select the component type
5. Modify the component style properties in Design mode (Flex Properties view)
6. View the generated CSS in Source mode
7. Save the CSS file

In addition to styles, Flex developers can apply skins to a component. The process of creating a skin is as follows:

1. Create a CSS file
2. Open the CSS file in Flex Builder 3 (this will launch CSS Explorer)
3. Click on the 'New Style' button
4. Select the component type
5. Press the 'Skin' button in Design mode (Flex Properties view)
6. Enter the type of skin (image or SWF)
7. Choose the location of the image or SWF for each applicable component state
8. Refresh Flex Builder to display the changes to your skin(s)
9. Edit the scale grid to prevent distortion of you skin, if necessary
10. View the generated CSS in Source mode
11. Save the CSS file

Once your skins and / or styles have been defined in your CSS file, simply add a tag similar to the following into your Flex application.

<mx:Script source="styles.css"/>

Now your new look and feel will be applied to your Flex application at compile time.

To dynamically alter your Flex application's look and feel at runtime, review Ted Patrick's entry on runtime CSS.

Flex Elements - Application Debugger

2008-06-23T13:27:00.000-06:00

A familiar activity to all developers involves the undesirable but necessary task of application debugging. Fortunately, Flex Builder provides the tools necessary to easily inspect your code and pinpoint logical or potentially fatal run-time errors.

Successful debugging hinges on the debugging skills of the developer and the debugging tools available to the developer. The former can be acquired only through experience and education while the latter is both a product of the development platform and the community and / or corporate tooling support.

Common debugging techniques include tracing (or printing), breakpoint debugging, step-through debugging and watch expressions. Each of these debugging techniques is supported by Flex Builder.

The Flex Builder Debugging perspective contains a code editor and a set of views designed to aid Flex developers in the debugging process. Flex Builder debugging views include Debug view, Console view, Variables view, Breakpoints view and Expressions view.

Flex Builder Debug View

Outlines the application call stack. Each function is displayed in order of execution (with the bottom of the list being the first function called). The Debug view serves as the control center of the Flex debugger. It allows a developer to start / stop application execution and step over lines of code and step into and out of functions.

Flex Builder Console View

Outputs the results of any trace statements added to your code. Also known as "poor man debugging", trace statements are synonymous with print statements or alert statements. Most developers are very familiar with this debugging technique.

Flex Builder Variables View

Displays variables (simple and complex), their value and data type. By selecting a function in the Debug view, you can inspect the current value of the function's local variables (variables limited in scope to the selected function). Variables outside of the function's scope are also available in the Variables view and are labeled as 'This'. Variable values are also configurable allowing developers to test alternate scenarios in hope of obtaining the desired outcome.

Flex Builder Breakpoints View

Displays a list of application breakpoints. Breakpoints allow developers to inspect the state of an application during execution. Breakpoints can be enabled, disabled or removed in the Breakpoints view.

Flex Builder Expressions View

Allows developers to "watch" specific variables through the life cycle of an application. Variables can be added to the Expressions view by selecting 'Create Watch Expression' in the Variables view for a specific variable.

A Debug session is initiated by clicking the Debug icon found on the Flex Builder toolbar and (by default) runs against the HTML wrapper of a Flex application. Therefore, a debug session requires the use of a web browser. (Change the default web browser by selecting Window > Preferences, then General > Web Browser.) Once a breakpoint is encountered, execution is halted and focus is returned to Flex Builder. At this point a developer can analyze the state of the application and make any necessary changes. Changes may include code changes in the code editor, variable changes in the Variables view, adding new breakpoints, etc. Execution is resumed by clicking 'Continue' in the Debug view. When another breakpoint is encountered, execution is halted once again. In the interim, developers may choose to step over each line of code, step into or out of a function. As this is done, variable values change accordingly. This process continues until the application has run its course or the developer terminates the Debug session.

The Flex debugger is not intended to highlight syntax or data type errors. ActionScript is a compiled language (versus interpreted) and those errors are caught by the compiler at compile time. Rather, the Flex debugger provides valuable insight into a Flex application. Debugging is part of the development process and application transparency is necessary to attain project success. The Flex Builder Application Debugger is a vital part of a successful development life cycle.

Flex Elements - Flex Builder

2008-06-14T15:14:00.000-06:00

A Flex application is the result of one or more MXML and / or ActionScript files compiled into a SWF and delivered via HTTP to the client's browser. The Flex SDK provides everything you need to create Flex applications and is available at no cost to you. Armed with a text editor and the Flex SDK, developers can create simple to complex Flex applications.

The process includes the following steps:

Download the Flex SDK

Create a text file with a .MXML extension to serve as your application root file

Create one or more files with a .MXML extension to dictate your application structure and layout

Create one or more files with a .AS extension to encompass your application functionality

From a command line, launch the Flex compiler to convert your MXML and ActionScript files into a published SWF file

More detailed instructions on command line Flex development can be found at Adobe - Flex Developer Center.

Another more practical option available to Flex developers includes the use of Adobe's Flex Builder. Flex Builder is a fully-functional IDE (Integrated Development Environment) available as a plugin for the Eclipse open-source platform. A stand-alone version of Flex Builder is also available and includes a customized distribution of Eclipse coupled with the Flex Builder plugin.

Priced from $250, Flex Builder 3 provides a host of features designed to improve developer productivity and application quality. Features include:

Coding tools (syntax coloring, code completion, code collapse, code refactoring)

Debugging tools (step-through debugger)

WYSIWYG design tools (prebuilt UI components, drag-and-drop layout manager, application transitions (view states), component property inspector)

Styling / skinning tools (CSS design manager, skin manipulation)

Charting tools

Testing tools

Performance monitoring (profiling) tools

The Flex Builder IDE is organized into three perspectives:

Flex Development perspective
Flex Debugging perspective
Flex Profiling perspective

A Flex Builder perspective is a collection of views and editors utilized to perform a group of related tasks (i.e. development tasks, debugging tasks & performance monitoring (profiling) tasks).

Editors are provided for MXML, ActionScript & CSS code authoring and editing. The MXML & CSS editors operate in two modes - source mode & design mode. The ActionScript editor operates in source mode only. Most developers feel comfortable working with the source code of an application, and therefore, spend a lot of time in source mode. Certain tasks (i.e. web service consumption) require the use of Flex Builder's source mode while other tasks encourage the use of Flex Builder's design mode (i.e. UI layout). However, in many cases the choice is a matter of preference as many tasks can be accomplished in either mode (i.e. UI controls instantiation).

Views encapsulate related functionality required of productive developers. Examples include the ability to visually navigate your application hierarchy (Outline View), display properties for a selected element (Flex Properties View), instantiate containers and controls on-the-fly (Components View), or define application states (States View). Views are also used to organize attributes of a Flex application (i.e. problems, breakpoints, variables, expressions, etc.)

As an Eclipse plugin, Flex Builder integrates seamlessly with other complimentary development tools including Subversion and CVS (source control), ANT (automated build tool), FTP (file transfer), unit testing and more.

With Eclipse and Flex Builder 3, developers have the tools necessary to build high quality, robust business applications.

Flex Elements - ActionScript

2008-06-07T14:12:00.000-06:00

The backbone of the Flex Framework is ActionScript 3.0. An object-oriented scripting language based on the ECMAScript standard, ActionScript defines all of the structure / layout and most of the behavior of your Flex application. (CSS is responsible for the formatting / style and a host of server-side scripting languages (ColdFusion, PHP, JSP, .NET, etc) may contribute to your application's behavior.)

The Flex Framework (or SDK) ships with a library of prebuilt ActionScript classes. These prebuilt classes are organized into packages. A package is a mechanism for organizing ActionScript classes. Each package provides two important benefits:

1. A logical grouping of related functionality. For example, the package labeled mx.controls.listClasses contains the classes responsible for providing list-based control functionality.

2. A namespace for an ActionScript class. Without packages, every class name would have to be unique to avoid ambiguity. If every class name must be unique, a developer must know the name of every prebuilt class to avoid naming conflicts when creating custom classes. With packages, a developer is free to name custom classes as he / she likes as long as the name is unique to the package (namespace).

In most cases your use of prebuilt ActionScript classes will be limited to those found in the mx top level package (i.e. mx.charts.effects or mx.controls.menuClasses). These classes (mx) are specific to Flex applications. However, you'll find that since Flex is a subset of Flash, the ActionScript classes found in the 'flash' top level package can also be leveraged in your Flex application (i.e. flash.net.URLLoader).

If you have any experience with JavaScript, you'll find ActionScript to be pleasantly familiar. After all, JavaScript and ActionScript are based on the same standard, ECMAScript. Outside of using MXML tags (an abstraction layer for ActionScript), the following techniques are used to include ActionScript into a Flex application:

1. Inline ActionScript – typically limited to property assignment or method calls triggered by an event rather than complex business logic, ActionScript can live within an MXML attribute.

<mx:Button id="myButton" click="eventHandler()" />

2. Nested ActionScript – The text node of an MXML element may contain ActionScript. To avoid the parsing of ActionScript in the text node as XML, place the ActionScript within a CDATA block.

<mx:Button label="click me">
 <mx:click>
   <![CDATA[
     myFunction('hi there')
   ]]>
 </mx:click>
</mx:Button>

3. MXML Script Tags – As your ActionScript becomes more complex and verbose, an MXML Script tag may be warranted. Again, a CDATA block must be used to prevent parsing of ActionScript as XML.

<mx:Script>
  <![CDATA[
    import mx.controls.Alert;

    public function myFunction(message:String):void {
      Alert.show(message);
    }
  ]]>
</mx:Script>

4. Adhering to object-oriented principles and guidelines often involves the creation of custom ActionScript classes for use in your Flex application. Custom classes are typically an extension of a prebuilt class and occupy their own file with an .AS extension. Like prebuilt classes, custom classes reside in a package. For custom classes, packages are synonymous with directories. Therefore, a custom class file (i.e. MyClass.as) found in wwwroot/com/flexdevelopers/view could be referenced from your Flex application as:

com.flexdevelopers.view.MyClass

The property / methods of a prebuilt or custom class can be utilized by simply importing the class into your application for use:

import com.flexdeveloper.view.MyClass

var myObject:MyClass = new MyClass();
var myVariable:String = myObject.myMethod();

or, by providing a fully-qualified class path in an ActionScript expression / statement:

if (1==1) { com.flexdeveloper.view.MyClass.myStaticMethod(); }

Flex Elements - MXML

2008-05-31T15:47:00.000-06:00

Arguably, one of the most important parts of the Flex SDK is the Flex Class Library (ActionScript classes categorized and organized into packages). Consisting of numerous ActionScript classes, the Flex Class Library provides a foundation for rapidly building Flex applications.

Dubbed a convenience language, MXML provides developers access to the Flex Class Library through an easy-to-use, easy-to-learn, clean and concise syntax. MXML is simply converted to ActionScript at compile time.

As you may have guessed, MXML follows the convention of XML and, as such, follows the basic syntactical rules of XML.

In many scenarios, using MXML in lieu of ActionScript is considered a best practice. The most popular scenario involves the authoring of application / component layout and structure.

As mentioned earlier, the Flex Class Library is an extensive collection of prebuilt ActionScript classes available for use by your Flex applications. At a very high level, these ActionScript classes provide developers with the ability to accomplish the following:

- Dictate application / component layout and structure
- Style the application / component
- Provide functionality
- Access / parse data

MXML provides an alternate method for Flex development which may be suitable for many scenarios (i.e. application / component layout and structure)

Keep in mind that everything in Flex is derived from an ActionScript class. In other words, every aspect of your Flex application is defined by an instance of an ActionScript class (an object) or by the class itself (static methods, constants, etc). ActionScript is a human-readable, Object-Oriented Programming (OOP) language that when compiled by the Flex compiler is converted into native Flash bytecode and wrapped in a SWF file. This SWF file is ultimately loaded and played by Flash Player 9 embedded in most browsers. Therefore, to build Flex applications, the developer is responsible for the creation and delivery of a collection of ActionScript classes (either prebuilt or custom) to the Flex compiler.

MXML IS ActionScript. MXML is nothing more than an alternate approach to instantiating (creating an object / creating an instance of) a prebuilt or custom ActionScript class for use in a Flex application.

Here is a line of MXML and its ActionScript equivalent.

Creating an instance of the Button class using MXML:

<mx:Button id="myButton" label="Hello" />

Creating an instance of the Button class using ActionScript:

var myButton:Button = new Button();
myButton.label = "Hello";

The MXML is more concise and cleaner in my opinion. In this example, the XML element name (Button) creates a reference variable (named myButton) with reference to a Button object. In MXML, XML attributes typically define the state of the object by setting properties (or instance variables) of the object. Not bad for one short line of code.

Also, as MXML is XML, it makes sense for use in scenarios where parent / child relationships are commonly defined. Application / component layout and structure commonly defines parent / child relationships through use of nested containers and controls, and therefore, makes a great candidate for the use of the XML-based MXML.

Flex - Overview

2008-05-26T13:48:00.000-06:00

Flex is a collection of resources packaged into an SDK (software development kit consisting of the Flex class library (ActionScript classes), the Flex compilers, the debugger, the MXML and ActionScript programming languages, and other utilities) provided by Adobe for use in building expressive and interactive rich internet applications (RIA). By leveraging the Flex SDK and Flex Builder (an Eclipse plugin), developers can create feature-rich, web-based and cross-browser compatible (thanks to Flash Player) applications.

Most applications of any merit consist of client-side functionality and server-side functionality. Traditional web applications utilize Javascript on the client side and a host of scripting languages (ColdFusion, PHP, JSP, .NET, etc) on the server side. Flex applications follow the same model. In fact, the Flex portion of an application (delivered as a SWF file) closely resembles the HTML / Javascript portion of a traditional web application. Flex takes care of the user interface (UI) or the client-side functionality of a web application. Server-side functionality (database interaction, for example) is still dependent on server-side components written in a traditional scripting language (ColdFusion, PHP, JSP, .NET, etc). However, you'll notice that many functions typically handled on the server (i.e. web service consumption) are now handled in the client thanks to Flex.

Web applications that depend too heavily on the server have a negative impact on user experience - specifically applications that require a full-page refresh to interact with the server. As the technology has become available, web applications are shifting a significant amount of work from the server to the client. The result is a highly responsive application providing instant user feedback which results in happier users. Flex-based applications and AJAX-based applications are leading the way.

As developers, one of our goals is to create the files that compose an application. As a whole, these files dictate the layout, structure, style and business logic of an application. In Flex, these files consist primarily of MXML files and ActionScript files (although CSS files play their typical role as stylesheets and Javascript is also available to your Flex app for additional client-side functionality, if necessary).

Best practices suggest the seperation of layout (or structure), style and business logic when developing web-based applications. The same holds true for Flex apps.

A properly-defined Flex app might look like the following*:

- Layout / structure: MXML files and/or ActionScript files
- Style: CSS files
- Client-side business logic: ActionScript files

However, there are exceptions to every rule, and many scenarios justify the use of inline ActionScript inside MXML (layout/structure) files. Similar to the use of inline Javascript inside HTML files, inline ActionScript can be used to provide client-side functionality such as event handling (event handlers) and data binding. However, it is probably best to limit your use of inline ActionScript to simple statements such as method calls or property assignment rather than complex logic. For example:

<mx:Button id="myButton" click="myObject.myFunction()" />
<mx:Button id="myButton" click="currentState='myState'" />

In the first example, a click event dispatched by the myButton instance of the Button class triggers a call to the myFunction method of the myObject instance. In other words, when you click myButton, myFunction is called. The MXML only maps the event to the method. The body of the method may be stored in a separate AS file and, therefore, business logic is successfully separated from layout / structure.

In the second example, a click event dispatched from myButton triggers a simple property assignment (currentState) required to alter the layout / structure using application states. Since this ActionScript statement impacts the layout / structure of the application, one could argue that it's place belongs in the MXML file used to define layout / structure.

When our development is complete, the Flex compiler that ships with Flex Builder generates one or more SWF files based on our MXML files and Actionscript files.

MXML + AS = SWF

Deploying a Flex application involves the delivery of the SWF file(s) plus an HTML wrapper, the CSS file(s) and any server-side script files (i.e. .CFM, .PHP, etc) to the server. Like traditional web applications, these resources are delivered from the server to the client browser using the customary HTTP request / response fashion.

Check out the animated overview of the Flex development life cycle for a nifty visual of the process.

*Don't forget a complete application usually requires server-side functionality (i.e. database interaction) implemented in the form of server-side scripts (ColdFusion, PHP, JSP, .NET, etc.).