Status Update
No update yet.
Comments
tc...@google.com
Assigning to Shep as we need to build it in Modifier.pressIndicatorGestureFilter().
For context, how it works in Views currently:
Note that we add this delay there only if we are inside the scrolling container, worth exploring if we can do similar thing in Compose
ra...@google.com
I gave it some thinking and my current inclination is that it doesn't make sense at all to make it a foundational requirement.
It's a grey areas, but still it strikes me as a design choice more than a general concept, so I wonder if we can just add delay(80) to our ripple logic to solve the issue, but allow other indication/design system devs to decide on their own.
Louis, wdyt?
ap...@google.com
This shouldn't be inside our Ripple, as it applies not only for this ripple. Plus once we migrate to the ripple imlementation based on RippleDrawable we would still need this delay. I think this should affect all indications
ra...@google.com
I agree, I think this is core touch slop behavior for Android - it doesn't matter what the indication type is, we probably just don't want to propagate the down event until we are sure it wont' be the start of a scroll event
Description
val (focusRequester1, focusRequester2) = FocusRequester.FocusRequesterFactory
val (focusRequester1, focusRequester2) = FocusRequester.createRefs()
Things that we should improve on:
1. Both of these appear next to each other in autocomplete, and we would like users to use createRefs() instead of FocusRequesterFactory.
2. Issues relating to remembering the FocusRequester. (Not an issue for the functionality of FocusRequester, but if this pattern is used in other APIs that need remembered objects, this could be an issue)