DevBytes: Window Animations


Hi. I’m Chet Haase, an engineer on
the Android team at Google. I work on graphics and
animations, and today I wanted to talk a little bit about
window animations. In another show that we did we
saw a little bit about view animations, which are the
animation APIs that you can use for releases prior to 3.0. There’s a more complete
animation system starting with 3.0, but if you’re doing window
animations you still want to use the animation
resource files of the older APIs. So we’ll see how to use those
today to get to try the kinds of transitions between
activities and subactivities in your activity. So let’s take a look
at a demo. I call this demo window
animations. And you’ll see a few buttons and
then a little bitmap down at the bottom, and each of the
buttons enables a different type of window transition as
it goes between the main activity and the subactivity. So default animations, you just
get whatever the system provides you, which is
the scale fade– at least on the current
platform. It’s the scale fade activity, so
we scale and fade in and we scale and fade out. That’s the default. You can do translate animations,
so you can provide a custom animation of any type
that you specify using the view animation system. In this case, we’re going to
slide things in and out. So the translate animation
slides in the new activity, slides out the old activity, and
then when you back out we get sort of the reverse thing,
which is actually a separate animation as we’ll see in
the code in a minute. Scale animations is a new
capability that came online in Jelly Bean where you can
actually specify a subrectangle to launch the new
activity from and it’ll scale up from that point. So it’ll start out
at the view– the visuals that it’s going to
have when it’s running in the full screen and then
it’ll simply scale that up over time. So scale animation launches that
window from the location that I gave it, which is
relative to that button that we clicked on. Now you’ll notice that although
we scale into the activity, we still get some
defaults or nonscaling animations when we
back out of it. This is a limitation of the
current system where we can’t scale back out of it. Instead, we can just use the
prior way of translation or scale fade or whatever
other kind of animation that you want. And then finally, we have the
bitmap at the bottom, which is another variation of the scale
animation where you can specify not only the
subrectangle to scale from but also the bitmap to start from. In this case, I took a
screenshot of what the activity was going to look
like and I saved it at a smaller size. We’re simply going to scale
up from that one into the larger one. So we can see that we get
exactly the same kind of view scaling up into the
larger activity. Now what that’s hiding is that
we’re actually crossfading from one representation
to the other. So it starts out at the smaller
bitmap and then as it scales up, it also crossfades
to the full screen representation of
the subactivity. So that’s the demo, but the more
interesting part is the actual code– how does
this stuff work? So we can take a look at this
class I’ve defined called window animations. And in here, we have the buttons
that we saw on the screen and then we have
an image view that holds that bitmap. And as you click on each of
the buttons, you get a different kind of effect
depending on what we were trying to do with window
animations. The default button just uses
the system behavior. So when you click on that, it
launches this subactivity. Let’s take a quick look
at subactivity– not much going on there. It’s just a subactivity. It only exists to provide
something for us to look at when we transition to
the subactivity. So all it does is launch the
subactivity and then the system itself just takes care of
doing the translation, the default scale fade transition
than it normally has. The translate button, the second
button down, did a custom animation where we slid
the new activity in, slid the old activity out. And then on the way back out, we
slid to the right instead, sort of a nice reversing
behavior. It gives kind of an indication
of the flow of the application in and out of the subactivity. So here we launched a different
subactivity which we call animated subactivity. And I’ll show you in a second
why we are using not just the regular subactivity. And then we created a bundle,
an activity options bundle, and said OK, well, here’s this
custom animation that we’re creating and we’re going to load
in a couple of resources here so we can take a look at
those in our resources folder. In the anim directory we have
a slide in left resource, which is a translate animation
that’s going to slide in and have the duration capabilities
specified in it. So we’re going to start
at it from x delta. So we’re basically going to
start off the screen 100% of the width of my parent and then
we’re going to slide into an x delta of zero. So we’re going to start out
there and then slide in over a duration of 500 milliseconds. Go back and we can take a look
at the other animation we’re specifying. So that was for the new activity
coming in and then slide out left was for the
activity going out. Slide out left we
can see here. And then this one starts from
an x delta of zero, so basically where that activity
is now, and it’s going to slide to half the width of
the parent out over 500 milliseconds. So it would be sort of
a parallax effect. They’re actually going
at a different rate. It’s not just moving together
in lockstep, but instead one is moving faster than the other
is going out– kind of a nice effect there. Now the reason we had an
animated subactivity there is because the transitions that we
specify here for the window animations only control what
happens when we go into the subactivity. But what if we actually want
to have a custom transition coming back out of that
activity as well? For that, we need a little bit
of code in the subactivities. So instead of using the normal
subactivity with no behavior specified here, we have this
animated subactivity. And here we override the finish
method, call super, and then override pending
transition. Then we specify different
transitions, which we don’t need to go in and look
at the code. It’s fairly straightforward. Basically we’re sliding the
subactivity out to the right and then sliding the main
activity in to the right as well, sort of the reverse from
the transition that we did to begin with. So now we can go back and look
at the original code and see the more interesting stuff,
what’s going on with those thumbnail scaling animations
instead. Again, we use the activity
options. This is the one where we scaled
up from the button itself and we basically give
it the rectangle that it’s going to scale from. But for the content that’s
actually going to scale on the screen, it uses the content
of the full screen activity itself. So we don’t need to specify
anything else there. We just say where do you start
from and how large are you and then it takes care of all
the rest of scaling that thing in over time. And finally on the last one,
when we’re actually scaling in from a thumbnail we not only
give it the location that it’s going to scale from, but we also
give it the bitmap that it’s going to use. So it’s going to start with that
representation and then scale up and fade into crossfade
into the full screen activity that you’re
going into. So here we create this bitmap. We’re actually just
loading a bitmap. This is the screenshot
that I took earlier and saved as a drawable. And then we create some activity
options with the appropriate parameters and
start the activity. And then the window animation
just uses that bundle to run the appropriate animation. So these are window
animations. They are useful for giving
a custom look to your application, your activities. It’s important to point out
that you can do this for subactivities. It’s a little trickier to do
it for main activities, and the general advice is don’t. It’s kind of nice for the users
to have a consistent experience across the device as
they’re using the main UI, and part of that is getting
consistent transition behaviors as they launch
activities. Now once they’re in your
activity, that’s a custom experience. That’s totally understandable
how you might want to customize that according
to what your application needs to do. But as far as going between
activities or just launching it from the launcher screen,
it’s kind of nice to let the default system behavior still
stay intact and use the custom window animations for the
activity transitions actually within your activities. Thanks for tuning in.

David Anderson

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *