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
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.
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
android:fillAfter). In my experiments, those
have a visual effect, but that’s it. For example, suppose you
TranslateAnimation to slide a
Button across the
screen. By default, when the animation ends, the
snap back to where it was originally, since there is nothing keeping
Button in the final position. If you try using
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.
fill attributes seem to affect where the pixels of the
View are drawn, but that’s it. If you really want the
to remain where the animation completes, use an
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.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!