This article is sponsored by Adobe.

---

Advertisements

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

In my previous article, States and Components in Flex 4, I talked about the new states syntax in Flex 4. In particular, that article covered how to use the includeIn and excludeFrom properties of states to help define the visibility of components in the different screens of a GUI. In this article, I'll be discussing another aspect of the new states syntax in Flex 4: state-specific values. This mechanism of states enables you to automate property value changes when your application changes state.

The idea and syntax are quite simple: properties have default values and you can add state-specific qualifiers to those property names in MXML to specify different values for those properties in specific states. The syntax uses the property name, followed by a period, followed by the name of a state or state group in which that property will take on the given value. For example, to set the value of x to 100 in state s1, you write x.s1="100". This is far easier to understand in code, so let's look at an example, SearchMe2.

The SearchMe2 example from my book Flex 4 Fun is very similar to the SearchMe example in the previous article except that some elements are shared between the screens. In particular, we would like the user to be able to perform another search on the results screen without having to return to the initial search screen, so the text input and the search button will live in both states. But since these elements were in the middle of the screen in the initial searchScreen state, we'll have to move them out of the way to make room for the results screen. Here's the SearchMe2 demo:

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

Some of the elements of this version of the application are the same as they were in the previous version. For one thing, we have the same states block to define the two screens of the application:

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

Also, our results list is defined similarly, existing only in the resultsScreen state due to the use of includeIn:

<mx:DataGrid includeIn="resultsScreen" x="10" y="38" width="280" height="202"
        dataProvider="{results}">
    <mx:columns>
        <mx:DataGridColumn headerText="Common Name" dataField="name"/>
        <mx:DataGridColumn headerText="Latin Name" dataField="latin"/>
    </mx:columns>
</mx:DataGrid>

We define our search screen elements a bit differently than we did in the SearchMe demo of the previous article. For one thing, there is no surrounding Group that is included only in the searchScreen. Instead, we just have one element, the Label, which is included only in that state:

  <s:Label x="107" y="66" text="Food Item"
      fontSize="18" fontWeight="bold"
      includeIn="searchScreen"/>

We then define the text input component and the button, which now exist in both screens, to take on different position values in the two states:

  <s:TextInput id="searchInput" 
      x="86" y="91" x.resultsScreen="84" y.resultsScreen="10"/>
  <s:Button label="Search" 
      x="115" y="121" x.resultsScreen="220" y.resultsScreen="10"
      enabled="{searchInput.text != ''}"
      click="runSearch()"/>

Here, the input and the button both have default values for x and y, which define the location of the elements in the first state. But these objects also have x and y values defined that are specific to the resultsScreen state. These values are set on the x and y properties when the application enters into the resultsScreen state. In this way, the application defines, in a declarative way, the values that these shared elements' properties have in both states. The Flex states engine handles setting these property values whenever the application changes state.

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 SDK 4
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.