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.