Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).
il...@google.com <il...@google.com> #3
I have a similar issue with plain AnimatorSet:
set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()
doesn't play animation in resume().
Description
The Fragment library has three different systems for doing view effects;
Animation
,Animator
, andTransitions
.Animations
were first, then they were followed byAnimators
to address any short comings, andTransitions
were built usingAnimators
.The new state manager introduced SpecialEffectsController which attempts to manage all of these effects and ensure their behavior is consistent. Where the old state manager started effects and kept going, the new state manager does things like waiting on entering effects to finish before moving to a Fragment to
RESUMED
and waiting on exiting effect to finish before destroying the Fragment's view.With some issues . Unfortunately, there isn't much we can do to address these and therefore, we should handle
Animators
andTransitions
, this is all works wonderfully, but withAnimations
there areAnimations
independent of the other effects and also hold them at a lower priority.This has two main implications:
Animations will only be run if there are no
Animators
orTransitions
present. This ensures we don't get any unexpected behavior from mixing systems and gives the other effects priority.Entering Animations will not be part of the fragment lifecycle. So your fragment will not wait until an entering Animation is complete to move to RESUME.
Everything that you can do in an
Animation
should be applicable to anAnimator
as well. Whenever possible, you should always opt for usingAnimator
overAnimation
.