public class TransitionManager extends Object
USAGE FROM MOUNTSTATE
Unique per MountState instance. Called from MountState on mount calls to process the transition keys and handles which transitions to run and when.
This class is tightly coupled to MountState. When creating new animations, the expected usage
of this class is: 1.
setupTransitions(com.facebook.litho.LayoutState, com.facebook.litho.LayoutState, com.facebook.litho.Transition) is called with the current and next LayoutStates.
isDisappearing(com.facebook.litho.TransitionId) can be called to determine what is/will be
animating 3. MountState updates the mount content for changing content. 4.
runTransitions() is called to restore initial states for the transition and run the new
Additionally, any time the
MountState is re-used for a different component tree (e.g.
because it was recycled in a RecyclerView),
reset() should be called to stop running all
- Transition keys are 1-1 mapped to AnimationState - An
AnimationState has many
PropertyStates (one for each property) - A
PropertyState can have up to one animation.
AnimationState keeps track of the current mount content object, as well as the
state of all animating properties (
PropertyState keeps track
AnimatedPropertyNode, which has the current value of that property in the animation,
and up to one animation and end value. A reverse mapping from animation to property(s) being
animated is tracked in
Combined, these mean that at any point in time, we're able to tell what animation is animating what property(s). Knowing this, we can properly resolve conflicting animations (animations on the same property of the same mount content).
Another important note: sometimes we need to keep values set on properties before or after animations.
Examples include an appearFrom value for an animation that starts later in a sequence of animations (in that case, the appearFrom value must be immediately applied even if the animation isn't starting until later), and keeping disappearTo values even after an animation has completed (e.g., consider animating alpha and X position: if the alpha animation finishes first, we still need to keep the final value until we can remove the animating content).
As such, our rule is that we should have a
PropertyState on the corresponding
AnimationState for any property that has a value no necessarily reflected by the most up to date
LayoutOutput for that transition key in the most recent
LayoutState. Put another
way, animation doesn't always imply movement, but a temporary change from a canonical
|Modifier and Type||Class and Description|
A listener that will be invoked when a mount content has stopped animating.
|Constructor and Description|
public TransitionManager(TransitionManager.OnAnimationCompleteListener onAnimationCompleteListener, com.facebook.litho.MountState mountState)