Status Update
Comments
lp...@google.com <lp...@google.com>
jo...@google.com <jo...@google.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
br...@cfacorp.com <br...@cfacorp.com> #3
ap...@google.com <ap...@google.com> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
jo...@google.com <jo...@google.com>
br...@cfacorp.com <br...@cfacorp.com> #5
na...@google.com <na...@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
vo...@gmail.com <vo...@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 },
br...@cfacorp.com <br...@cfacorp.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.
jo...@google.com <jo...@google.com> #9
Thanks, we will investigate and update this issue.
at...@gmail.com <at...@gmail.com> #10
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@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...@cfacorp.com <br...@cfacorp.com> #12
What is the fix version?
jo...@google.com <jo...@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.
pr...@google.com <pr...@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
0x...@gmail.com <0x...@gmail.com> #15
jo...@google.com <jo...@google.com> #16
#15, please report a new issue with a full reproduction case and the versions you are using. Thank you!
0x...@gmail.com <0x...@gmail.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
}
jo...@google.com <jo...@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!
sj...@gmail.com <sj...@gmail.com> #19
Or, is there some way to look up which is the first build to contain the change?
jo...@google.com <jo...@google.com> #20
Looking at the release notes (
br...@cfacorp.com <br...@cfacorp.com> #21
Unfortunately, this still does not work. I'm on 1.8.0-alpha07 and when I use 0.9f from the original example it still snaps at 50%.
jo...@google.com <jo...@google.com> #22
#21, are you using exactly the same code shared in #1?
br...@cfacorp.com <br...@cfacorp.com> #23
Yes, I'm the OP.
wl...@gmail.com <wl...@gmail.com> #24
sdkmanager "build-tools;build-tools-version"
jo...@google.com <jo...@google.com> #25
Apologies #23, but I am not able to reproduce the issue with the sample from #1, running on Compose 1.8.0-alpha08. Can you please provide a full reproducer project as a zip? Thanks!
r....@gmail.com <r....@gmail.com> #26
Can confirm that positionalThreshold doesn't work, still snaps at 50%.
Here is composable I'm using to test:
@Composable
fun AnchoredDraggableAnchorsFromCompositionSample() {
val density = LocalDensity.current
val state = rememberSaveable(saver = AnchoredDraggableState.Saver()) {
AnchoredDraggableState(initialValue = DragAnchors.Start)
}
val draggableWidth = 200.dp
val containerWidthPx = with(density) { draggableWidth.toPx() }
// Our anchors depend on the density which is obtained from composition, so we update them using
// updateAnchors whenever they are available
SideEffect {
state.updateAnchors(
DraggableAnchors {
DragAnchors.Start at 0f
DragAnchors.End at containerWidthPx
}
)
}
Box(Modifier.width(draggableWidth).background(Color.Gray)) {
Box(Modifier
.size(50.dp)
.offset { IntOffset(x = state.requireOffset().roundToInt(), y = 0) }
.anchoredDraggable(
state,
Orientation.Horizontal,
flingBehavior =
AnchoredDraggableDefaults.flingBehavior(
state,
positionalThreshold = { distance -> distance * 0.95f }
)
)
.background(Color.Red)
)
}
}
Description
Jetpack Compose version: Compose BOM 2024.9.01
Jetpack Compose component(s) used: AnchoredDraggableState, DraggableState, Boxes, Modifiers, and such
Android Studio Build: Build #AI-241.18034.62.2411.12071903, built on July 10, 2024
Kotlin version: 1.9.24
Steps to Reproduce or Code Sample to Reproduce:
See the positionalThreshold in the AnchoredDraggableState. It doesn't matter what multiple is applied to the distance, it always uses 50%. I've tried a bunch of values, even 1.5! Am I using it wrong?