In many
rich Internet applications, the interface changes based on the task
the user is performing. A simple example is an image that changes
when the user rolls the mouse over it. More complex examples include
user interfaces whose contents change depending on the user’s progress
through a task, such as changing from a browse view to a detail
view. View states let you easily implement such applications.
At its simplest, a view state defines a particular view of a
component. For example, a product thumbnail could have two view
states; a default view state with minimal information, and a “rich”
state with links for more information. The following figure shows
two view states for a component:
A.
Default view state
B.
Rich view state
To create a view state, you define a default view state, and
then define a set of changes, or overrides, that modify the
default view state to define the new view state. Each additional
view state can modify the default view state by adding or removing
child components, by setting style and property values, or by defining state-specific
event handlers.
For example, the default view state of the application could
be the home page and include a logo, a sidebar, and some welcome
content. When the user clicks a button in the sidebar, the application
dynamically changes its appearance, meaning its view state, by replacing
the main content area with a purchase order form but leaving the
logo and sidebar in place.
Two places in your application where you must use view states
is when defining skins and item renderers for Spark components.
For more information, see Spark Skinning and Custom Spark item renderers.
Adobe Flash Builder also has built-in support for view states.
For more information on using Flash Builder, see Add
View states and transitions.
Defining a login interface by using view states
One use of view states is to implement a login and registration
form. In this example, the default view state prompts the user to
log in, and includes a LinkButton control that lets the user register,
if necessary, as the following image shows:
LinkButton control (A)
If the user selects the Need to Register link, the form changes
view state to display registration information, as the following
image shows:
A.
Modified title of Panel container
B.
New form item
C.
Modified label of Button control
D.
New LinkButton control
Notice the following changes to the default view state to create
this view state:
The title of the Panel container is set to Register
The Form container has a new TextInput control for confirming
the password
The label of the Button control is set to Register
The LinkButton control has been replaced with a new LinkButton
control that lets the user change state back to the default view
state
When the user clicks the Return to Login link, the view state
changes back to the default view state to display the Login form.
This change reverses all the changes made when changing to the register
view state.
View states give you one way to change the appearance of
an application or component in response to a user action. You can
also use MX navigator containers, such as the Accordion, Tab Navigator,
and ViewStack containers when you perform changes that affect several
components.
Your choice of using navigator containers or states depends on
your application requirements and user-interface design. For example,
if you want to use a tabbed interface, use a TabNavigator container.
You might decide to use the Accordion container to let the user
navigate through a complex form, rather than using view states to
perform this action.
When comparing view states to ViewStack containers, one thing
to consider is that you cannot easily share components between the
different views of a ViewStack container. That means you have to
recreate a component each time you change views. For example, if
you want to show a search component in all views of a View Stack
container, you must define it in each view.
When using view states, you can easily share components across
multiple view states by defining the component once, and then including
it in each view state. For more information about sharing components
among view states, see Controlling when to create added children. For more information on navigator containers,
see MX navigator containers.
Example: Creating a simple view state
The following example shows an application with a default
view state, and one additional view state named "NewButton". In
this example, changing to the NewButton view state adds button b2
to the Group container, and disables button b1. Switching back to
the default view state removes b2 and enables b1:
<?xml version="1.0"?>
<!-- states\StatesSimple.mxml -->
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:s="library://ns.adobe.com/flex/spark">
<s:states>
<!-- Define the new view states. -->
<s:State name="default"/>
<s:State name="NewButton"/>
</s:states>
<s:VGroup id="g1">
<s:HGroup>
<!-- Disable Button in the NewButton view state. -->
<s:Button id="b1" label="Click Me"
enabled.NewButton="false"/>
<!-- Add a new child control to the VBox. -->
<s:Button id="b2" label="New Button"
includeIn="NewButton"/>
</s:HGroup>
<!-- Define Button control to switch to NewButton view state. -->
<s:Button label="Change to NewButton state"
click="currentState='NewButton';"/>
<!-- Define Button control to switch to default view state. -->
<s:Button label="Change to default view state"
click="currentState='default';"/>
</s:VGroup>
</s:Application>
The executing SWF file for the previous example is shown below:
