Fixed
Status Update
Comments
ro...@t-online.de <ro...@t-online.de> #2
Thanks! This looks like a bug, thank you for reporting!
ha...@google.com <ha...@google.com>
ap...@google.com <ap...@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
Description
Issue
Currently, it is very hard to implement more complex gesture-driven animations.
ConstraintLayout
or other workarounds. It would be nice to have a convenience API to turn these gestures into an animation progess float (or even directly into aTransition
)AnimatedContent
,AnimatedVisibility
or in theTransition
API. I feel like controlling e.g. a crossfade smoothly with a gesture should be very simple.Proposed Solution
Resulting from these considerations, these are the API additions I propose:
AnchoredDraggableState
(instead of onlyoffset
).Something like:
Transition
/AnimatedContent
/etc. but also provide an animation progress (this would probably require to also provide a source state). For Composables likeAnimatedContent
this should probably be a lambda parameter to avoid unncecessary recompositions.AnimatedDraggableState
into a gesture drivenTransition
(or any other way to link those two) since they would really play well together in my opinion.Concrete Use Case
I have a composable that can be in multiple different layout states (concretely: Item containers (lists) that can be collapsed and then slide off screen). These states don't all include the same composables (once the container has been collapsed it doesn't need to compose its items) and have different sizes (the container shrinks when collapsing). Ideally, I would like to use
AnimatedContent
orCrossfade
for the container shrinking and anoffset
modifier to make it slide off screen.Now I want this animation to be powered by a continuous gesture, but it should be possible to stop in the "collapsed but still on-screen" state. So I would like to use an
anchoredDraggable
with three states and define anchors inDp
. TheDp
difference between "collapsed" and "off-screen" would be exactly the width of the collapsed containers in order to have them slide out in sync with the motion of my finger.I imagine something like this: