Advertisements
|
||
|
In a previous article, State-Specific Property Values in Flex 4, I talked about the new states syntax in Flex 4. In particular, that article covered the states syntax to automate changes in property values when going between screens in an application. In this article, I'll be continuing the discussion of the SearchMe
application, but adding transitions to animate the property changes.
How often have you found yourself using an application, or navigating a website, and the entire UI changes out from under you and you have to figure out what's where and what to do about it? The Submit button moved, the shopping cart total scrolled off the page, and the search results now cover the area where you thought you were supposed to enter refining search terms. This is unfortunately a common experience with GUI applications. When the application changes to a new screen, even if the new screen shares elements with the previous one, the typical application erases the current information and draws the new UI in its place, forcing the user to do the hard work of parsing all of the information in the new GUI.
This is why Flex transitions were invented; to take the user along for the ride, bringing them smoothly between the screens and states of the application. Transitions enable you to animate changes in state, which helps your users understand the changes as they happen. Applications must alter the information on the screen often during the course of being used. The more that you can bring your user along with the UI as these changes occur, the faster they will be able to understand what they need to do and the more productive they will be.
Transitions work hand in hand with states, which was discussed in two previous articles. States in Flex are a powerful way to set up the changing behavior of your application. But the combination of states plus transitions makes for very compelling user experiences. Transitions provide a way to give a smooth, continuous experience to the user as they navigate the application between different states. Repositioned objects glide into their new locations, objects that go away fade out, objects that appear do so gradually. Animations can be used for every change to help the user understand the differences in the new screen.
SearchMeTransition
Let's return to the search example in the previous article on Flex 4 states. On one screen we have the label, searchLabel
, defined in that single state as follows:
<s:Label id="searchLabel" x="107" y="66" text="Food Item" fontSize="18" fontWeight="bold" includeIn="searchScreen"/>We also have the
searchInput
and
searchButton
elements that are located in different
x
and
y
positions in the two states:
<s:TextInput id="searchInput" x="86" y="91" x.resultsScreen="84" y.resultsScreen="10"/> <s:Button id="searchButton" x="115" y="121" label="Search" enabled="{searchInput.text != ''}" click="runSearch()" x.resultsScreen="220" y.resultsScreen="10"/>Finally, we have the
searchResults
list that only exists in the
resultsScreen
state:
<mx:DataGrid id="searchResults" 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>I'd like a transition effect that fades the label out, moves the input and button elements into place, and fades the results list in. If all of these animations ran at the same time, the screen would be a mess, with the various elements moving and fading all on top of one another. While simultaneous animations are appropriate in some situations, they don't work as well when the target objects are in the same area, especially when their actions are different (fading versus moving).
I'll stagger the animations instead. First, the label will fade out. Once it is gone, the input and button elements have a clear field to move up to the top of the screen. And once those objects are out of the way, the results list can be faded into place. Here is the resulting transition:
<s:Transition toState="resultsScreen"> <s:Sequence> <s:Fade target="{searchLabel}"/> <s:Move targets="{[searchInput,searchButton]}"/> <s:AddAction target="{searchResults}"/> <s:Fade target="{searchResults}"/> </s:Sequence> </s:Transition>Here, the transition runs automatically when the application's
currentState
is changed to
resultsScreen
. A
Sequence
effect is used to stagger the animations to run one after the other.
First, we run a Fade
effect on the searchLabel
, which fades out automatically because the transition knows that it is going away between these states. Next we run a Move
effect on the input and button to shift them to their new locations. This effect picks up the locations of the elements automatically and moves them to their correct positions in the new state. Next we run an AddAction
effect on the resultsList
object, which is there to keep the results list from appearing until we're ready to fade it in. Now that the results list is ready, we Fade
it in. Again, Fade
knows that it needs to fade the object in, not out, because the transition knows that the object is coming into existence, so Fade
automatically does the right thing.
Here's the resulting application. Click on the button to cause the state to change and the transition to run.
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.
Transitions are one of my favorite things about the Flex platform. In a world where many platforms make animations hard to figure out, or difficult to use, or impossible to get right, transitions make it possible to get very powerful animated effects automatically by requiring only that the developer tell the system what they want to animate (e.g., <cocomment>button1
</cocomment> ) and how (e.g., Move
), and the transition system itself figures out the details of how that object changes between states and runs the animations to get it there. It's a simple, declarative way of getting very rich GUI effects that help the user understand the application UI.
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
Have an opinion? Be the first to post a comment about this article.
Chet Haase worked as a senior computer scientist on the Flex SDK team at Adobe Systems, Inc., during 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 posts regularly to his technical blog at http://graphics-geek.blogspot.com, where you can find articles, videos, demos, and plenty of source code. 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.
Artima provides consulting and training services to help you make the most of Scala, reactive
and functional programming, enterprise systems, big data, and testing.