You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Developers who take screenshots of their app during integration tests will find that Lottie animations load + play asynchronously during those tests, resulting in inconsistent captures.
Describe the solution you'd like
Provide a way to guarantee that Lottie animations will always be visualized on a consistent frame (e.g. either the min frame or the max frame of the animation) during integration tests.
Lottie already respects 0x System animation scale (the standard setting for integration tests) by jumping to the last frame of an animation. Espresso only needs to be aware of, and "idle" on, onCompositionLoaded events.
Describe alternatives you've considered
In my own repo, I've introduced a subclass of LottieAnimationView which maintains a global counter of compositions that are still loading. I then feed this number into an idling resource which only considers itself idle when the count is 0. To ensure my subclass of LottieAnimationView is used globally, I built a custom LayoutInflater.Factory2 which special-cases the inflation of com.airbnb.lottie.LottieAnimationView tags.
It would be neat to have a library-native way to hook into this global composition count, or more ideally: be able to specify a global composition-loading callback so that we can have knowledge of those events in Espresso.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
cmathew
changed the title
Feature request: Facilitate idling on animations during Espresso tests
Facilitate idling on animations during Espresso tests
Jan 3, 2022
Thanks @gpeal! We previously used something much like LottieIdlingResource in select integration tests. But since it only works a per-LottieAnimationView basis, we began searching for a global (integration test runner-level) idling solution.
I'm thinking now that maybe I could combine my current approach of providing a custom LayoutInflater.Factory2 with LottieIdlingResource. I.e. provide a special LayoutInflater.Factory2 during integration tests which associates each LottieAnimationView that it inflates with an LottieIdlingResource. I'll explore that.
Is your feature request related to a problem? Please describe.
Developers who take screenshots of their app during integration tests will find that Lottie animations load + play asynchronously during those tests, resulting in inconsistent captures.
Describe the solution you'd like
Provide a way to guarantee that Lottie animations will always be visualized on a consistent frame (e.g. either the min frame or the max frame of the animation) during integration tests.
Lottie already respects 0x System animation scale (the standard setting for integration tests) by jumping to the last frame of an animation. Espresso only needs to be aware of, and "idle" on, onCompositionLoaded events.
Describe alternatives you've considered
In my own repo, I've introduced a subclass of LottieAnimationView which maintains a global counter of compositions that are still loading. I then feed this number into an idling resource which only considers itself idle when the count is 0. To ensure my subclass of LottieAnimationView is used globally, I built a custom LayoutInflater.Factory2 which special-cases the inflation of
com.airbnb.lottie.LottieAnimationView
tags.It would be neat to have a library-native way to hook into this global composition count, or more ideally: be able to specify a global composition-loading callback so that we can have knowledge of those events in Espresso.
Additional context
N/A
The text was updated successfully, but these errors were encountered: