What does people use to avoid multiple input event...

# compose-android

[David]

What does people use to avoid multiple input events? dropUnlessResumed , dropUnlessStarted, or something else? dropUnlessResumed doesn't allow any clicks while the view is animating in. Which has caused some troubles for us in UI tests as some clicks are ignored because it is too fast, this can also in some cases be experienced as a user as well. Would there be any drawbacks of using dropUnlessStarted instead of dropUnlessResumed ?

[Stylianos Gakis]

Depends when you want to drop the events tbh.
If it's to drop navigating twice for example, your only option is Resumed, since the composable only leaves the Resumed state when it starts the navigation animation.
If your UI test fails to navigate due to that, if anything that's expected behavior, as you don't want the navigation to work then. You might have to await until the lifecycle has settled before doing the click.

With that said, if the use case isn't navigation, what is it, and when do you want to drop it? If the lifecycle is below even Started, they probably won't be clicking anywhere in your app, don't know scenarios where this would happen.

[David]

Clarification, the use case is navigation. 🙂
> If it's to drop navigating twice for example, your only option is Resumed, since the composable only leaves the Resumed state when it starts the navigation animation.
Why wouldn't dropUnlessStarted be an option? From my testing when navigate is invoked the old view will enter CREATED state. So do conclude:
• On a new screen entering, it is STARTED while it is animating in.
• The previous screen will leave RESUMED & STARTED immediately and be in CREATED lifecycle state.
When it comes to predictive back, it goes to STARTED when the back animation is started, once you lift and execute the back action it goes to CREATED

[Stylianos Gakis]

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigati[…]oidx/navigation/compose/NavHostPredictiveBackTest.kt;l=55-104
Yeah that seems to check out here. You can also double check your findings in their test too.

So using dropUnlesStarted will mean that you will be able to click on such buttons on the screen animating IN, but not on the one animating out right?
And you will be able to interact with both screens while the back gesture is going on.

I suppose at that point in depends on if you wish for those two scenarios to be true, or if you want to be able to navigate only when the state is resumed and settled

[David]

So using dropUnlesStarted will mean that you will be able to click on such buttons on the screen animating IN, but not on the one animating out right?

Yeah this is how I interpreted it.

And you will be able to interact with both screens while the back gesture is going on.

From testing while you are doing a predictive back gesture, input are blocked. So you wouldn't be able to click anything.

[David]

When this function was introduced the dropUnlessResumed was proposed as an example for navigation. Not sure if this is intentional to use it instead of dropUnlessStarted , I guess one should not read too much into it.

[Stylianos Gakis]

Won't the state still need to settle for a little while after the back gesture was let go? Maybe this is milliseconds, but I would be curious nonetheless.

Yeah it was an example, I don't think that by itself qualifies as a "this is the only way to do nav event dropping", so I agree with you.

I'd say try the drop unless resumed and let me know in one month if you've regretted it at all 😅 right now, I can't come up with a reason not to, judging from that test.

[Ian Lake]

Note that in the future where there is a Predictive back peek animation even when using three button navigation, input is not blocked, so you definitely want to be using dropUnlessResumed if you only want clicks in the settled cases