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

Easier, Better Transitions in Flex 4

0 (0 Likes / 0 Dislikes)
[Adobe Developer Connection] [codedependent () ;] [keystrokes] [Chet Haase - Flex SDK Team] Today on Codedependent, I'm going to talk about transitions and where you put the values that you're animating from and to. So let's take a look at a simple application. I have an interface with a button in it, and it is going to transition into another screen where the button is moved, and there is going to be a panel in the place where the button was, so I want the effect to be well, let's move the button out of the way first, and then let's fade the panel in. So we can run the application, and say, okay, when I go to the next state, I want the button to move out of the way and the panel to fade in. So that's all very good, so how did that work? So we've got 2 states in the application, and we have our objects declared down here. There's the button that changes state. That's not the one I care about. There's the panel. It is excluded from state 1, so it's only going to exist in state 2. And it's going to exist at the following location and dimensions. And then there's the button itself. It's going to be at x = 0, but when it's in state 2, it's going to be moved over to the right at x = 300, so fairly simple. But what I would really like to do is sort of have 2 different transitions, so I want to go from this state to the next state and then back. So I can do that. I can click the next state toggle, and I can see that's not at all the effect I was looking for, right? Now, on the first transition, the button moves out of the way, panel comes in, and on the second one, everything happens in the same direction, but that's not what you wanted at all. It's a very discontinuous and disturbing effect. So how do we fix that? Well, obviously, we need another transition, right, so let's go in here, and let's create another transition, and we say okay, well we'll use this transition, where we're going toState s2. And then this other one, we'll call when we go toState s1. And I want to do things in a different order, so I want the fade to be first, and I want the move to be second, so we're going to fade the panel out. And then we're going to move the button back into place. So we can move the move operation. I know that I don't need to add action at the beginning, if the fade is happening immediately, so I can remove this guy. So now we've got our fade and our move, so we should be in business, right? So let's run this thing, and we run, and that also wasn't at all what we were looking for. And here is the problem. We have all off this information embedded in the effects about what we want to do when. And so we're saying in the transition up here, we're going from a particular x value to a particular x value in the next state. The fade is happening from zero to 1, right. And then we come down here, and we've got-- well, now we're going from and to the same value, so obviously, that's wrong, so let's change this and we'll say okay, well, in the reverse one, I obviously want to fade from 1 to zero, from fully opaque to fully transparent. And I obviously want to go from an x value of 300, which is where the button is now, to an x value of zero. So let's see how that thing works. Okay, so we go to the next state, and it looks good. And we go to the previous state, fade out, button moves back. That's great. Okay, but I decide, you know what, I really want to shift the button down a little bit. So let's put this at--you know what-- let's have it go to the right a little bit further, so I want to move it over to that value. I want to move it further to the right. So now, when it goes to the second state, it's going to automatically-- Ah, that wasn't quite right, so did you notice at the end, it popped, right? So what's going on is I told the button that in the next state I want it to be at that value of 320, but the effect still has information about animating it to a value of 300, right? And moreover, when the animation starts, you'll notice a little glitch on the reverse animation right at the beginning, where it pops over 20 pixels to the left to start the animation. And the problem is that we've hard coded all of this information about what the values we want to animate from and to are in the effects themselves. Well, the magic of transitions is they can depend upon the state information to extract that information. We don't need this in the effects at all. So let's go ahead and remove this and see what happens. So we're not going to tell it where to move from and to, and we're not going to tell it the values to fade from and to. Instead we're going to let the transitions do what they do best, which is figure that stuff out on their own. So now we go to the next state. We move and we fade the thing in. The button animated to the correct value of 320. And then we go to the previous state. Again, the button animates from the correct value, and the fade happened automatically. So not only was everything more correct this time because the state information actually aligned with the transition information, but the transitions are far simpler to write and to read. None of this information is hard-coded in the effects. Instead, we put the information in the object themselves, and let the transitions just pick it up automatically on the fly. So this comes from real examples that I've seen out there, where people will write these transition effects, and they will embed this information in the effects that is simply a duplicate of what they have in their other code. Not only is it harder to read, and it's more information, and it's a pain to think about all of the property values, but when they change their state information in the code, now there is a disconnect between the effects and the states that they're supposedly based on. So this is the correct approach for using transitions whenever you can. There are particular situations when you can't do this, where you may need to animate from or to a value that's not actually part of the state information. Maybe you're sliding off of the screen before fading it out, and then putting it in some default location. That's fine. Sometimes you need to use hard-coded values, but for the most part, if you're simply animating from and to the values that the objects have in the states anyway, just depend upon the state values themselves. Let the transitions do the work for you. If you want to see the code for this and other related applications, check out my blog at graphics-geek.blogspot.com. [Adobe Developer Connection] [rocket taking off]

Video Details

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

Transition effects rely on state information to specify the values to animate between.  You can hard-code these values in the effects, but in this episode Chet shows why you should avoid doing so.

Caption and Translate

    Sign In/Register for Dotsub to translate this video.