Handles animating transitions defined by ComponentSpec's onCreateTransition code.
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, java.util.ArrayList<com.facebook.litho.Transition>)
is called with the current and next LayoutStates.
2.
isKeyAnimating(java.lang.String)
and
isKeyDisappearing(java.lang.String)
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
animations.
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 existing animations.
TECHNICAL DETAILS
- Transition keys are 1-1 mapped to AnimationState
- An
AnimationState
has many
PropertyState
s (one for each property)
- A
PropertyState
can have up to one animation.
An
AnimationState
keeps track of the current mount content object, as well as the state
of all animating properties (
PropertyState
s). A
PropertyState
keeps track of a
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
mAnimationsToPropertyHandles
.
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
LayoutOutput
.