WAI
Status Update
Comments
ma...@google.com <ma...@google.com> #2
Thanks! This looks like a bug, thank you for reporting!
da...@danielzfranklin.org <da...@danielzfranklin.org> #3
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.
ma...@google.com <ma...@google.com> #4
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
ap...@google.com <ap...@google.com> #5
Any estimate on when will this release?
je...@google.com <je...@google.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-alpha04
androidx.compose.foundation:foundation-android:1.8.0-alpha04
androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha04
Description
I had code that required detecting a number of different gestures that were possible only in certain states. I started off using the gesture detecting functions and global variables like so:
I eventually traced a number of bugs down to updating the state non-atomically, so I was planning to add a mutex. That reminded me of how coroutines can often be used to solve concurrency issues, and I came up with
I defined a bunch of my own functions on
PointerInputScope
, and the approach solved my concurrency issues in a relatively clean way.The problem is that most of the framework detectors block forever, so they can't be combined. I ended up copying a framework function, editing it to remove the line
forEachGesture {
, and copying over all their private/internal dependencies.I'm suggesting that framework gesture detector functions should (when it makes sense) delegate to another public function that detects only one gesture.
I'm also suggesting that more of the private helpers you use in gesture detection be made public, such as
awaitLongPressOrCancellation
, to enable users to write code that combines small suspending functions to detect complex gestures as cleanly as the framework.