Status Update
Comments
jo...@google.com <jo...@google.com> #2
Thanks for the report! Our UX best practices recommend that components preview the target state. For modal bottom sheets, which have a positional threshold of 56 dp, this means that the scrim's visibility gets determined based on the target value. The target value changes once the positional threshold is crossed. From the UX perspective, we do not recommend gradually changing the scrim alpha.
If you want to deviate from Material's UX, ModalBottomSheetLayout
is probably a good place to start copying the implementation and adjusting this to your needs. However, we understand this is cumbersome while the new swipeable APIs are still internal.
We are still considering different ways of exposing the progress
for modal bottom sheets and other components. It is on our to-do-list, but we are working on some other high-priority tasks at the moment.
Some more nerdy context:
Swipeable is a state machine, and a modal bottom sheet can have three values (Hidden, HalfExpanded and Expanded). The progress is modelled as the fraction of the distance between the current value and target value. For a drag that starts at Expanded
, drags through HalfExpanded
and finishes somewhere after the threshold, the progress will look like this:
1.0f // currentValue = Expanded, targetValue = Expanded
0.9f
0.8f
0.7f // Positional threshold here. currentValue = Expanded, targetValue = HalfExpanded
0.3f
0.4f
...
1.0f // currentValue = HalfExpanded, targetValue = HalfExpanded
(Assuming a positional threshold of 30%)
This makes sense at the Swipeable level, but is a bit confusing as an end-user ModalBottomSheetState API. For the use cases that we see, a (hypothetical) progressBetweenVisibleAndInvisible
API is probably more useful, but we need to have some more explorations.
CC Jose from Material as I believe this would be useful in M3 as well.
ph...@lu.ma <ph...@lu.ma> #3
Thanks for the context and quick response!
Yeah, progressBetweenVisibleAndInvisible
sounds like good API, at least for my needs.
I tried taking 1.3 version of ModalBottomSheetLayout
as base, and indeed it's using some of the internals: I'm missing anchors
and minBound
for PreUpPostDownNestedScrollConnection
. So I had to copy Swipeable
too..
It is on our to-do-list, but we are working on some other high-priority tasks at the moment.
Is it correct that I shouldn't expect it in 1.4.0 release?
jo...@google.com <jo...@google.com> #4
Yep, it won't be in 1.4.0.
ro...@osome.com <ro...@osome.com> #5
This progress can be used not only this case. Designers can create a lot of beautiful UI cases, for example, make parallax effect of background, change color of another contents or something another different things, which I can't imagine right now.
And I faced with the same problem during migration on to compose 1.4
ap...@google.com <ap...@google.com> #6
Branch: androidx-main
commit 762bbc3cea2a9bcfb6fae34e71c6bb8da917f43c
Author: Jossi Wolf <jossiwolf@google.com>
Date: Mon May 15 11:50:25 2023
[M2] Expose AnchoredDraggable components' progress
Fixes: 271169225
Fixes: 276375124
Fixes: 276776071
Fixes: 270066861
Relnote: BottomSheetState, ModalBottomSheetState and BottomDrawerState now expose a progress property indicating the progress between the current (settled) anchor and the closest anchor in the swipe direction.
Test: AnchoredDraggable tests
Change-Id: I1b31727b4f56df890e336bea9f4de526733aaacc
M compose/material/material/api/current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/AnchoredDraggable.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/BottomSheetScaffold.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Drawer.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/ModalBottomSheet.kt
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit 00a9792162b32f60b64eeb5617fd46da749be323
Author: Jossi Wolf <jossiwolf@google.com>
Date: Fri May 12 17:08:38 2023
[M2] AnchoredDraggable Progress API
Improves AnchoredDraggable's progress API to match Swipeable's behavior. The progress is now exposed as the fraction of the current offset between the current (settled) anchor and the closest anchor in the swipe direction.
In contrast to the targetValue, the closestValue does not consider the thresholds.
Test: anchoredDraggable_closestValue, existing progress tests
Fixes: 270066861
Change-Id: I651e06cb34e914a63e13df851b27087d3bbb4257
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/anchoredDraggable/AnchoredDraggableStateTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/AnchoredDraggable.kt
[Deleted User] <[Deleted User]> #8
ph...@gmail.com <ph...@gmail.com> #9
I also expected to see it in 1.5.0-beta02, but it's not there. It's only gonna be available in 1.6?
pr...@google.com <pr...@google.com> #10
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material:1.6.0-alpha01
androidx.compose.material:material-android:1.6.0-alpha01
ju...@google.com <ju...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material:material:1.5.0-beta03
androidx.compose.material:material-android:1.5.0-beta03
na...@google.com <na...@google.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.wear.compose:compose-material-core:1.2.0-rc01
androidx.wear.compose:compose-ui-tooling:1.2.0-rc01
Description
System
ModalBottomSheet
hides scrim quite early after you start swiping - I guess it indicates that sheet is gonna be dismissed at this point.I prefer to have a progressive scrim alpha - it drops smoothly to zero when the sheet is completely closed.
In Compose 1.3.0 I was using
ModalBottomSheetState.progress
to calculate scrim alpha depending on swipe progress.Looks like
SwipeableV2State
API is different fromSwipeableState
at this point. I guess that I can useModalBottomSheetState.currentValue
/ModalBottomSheetState.targetValue
instead ofSwipeableState.progress.from
/SwipeableState.progress.to
, but I still needSwipeableState.progress.friction
which seems likeSwipeableV2State.progress
now.Could you make it publicly available with
ModalBottomSheetState.progress
?