Bug P2
Status Update
No update yet.
Comments
kl...@google.com
Thanks! This looks like a bug, thank you for reporting!
ap...@google.com
I would also recommend setting the value to 10%. When you do that, the behavior is wild.
Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor.
Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.
Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor.
Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.
kl...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <
Link:
Update AnchoredDraggable target calculation logic
Expand for full commit details
Update AnchoredDraggable target calculation logic
We were previously relying on currentValue and the next closest anchor in the drag direction, but the simpler and more reliable way is to look at the left and right anchors as the window.
Relnote: Fixed a bug where positional thresholds passed to AnchoredDraggableDefaults.flingBehavior were not considered correctly in some scenarios.
Test: anchoredDraggable_fling_offsetPastHalfwayBetweenAnchors_beforePosThreshold_doesntAdvance
Bug: 367660226
Bug: 366003852
Change-Id: Ifdf0dfcf3d7ff8288affee56e7092bbed473d6ab
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableStateTest.kt - D
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableTestState.kt - M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt
Hash: eff53304942e9fd4fa5382e0cf487a734c5b8d28
Date: Thu Sep 19 16:24:55 2024
Description
If
ScrollableState.animateScrollByis called and then before it completes it is called again in another coroutine, the first animation will be cancelled before starting the second one. However, unlike calls toAnimatable.animateTo, the velocity of the previous animation will not be preserved.Possible solutions
This isn't a trivial fix because
ScrollableStateitself does not keep any animation or velocity state –animateScrollByis an extension function. It also does not provide any signal about whether it's being scrolled by an animation or the user, so if we track the velocity externally then we could end up in a weird state if the user interrupts an animation.Option 1: Move
animateScrollByintoScrollableStateThis would allow
ScrollableStateto keep track of animated scroll velocity internally. It should also allow it to be reset to zero when the animation is interrupted by a user scroll. However,ScrollableStateis a public interface so to avoid breaking binary compatibility we would need to wait for Kotlin 1.6.20 and then give it a default implementation. The default implementation could simply be the current implementation.Option 2: Expose scroll velocity from
ScrollableStateI'm not sure how feasible this is – tracking velocity requires tracking timestamps, which
ScrollableStatedoes not currently do and would probably make the API super gross.