Status Update
Comments
si...@google.com <si...@google.com> #2
Thanks! This looks like a bug, thank you for reporting!
si...@google.com <si...@google.com>
si...@google.com <si...@google.com>
di...@google.com <di...@google.com> #3
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.
di...@google.com <di...@google.com> #4 Restricted
di...@google.com <di...@google.com> #5
ju...@gmail.com <ju...@gmail.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
no...@gmail.com <no...@gmail.com> #7
Using the new version 1.8.0-alpha04
does not seem to resolve the issue for me. I tested with the same setting as the reported issue:
// it doesn't matter what you put here a the multiplier, the positionalThreshold is always 50%
positionalThreshold = { d -> d * 0.9f },
velocityThreshold = { Float.POSITIVE_INFINITY },
se...@google.com <se...@google.com> #8
Same. I've run this again on 1.8.0-alpha04. When using
positionalThreshold = { d -> d * 0.1f }
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.
I would expect It to only return if dragged less than or equal to 10% and snap to the end if dragged greater than 10%.
When using
positionalThreshold = { d -> d * 0.9f }
It acts as if the threshold has been set to 50%.
From what I can tell, nothing has changed about the behavior.
se...@google.com <se...@google.com> #9
Thanks, we will investigate and update this issue.
se...@google.com <se...@google.com> #10
bu...@google.com <bu...@google.com> #11
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
There was a missed case when the velocity was negative.
Test: New tests with more parameter permutations
Fixes: 367660226
Bug: 376931805
Relnote: "Follow-up fix for an issue in AnchoredDraggable's target calculation where it could settle at the wrong anchor for specific swipes."
Change-Id: I23b8773d3a694aa3c8de6a8f34b9d7fb54cfe560
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableStateTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt
Hash: 6a23aa4ee37ba171475e4155db0d24c90b358c7e
Date: Fri Nov 08 14:11:31 2024
br...@gmail.com <br...@gmail.com> #12
What is the fix version?
bu...@google.com <bu...@google.com> #13
We will comment on the issue when it has been included in a release. Until then, you can try the snapshot versions from androidx.dev.
ap...@google.com <ap...@google.com> #14
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-alpha07
androidx.compose.foundation:foundation-android:1.8.0-alpha07
androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha07
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha07
ap...@google.com <ap...@google.com> #15
ap...@google.com <ap...@google.com> #16
#15, please report a new issue with a full reproduction case and the versions you are using. Thank you!
ap...@google.com <ap...@google.com> #17
Running compose foundation 1.8.0-alpha07
I'm using AnchoredDraggable with nested scrolling. When I drag and release the lazy layout sometimes the draggable settles correctly and sometimes it doesn't even when i drag and release past the threshold (positionalThreshold = { distance -> distance / 2f }.
internal fun nestedScrollConnection(
dragState: AnchoredDraggableState<Anchors>,
decayAnimationSpec: DecayAnimationSpec<Float>,
orientation: Orientation = Orientation.Vertical,
): NestedScrollConnection = object : NestedScrollConnection {
override fun onPreScroll(
available: Offset,
source: NestedScrollSource,
): Offset {
val availableDelta = available.toFloat()
return if (
availableDelta < 0f
) dragState.dispatchRawDelta(availableDelta).toOffset()
else Offset.Zero
}
override fun onPostScroll(
consumed: Offset,
available: Offset,
source: NestedScrollSource,
): Offset {
val availableDelta = available.toFloat()
return if (
availableDelta >= 0f
) dragState.dispatchRawDelta(availableDelta).toOffset()
else Offset.Zero
}
override suspend fun onPreFling(
available: Velocity,
): Velocity {
val availableDelta = available.toFloat()
val consumedOffset = if (availableDelta < 0f) dragState.animateToWithDecay(
velocity = availableDelta,
targetValue = Anchors.Collapsed,
decayAnimationSpec = decayAnimationSpec,
) else 0f
return Velocity(
x = 0f,
y = consumedOffset,
)
}
override suspend fun onPostFling(
consumed: Velocity,
available: Velocity,
): Velocity {
val availableDelta = available.toFloat()
if (
availableDelta > 0f
) dragState.animateToWithDecay(
velocity = availableDelta,
targetValue = Anchors.Expanded,
decayAnimationSpec = decayAnimationSpec,
)
dragState.settle(animationSpec = spring())
return Velocity(x = 0f, y = availableDelta)
}
private fun Float.toOffset(): Offset = Offset(
y = if (orientation == Orientation.Vertical) this else 0f,
x = if (orientation == Orientation.Horizontal) this else 0f,
)
@JvmName("offsetToFloat")
private fun Offset.toFloat() = if (orientation == Orientation.Horizontal) x else y
@JvmName("velocityToFloat")
private fun Velocity.toFloat() = if (orientation == Orientation.Horizontal) x else y
}
ap...@google.com <ap...@google.com> #18
Hi, this seems to be a different issue. Please provide a full reproducer in a new issue so we can investigate. Thank you!
na...@google.com <na...@google.com> #19
Or, is there some way to look up which is the first build to contain the change?
Description
No description yet.