---

Advertisements

This article is based on material from the book Flex 4 Fun by Chet Haase, available as a PrePrint™ from Artima Press.

Most applications enter into many different states over time. An application may have different screen states, for example, such as a shopping site that enables searching on one screen, search results on another, and shopping cart details on yet another. An application's individual components may have different states as well, like a disabled state for a button until the user has entered their billing address.

One of the innovative things about the Flex platform is that this concept of states is supported by the API. Flex provides a way to describe the different states of your application and components in your MXML code directly.

The underlying concept and implementation of states did not change significantly between Flex 3 and Flex 4, but the syntax for states changed dramatically. States were a powerful mechanism in Flex 3, but writing correct state code could be very tricky, and reading even correctly written state code was a chore at best.

Fortunately, Flex 4 came along and completely changed the way that state code is written. Instead of a block of unreadable state code, you write a block of state name declarations and then state-dependent values are declared directly inline on the affected tags. Now the state code is both easy to write and read.

Using includeIn and excludeIn

Often, you may want to define states in which an object exists, or, conversely, states in which it does not. Or in a situation with more than two states, the set of states in which it either exists or does not exist. For example, you may want a button to be visible when the application starts up in state s1, but to go away when the application changes to state s2. To set this existence information in Flex 4, you use the includeIn or excludeFrom property on the object.

The includeIn property lists those states in which the object exists; it does not exist in any other states that are not named in that list. Conversely, the excludeFrom property lists those states in which the object does not exist; the object exists only in states that are not in that list. You should only use one of these properties on any given object, not both.

The SearchMe demo application from my book Flex 4 Fun demonstrates states in action. When you type a string into the text input box and click the Search button, the application will bring up a second screen with the search results:

Either scripts and active content are not permitted to run or Adobe Flash Player version 10.0.0 or greater is not installed.

This results screen, just like the search screen of the application, is created using states to define which elements are visible. First, this MXLM code defines the two states of the application:

    <s:states>
        <s:State name="searchScreen"/>
        <s:State name="resultsScreen"/>
    </s:states>

Next, the includeIn syntax indicates which elements are visible in each state. The label, text input, and search button only exist in the searchScreen state, so they are defined together in a Group that is only included in that state:

    <s:Group includeIn="searchScreen">
        <s:Label x="107" y="66" text="Food Item"
            fontSize="18" fontWeight="bold"/>
        <s:TextInput id="searchInput" x="86" y="91"/>
        <s:Button x="115" y="121" label="Search" 
            enabled="{searchInput.text != ''}"
            click="runSearch()"/>
    </s:Group>

Similarly, the results screen includes a DataGrid with the results, along with a button that let's you return to the search screen:

    <s:Group includeIn="resultsScreen">
        <mx:DataGrid x="10" y="10" width="280" height="201"
                     dataProvider="{results}">
            <mx:columns>
                <mx:DataGridColumn headerText="Common Name" 
                                   dataField="name"/>
                <mx:DataGridColumn headerText="Latin Name" 
                                   dataField="latin"/>
            </mx:columns>
        </mx:DataGrid>
        <s:Button x="104" y="219" label="Search Again"
                  click="currentState = 'searchScreen'"/>
    </s:Group>

With these groups defined to exist in their respective states, Flex takes care of displaying the right GUI state at the right time. When the user clicks on the Search button, the currentState of the application is set to resultsScreen. This causes the elements that are included only in the searchScreen to go away and the elements that are included in the resultsScreen to appear.

States are a powerful, declarative system for defining the different logical states that an application, or even a single component, can be in when the application runs. They are useful for defining anything from the different screens that a user may see during the course of using the application to the different states that a button may be in when the user hovers over it or presses it. They help define the visual differences between these states in a simple way so that you can structure your code according to how things look in the different states.

Resources

Chet Haase is author of Flex 4 Fun, which is available as a PrePrint™ (early access release) at: http://www.artima.com/shop/flex_4_fun

Adobe's Flash Builder 4
http://www.adobe.com/products/flashbuilder

Flex 4 SDK
http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK

For more on states in Flex 4, see "Working with States in Flex 4":
http://www.artima.com/articles/flex_4_states.html

Flex.org
http://www.flex.org

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Chet Haase is a senior computer scientist on the Flex SDK team at Adobe Systems, Inc. In the Flex 4 release, he was responsible for Flex effects, and writing the next effects infrastructure and classes for Flex 4. Prior to his work at Adobe, he worked at Sun Microsystems for several years, and co-authored the book Filthy Rich Clients about creating rich user experiences with the Java client platform. His entire career has been in graphics software, from the application level to APIs and libraries to drivers for graphics chips. As long as it puts pixels on the screen, he's interested. He earned a B.A. in Mathematics from Carleton College and an M.S. in Computer and Information Sciences from the University of Oregon.

Chet is also interested in writing and performing comedy; you can see some his work in this completely unrelated field at http://chetchat.blogspot.com, and in his book When I am King..., which is available at Amazon.com. Chet lives in Pleasanton, California, with his wife and three kids, whom he needs to spend more time with now that this book is finished.