AnimatorSet.Builder

public class AnimatorSet.Builder
extends Object

The Builder object is a utility class to facilitate adding animations to a AnimatorSet along with the relationships between the various animations. The intention of the Builder methods, along with the play() method of AnimatorSet is to make it possible to express the dependency relationships of animations in a natural way. Developers can also use the playTogether() and playSequentially() methods if these suit the need, but it might be easier in some situations to express the AnimatorSet of animations in pairs.

The Builder object cannot be constructed directly, but is rather constructed internally via a call to AnimatorSet#play(Animator).

For example, this sets up a AnimatorSet to play anim1 and anim2 at the same time, anim3 to play when anim2 finishes, and anim4 to play when anim3 finishes:

     AnimatorSet s = new AnimatorSet();
     s.play(anim1).with(anim2);
     s.play(anim2).before(anim3);
     s.play(anim4).after(anim3);
 

Note in the example that both Builder#before(Animator) and after(android.animation.Animator) are used. These are just different ways of expressing the same relationship and are provided to make it easier to say things in a way that is more natural, depending on the situation.

It is possible to make several calls into the same Builder object to express multiple relationships. However, note that it is only the animation passed into the initial AnimatorSet#play(Animator) method that is the dependency in any of the successive calls to the Builder object. For example, the following code starts both anim2 and anim3 when anim1 ends; there is no direct dependency relationship between anim2 and anim3:

   AnimatorSet s = new AnimatorSet();
   s.play(anim1).before(anim2).before(anim3);
 

   AnimatorSet s = new AnimatorSet();
   s.play(anim1).before(anim2);
   s.play(anim2).before(anim3);
 

Note that it is possible to express relationships that cannot be resolved and will not result in sensible results. For example, play(anim1).after(anim1) makes no sense. In general, circular dependencies like this one (or more indirect ones where a depends on b, which depends on c, which depends on a) should be avoided. Only create AnimatorSets that can boil down to a simple, one-way relationship of animations starting with, before, and after other, different, animations.

Summary

Public methods

public AnimatorSet.Builder after (long delay)

public AnimatorSet.Builder after (Animator anim)

public AnimatorSet.Builder before (Animator anim)

public AnimatorSet.Builder with (Animator anim)