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

Summary
With a demo app from his book, Flex 4 Fun, Chet Haase shows how to make
components visible only in specified application states in Flex 4.

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:

To view this page ensure that Adobe Flash Player version
10.0.0 or greater is installed.

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:

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:

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.

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.