Sequential Animations

I_Artist has a blog post up regarding issues with the animation documentation. He is absolutely correct in his general theme, that the documentation is lacking. However, one of his statements is equally incorrect.

With regards to animation sets, I_Artist writes:

Transformations by default are not sequential, but are composite. The only way to make them sequential is by timing them against the beginning of the animation, NOT against the previous transformation.

Nonsense! Use an AnimationListener. In onAnimationEnd() of the first animation, call startAnimation() to kick off the next in sequence. This works like a champ. It also addresses I_Artist’s concern:

That means that transformations are not timed relative to each other but rather against the beginning of the full animation. Therefore if you have 10 transformations in a file that you timed to start sequentially and then decide that you want to change the delay of the first transformation, well then you have to change the timing for every transformation in the file.

By using AnimationListener, if you change the timing of the start, everything else follows along as planned, without modifying each and every animation.

I am also decidely nervous about I_Artist’s use of the fill attributes (e.g., android:fillAfter). In my experiments, those have a visual effect, but that’s it. For example, suppose you use a TranslateAnimation to slide a Button across the screen. By default, when the animation ends, the Button will snap back to where it was originally, since there is nothing keeping the Button in the final position. If you try using fill parameters to have the Button stick to where the animation ends, it looks like it works…but the actual “hot spot” for the click action is back where the Button was originally. The fill attributes seem to affect where the pixels of the View are drawn, but that’s it. If you really want the Button to remain where the animation completes, use an AnimationListener, and in onAnimationEnd() do something to adjust the layout rules such that the Button winds up where you want it.

There is nothing wrong with the fill attributes, so long as you recognize the limits of their behavior.