Status Update
Comments
js...@google.com <js...@google.com>
lp...@google.com <lp...@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.
nj...@google.com <nj...@google.com> #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?
Description
It'd be nice if
Divider
supportedDp.Hairline
. In its current implementation, the divider becomes invisible ifDp.Hairline
is used.I'm currently working this around by manually calculating
1px
indp
:I'd also like to call it out that it feels weird to have
Dp.Hairline
globally available, only to realize that it's up to Composables to manually support it(?). From what I understand, onlyBorderStroke
andModifier.border
account for hairlines inv1.0.1
.