Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Flex 4 States and Transitions

0 (0 Likes / 0 Dislikes)
[ringing sound] [ADOBE DEVELOPER CONNECTION] [keyboard clicking] [codedependent () ;] Today on CodeDependent I'm going to talk about states and transitions. [Chet Haase - Flex SDK Team] This is a demo that's based on demos from my book, "Flex 4 Fun," [Flex 4 Fun - http://www.artima.com/shop/flex_4_fun] We're going to be covering a little bit about the Flex 4 states syntax, the new, improved states syntax, as well as transitions and why and how you might use them. So let's take a look at the demo first. We have a simple screen here. It's got a little search box. We can type in something. Let's say we want to know about condiments. Click on the Search button, and then we get the results screen here. Pretty simple. We've got a little data grid to display our stuff here, we had the search box up here, we have the Search button from the original screen, and then there was some other information on the original screen that went away. Let's see how we set that up with the new states syntax. First of all, we have our states block here where we say, "These are the names of the states." Notice if anybody has tried to use states prior to Flex 4, the states block used to have a lot more information in there about adding children and removing children and setting properties and styles and all that stuff. All that stuff now is done in line with the objects themselves, and instead, the states block now consists just of the names that are going to be used for the different states of the application. So we have a search screen state and a results screen state. The label that you saw in the first screen-- Here's the label where it says Food Item. That says, "Okay, I'm going to be included in the search screen." So it's not going to be in the second screen; it's going to go away between going from the first state to the second state, to the results screen. The text input box--this guy right here-- that is right here, and it's going to be on both screens, so it doesn't have that Include In states syntax. Instead, it says, "Okay, my X and Y position are the following." That's the default location of this object. But then when I'm on the results screen, I'm going to be at this different location. So I say x.resultsScreen equals the X information for that other state. Same thing for Y. So it's going to exist in the second state. It's just going to exist in a different place. And the same thing for the search button itself. When you click on it, it runs the search, and that basically just does a state change. And it's going to be positioned differently in the results screen. The other little twist here is that we have a nicety about not enabling the button until there's something in the text box. You can see the button is disabled by default. But then when we start typing into it, then the search button is enabled there. So we click on the search button, we can see the text box exists up there, the search button is up there, and then we have this new data grid object. The data grid says Include In results screen, so that also doesn't exist in the first screen, but it does exist in the second screen. So all of that is really good. I really like the states syntax. It's a lot more obvious, I think, how to write it and how to read it and understand what's going on than the previous syntax. This is one of the big reasons, I think, to move to Flex 4, at least if you're doing a lot of MXML coding and you're using states. But it's kind of a discontinuous experience, right? So let's run it once more. So we run this, we type into the box, and then we go to the second screen and we just get this first screen erased, second screen painted in place. One of the things that I like best about the Flex platform overall is the concept of transitions, the idea of actually being able to bring the user from state to state as you go through the application. You don't have to just pop a new UI in front of them. Instead, you can tell them in an ongoing story how you got to that new screen from the screen where you used to be. So let's see how that works. Let's go to this other version of the same application. We've got our little search box, we click on the button, okay. So we've got a nice little animation there. Let's do it one more time. [keyboard clicking] Click on the button. We're going to see Food Item fade out, and we're going to see the other two items move, and then we're going to see the results screen fade in. So how did that work? Let's take a look at the transitions block. Otherwise, outside of the transitions block, everything about this version of the application is exactly the same as what we saw before. But then we had this new transitions block, and this says, "Okay, whenever the state changes, I want you to run the following transition." And a transition is basically a data structure that contains information about the screens that it's going from and to and the effect, the animation effect, that is going to play when that transition plays. So the effect is going to be a sequence. We're going to do these things in steps. First we're going to fade out that label. The Food Item label is going to fade out. After that happens, we're going to move two items-- the search button and the text input box. Text input box is going to move up there. The button is going to move to the upper right. Then we're going to add action on the results screen. This is a way to delay adding something new into the GUI until you're ready for it. In this case, we don't want to fade that guy in until these other actions have happened, so we're going to wait until that point, and then we're going to add the results screen in and we're immediately going to fade it in. We're going to fade it in from an alpha of zero so that it won't simply appear but instead, it's going to appear on the display list, but it's going to be completely transparent, and then it's going to fade in over time to get that effect we want. One of the most important things to notice about the transitions is how easy they are to use, because they depend upon the state information. So the fade, for instance, doesn't say, "I want you to fade this guy out." It knows that the label is going away, so it's automatically going to fade it from completely opaque to completely transparent. The move operation, you don't have to tell it to move up there and over there. Instead, it knows where those objects were in the first screen and where they're going to in the second screen, so it can supply that information automatically to the effect. And the fade for the results data grid, of course, is the same thing. It knows that it didn't use to exist; now it does, so it's automatically going to fade it in from completely transparent to completely opaque. So states syntax in Flex 4 coupled with transitions. Very powerful mechanisms for making rich UIs that actually help your users understand what's going on in the interface. If you want to see the code for this application and other related applications, check out my blog at graphics-geek.blogspot.com [Chet's Blog - graphics-geek.blogspot.com] [ADOBE DEVELOPER CONNECTION]

Video Details

Duration: 6 minutes and 36 seconds
Country:
Language: English
License: All rights reserved
Genre: None
Views: 171
Posted by: adobetv on Oct 21, 2010

Chet shows how the simple state syntax in Flex 4 makes state code easier to write and read. He also highlights how transitions can create a more engaging experience when changing application states.

Caption and Translate

    Sign In/Register for Dotsub to translate this video.