components, , " />

FlashPlatformist
Articles, Information, News, & Tutorials for Adobe Flash Platform Developers and Architects

Flash Camp Phoenix a Huge Success

Flash Camp Phoenix was held in front of a sellout crowd on Friday, and everyone considered it a huge success. I consider this a huge success for the local Phoenix Flash Platform community as this was the FIRST Adobe-based event held in the Phoenix-metro area and the turnout was HUGE. Some of the highlights of the even included Christian Saylor’s inspiring session on User Experience, Ryan Stewart’s keynote which announced Adobe’s upcoming plans for the Flash Platform. Additionally, Sarge Seargent from Adobe did an awesome session on Flash Media Server and the direction of the Open Source Media Framework and Flash video on the web. Kevin Fauth also kept things interesting with his comedy routine on programmatic drawing (you have to see it to believe it).

I was asked to publish my presentation from my session on “Building Custom Spark Components in Flex 4″, so I have included it below:

Possibly Related Posts:



Posted by Dan Orlando on February 1st, 2010 :: Filed under General, Tutorials
Tags :: , ,

Understanding the Flex 4 Spark Component Architecture and how to Build Custom Components with the Flex 4 SDK

The architecture of the new Spark components in Flex 4 supercedes the Halo components of Flex 3. Upon learning how to leverage the  architecture of Spark components, you will find the improvements to be quite substantial.

Ultimately, the new component architecture with the Spark library makes building, modifying, and designing custom components a lot easier and far more intuitive. The most significant architectural changes are internal state management and decoupled visual appearance.

Internal State Management

The declaration of global application states is still possible, but the trick to getting a Flex application to closely resemble a native desktop application is by changing the state of individual container components while holding the state of others. This is what gives the application a “seamless” flow. This is accomplished by creating multiple skins for a single component, and just swap them out in an event handler. The code for the skin itself should have the following structure:

<Skin xmlns="http://ns.adobe.com/mxml/2009">

    <states>
        <State name="up" />
        <State name="over" />
        <State name="down" />
        <State name="disabled" />
    </states>

    ...
</Skin>

In the example above, state changes are controlled by the component, as the component class is responsible for internal behaviors. However, a single state change could include the attachment of a new skin class.   In addition to controlling it’s currentState property, the component broadcasts this value to its parent through the use of meta data. That means the parent can still override the built-in states of a component, and most importantly, the parent application is able to easily find out the current state of any of its children.

Decoupled Visual Appearance

HOWEVER, skin states are not the same as component states. A component state can change without the skin state changing. In other words, component states are decoupled from skin states. Component states define changes to the behavioral state of a component, while Skin states define changes to the display state of the component that they are attached to. For example, the Button class has a set of states that include: up, down, selected, and disabled. The Button drives state changes to ButtonSkin, which is the skin that is attached to the Button component. The Button and ButtonSkin classes both have their own currentState property, which is accessible by the parent container. This is a good example of the Template design pattern.

The following code sample is taken from ButtonSkin.mxml and provides a nice depiction of what we are talking about here:

<?xml version="1.0" encoding="utf-8"?>
<Skin xmlns="http://ns.adobe.com/mxml/2009">

    <Metadata>
        [HostComponent("spark.components.Button")]
    </Metadata> 

    <states>
        <State name="up" />
        <State name="over" />
        <State name="down" />
        <State name="disabled" />
    </states>

    <!-- border -->
    <Rect left="0" right="0" top="0" bottom="0" minWidth="70" minHeight="24">
        <stroke>
        <SolidColorStroke color="0x808080" color.disabled="0xC0C0C0" />
        </stroke>
    </Rect>

    <!-- fill -->
    <Rect left="1" right="1" top="1" bottom="1" minWidth="68" minHeight="22">
        <stroke>
        <SolidColorStroke color="0xFFFFFF" color.over="0xFAFAFA" color.down="0xEFEFEF" />
        </stroke>
        <fill>
        <SolidColor color="0xFFFFFF" color.over="0xF2F2F2" color.down="0xD8D8D8" />
        </fill>
    </Rect>

    <!-- label -->
    <TextBox text="{hostComponent.label}"
         fontFamily="Arial" fontSize="11"
         color="0x444444" color.disabled="0xC0C0C0"
         horizontalCenter="0" verticalCenter="0"
         left="10" right="10" top="4" bottom="2"
         textAlign="center" verticalAlign="middle">
    </TextBox>

</Skin>

Now that you have reviewed the code for the default Spark skin class that is used by the <code>Button</code> component, let’s take a look at the code for the <code>Button</code> component in the Spark library:

