Status Update
Comments
il...@google.com <il...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <
Link:
Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling
Expand for full commit details
Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component.
Fixes: b/266550551
Fixes: b/204650733
Fixes: b/255554340
Fixes: b/229537244
Test: OverscrollTest
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere."
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61
Files:
- M
compose/foundation/foundation/api/current.txt
- M
compose/foundation/foundation/api/restricted_current.txt
- M
compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/OverscrollDemo.kt
- M
compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/OverscrollSample.kt
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/OverscrollTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Overscroll.kt
Hash: f64e25b7a473c757d080521e7dd97b3f6670f60d
Date: Fri Nov 01 18:43:56 2024
jo...@google.com <jo...@google.com> #3
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-alpha06
androidx.compose.foundation:foundation-android:1.8.0-alpha06
androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06
jo...@google.com <jo...@google.com> #4
Bugjuggler:
bu...@google.com <bu...@google.com> #5
bu...@google.com <bu...@google.com> #6
jo...@google.com <jo...@google.com> #7
Copying comment from M2 issue:
Looking at the Material guidelines and MDC views, it looks like the gesture only influences how the sheet is drawn. AnchoredDraggable's APIs support this, although we might want to improve the contract of the anchoredDrag
method so users do not have to call settle
manually.
The implementation of this lies with the Material team, reassigning for prioritization:
Here is some example code:
/**
* This receiver allows manipulating the sheet's offset.
*/
interface SheetAnimationScope {
fun seekTo(fraction: Float)
}
/**
* Seek the [ModalBottomSheetState] to fractional values between [from] and [to]. This is useful
* to integrate seeking interactions such as predictive back.
*/
suspend fun seek(
from: ModalBottomSheetValue = currentValue,
to: ModalBottomSheetValue = if (from == HalfExpanded || from == Expanded) Hidden
else if (hasHalfExpandedState) HalfExpanded
else Expanded,
block: suspend SheetAnimationScope.() -> Unit
) {
anchoredDraggableState.anchoredDrag { anchors ->
val startOffset = anchors.positionOf(from)
val targetOffset = anchors.positionOf(to)
val distance = abs(startOffset - targetOffset)
val scope = object : SheetAnimationScope {
override fun seekTo(fraction: Float) {
val newOffset = distance * fraction
dragTo(startOffset + newOffset)
}
}
scope.block()
}
anchoredDraggableState.settle(0f)
}
PredictiveBackHandler { progress ->
bottomSheetState.seek(to = ModalBottomSheetValue.Hidden) {
progress.collect { backEvent ->
seekTo(backEvent.progress)
}
}
}
se...@google.com <se...@google.com> #8
CC: Dan, is this within the scope of your predictive back work in compose?
dn...@google.com <dn...@google.com> #9
Yes! Working on this in
With the approach in the CL above, ModalBottomSheet
will automatically animate itself during the predictive back swipe gesture on U+.
dn...@google.com <dn...@google.com>
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit 699ee4fa3f47da2ccd52fb6b4628fc2d61cd5039
Author: Dan Nizri <dniz@google.com>
Date: Wed Dec 06 20:50:22 2023
Update Compose M3 ModalBottomSheet to support Predictive Back on U+
Bug: 281967264
Bug: 307969902
Bug: 304850357
Test: added screenshot tests
Relnote: "Update Compose M3 ModalBottomSheet to support Predictive Back on U+"
Change-Id: Iccf324cb6dfc7f4ea1fe413b69e035658282360d
A compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ModalBottomSheetScreenshotTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ModalBottomSheet.android.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/SearchBar.android.kt
A compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/PredictiveBack.android.kt
dn...@google.com <dn...@google.com>
pr...@google.com <pr...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha01
androidx.compose.material3:material3-android:1.3.0-alpha01
androidx.compose.material3:material3-desktop:1.3.0-alpha01
Description
With Android 14, apps can opt in for predictive back where they show a preview of what is happening as the system back gesture is happening (rather than only after the user confirms the system back gesture).
The Activity 1.8.0 release adds a new
PredictiveBackHandler
that allows apps to capture theprogress
of the system back gesture and use it to drive the state of their own components.I wanted to use this to start hiding a Material3 Bottom Sheet by writing code like:
But as per the two TODO messages there, I ran into two issues:
There's no way to drive the progress towards the hidden state from outside the bottom sheet - I see that
ModalBottomSheet
does this internally to support dragging the bottom sheet down, but this isn't exposed anywhere.The use of a
suspend
show method here doesn't actually work well inPredictiveBackHandler
since the scope that is provided to the trailing lambda is cancelled by the time we need to callshow
(similar to other suspending lambdas, it uses coroutine's cancellation as its indicator for cancellation). It would be helpful to have a non-suspending way to set thetargetValue
and letModalBottomSheet
take care of moving to that state. I think we could possibly work around this by usingrememberCoroutineScope
and launching theshow
into that scope, but that seems even harder to get right.