Verified
Status Update
Comments
ti...@google.com <ti...@google.com> #2
Thanks! This looks like a bug, thank you for reporting!
ti...@google.com <ti...@google.com> #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.
ap...@google.com <ap...@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
ti...@google.com <ti...@google.com> #5
Any estimate on when will this release?
ma...@google.com <ma...@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
After offline discussion with Adam we came up with the good idea around AnimaitonDecaySpec and the level of granularity we might want to add.
Basic idea: Let's split AnimationDecaySpec into two abstractions: one will be an per-animation-run "Info" thing that, and the other will allow creation of this "info" things for any particular animation given some input.
Detailed information: Let's split
AnimationDecaySpec
into two things:the API of this will be similar to what we have right now in AnimationSpec, BUT with one big difference: you already have all the knowledge about this particular occurrence of the animation, so you don't need to remember what was your entrypoints (start position, start velocity, etc).
Given that,
will become
and similar with other methods.
(Names are TDB of course).
What this separation gives us: This granularity brings clear separation of concerns and knowledge: one thing lives for a long time and hosts somewhere higher lever (in components, states) and it's generated "Info" objects can flow into lower level abstraction that are one-time fired (such as
AnimatedFloat.fling
oranimateTo
).Additionally, I would suggest to rename Decay to Fling (or just make it part of plain animations api) everywhere because:
For the reference and initial idea: take a look here
Going forward, we can try to stretch this idea to the whole animation, and not only decay/fling part.
Doris, I'd like to know your opinion on this.