package spark.components {
/**
 *  Up State of the Button
 */
[SkinState("up")]
/**
 *  Over State of the Button
 */
[SkinState("over")]
/**
 *  Down State of the Button
 */
[SkinState("down")]
/**
 *  Disabled State of the Button
 */
[SkinState("disabled")]
public class Button extends SkinnableComponent implements IFocusManagerComponent {  

    /**
     *  @return Returns true when the mouse cursor is over the button.
     */
    public function get isHoveredOver():Boolean {
        return flags.isSet(isHoveredOverFlag);
    }

    /**
     *  Sets the flag indicating whether the mouse cursor
     *  is over the button.
     */
    protected function setHoveredOver(value:Boolean):void {
        if (!flags.update(isHoveredOverFlag, value))
            return;

        invalidateSkinState();
    }

    // GetState returns a string representation of the component's state as
    // a combination of some of its public properties
    protected override function getUpdatedSkinState():String
    {
        if (!isEnabled)
            return "disabled";

        if (isDown())
            return "down";

        if (isHoveredOver || isMouseCaptured )
            return "over";

        return "up";
    }

    //--------------------------------------------------------------------------
    //
    //  Event handling
    //
    //--------------------------------------------------------------------------

    protected function mouseEventHandler(event:Event):void
    {
        var mouseEvent:MouseEvent = event as MouseEvent;
        switch (event.type)
        {
            case MouseEvent.ROLL_OVER:
            {
                // if the user rolls over while holding the mouse button
                if (mouseEvent.buttonDown && !isMouseCaptured)
                    return;
                    setHoveredOver(true);
                break;
            }

            case MouseEvent.ROLL_OUT:
            {
                setHoveredOver(false);
                break;
            }

        }
    }
}

}

As you can see in the third code listing, a SkinState meta data declaration is used to define the states of the attached skin. To change skin states, you should use invalidateSkinState() and getCurrentSkinState(). The invalidateSkinState() method is what invalidates the skin state, and sets the skin’s state to that which is returned by the getCurrentSkinState() method. The getCurrentSkinState() method keeps track of any internal properties on the component and figures out what state the skin should be in.

This may seem a bit complicated at first, but as you begin to develop your own custom Flex 4 components, it will quickly become apparent that this is a very valuable architectural change to components for this new iteration.

Possibly Related Posts:



Posted by Dan Orlando on June 13th, 2009 :: Filed under Tutorials
Tags :: , ,

Tour de Flex Component Explorer

I came across one of the coolest things I’ve seen in a while, the “Tour de Flex Component Explorer”. This is an AIR application that also has a corresponding web-based version. This is something that both newbies and gurus alike will find most interesting. You can install the application by clicking the install badge below:

The coolest thing about this application is that Flexers are invited to submit their work to be included in the application. What an ingenious way for Flexers to collaborate on ideas! It gets better though; it seems that Adobe has created a plugin for Eclipse as well that allows you to browse the Tour de Flex components right from the Eclipse IDE.

Here are some additional Tour de Flex links:

The web-based version of the application can be viewed HERE

Additional info on the application can be found HERE

The sample submission to have your work included can be found HERE

Possibly Related Posts:



Posted by Dan Orlando on April 1st, 2009 :: Filed under Announcements, Flash Platform News, Tools & Innovation
Tags :: ,

Life Cycle of the Flex UIComponent Base Class

The Flex documentation on the UIComponent life cycle is rather difficult to understand, and so I came up with what I felt was an easier and more logical way of describing the process. I felt this might be useful for those who are interested in creating custom visual components in Flex that extend the UIComponent class. Creating custom components without having a solid understanding of the functionality that is abstracted within the Flex framework in regard to how it lays out UIComponent objects will likely result in design decisions that are inconsistent with the Flex Framework, which could potentially lead to a frustraing and seemingly uphill battle between the developer and the framework.

The following flow diagram represents the process that is abstracted within the Flex framework when the addChild() command is made to create and make a visual component visible on the stage, or when the properties of the component and/or it’s parent change (like a new data update for example):

Life Cycle of a Flex UIComponent

Life Cycle of a Flex UIComponent

Note that if that is a little hard to read, you can click on it and it will brink up a pdf version. This is identical to what is said in the Flex documentation, it is just a lot easier to understand for those of us who appreciate visual representations of processes that are comprised of many steps. It is just easier to follow.

You will notice toward the bottom the diamond shape, which represents a decision that has to be made. The thing to understand here, is that additional components may be going through this same process simultaneously, thus affecting the layout properties of each other. An example might be the resizing of the parent window. The invalidation methods in essence, act as a sort of “queue” so to speak, so the actual stage ends up redrawing just once even though a number of things may have changed. The point at which the UIComponent makes the decision on whether or not to re-render is sort of like it is checking itself to make sure that it is ready before becoming visible. If a number of visual properties have been set on it or something else changed again that forced the invalidation methods to be called again on the components, it re-runs the commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods again, and will continue to do so until it knows that it is now ready to be seen, at which point it’s visible property is set to true.

The speed at which this all happens and the overall architectural decisions with regard to how the stage is drawn in a Flex app and the way the visual elements are laid out, is truly quite impressive, and worth studying in further detail if you are interested in learning more about the design patterns used in the Flex framework to make it work the way it does. Although Flex does have its flaws, this is an example of how the framework abstracts a lot of functionality quite elegantly for the developer.

Possibly Related Posts:



Posted by Dan Orlando on February 7th, 2009 :: Filed under Tutorials
Tags :: , , ,