tree e61810608bb1ed55b6966420f45329c83a5b768b
parent c9cb92f1dac0b1ee62267516c6de0590308b2e8c
author Gabriel Peal <gpeal@users.noreply.github.com> 1642134213 -0800
committer GitHub <noreply@github.com> 1642134213 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJh4PrFCRBK7hj4Ov3rIwAAewAIAG1D9CELHFRnBfXvMCNrcvxx
 hKUQqeGA2az89ZGlNdvSMyXvJ1g4rusykeytYGaSXpAXTByPrecp6F0SS02abtri
 jLUSZJnhGJ3Q297N8LRUwXl/4XLgj5nYeu+Ui/BrlN3NvOIQ2Exwmih8puIy3LpB
 UNAR1wyh/5r4odDnxL02J04H/tTdMtCnHN4MHHJXLLzByuHh9bVjikmWvnhlhnaA
 Yt8NZuMm5FlO5vOUyON33HLKbeUdbeksO5zNdvcaj/6ST5Y8jAwRf4OqhMCocVJ5
 8+kjn8KB7Qa+2csQKWxvSsV0H75rKw3skDWqs4pTZRIuxFaCGePF44I7xEKoqeQ=
 =sMGb
 -----END PGP SIGNATURE-----
 

Move window/view visibility handling from LottieAnimationView to LottieDrawable (#1981)

Previously, all of the logic to pause/resume Lottie animations on events such as hiding a view, backgrounding an app, etc. were handled by LottieAnimationView. This logic works fine for the default cause. However, LottieDrawable had no notion of visibility handling itself. As a result, if somebody were to use LottieDrawable on its own, they would have to get the lifecycle exactly right or else they could risk leaking animators and impacting the user's battery life.

This PR combines all of the logic into Drawable.setVisible. This also simplifies things because it is a single API vs views that have to deal with window attachment and visibility changes.

I ran all existing FragmentVisibilityTests and they all pass and the intention is to maintain backwards compatibility.