Status Update
No update yet.
Comments
se...@google.com
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
to...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-alpha06androidx.compose.foundation:foundation-android:1.8.0-alpha06androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06
se...@google.com
va...@google.com
One option here would be adding another window insets parameter, which is applied to the sheet's surface itself, rather than the content within in sheet's surface.
to...@gmail.com
Yes that's be the normal way, but I guess for 1.4 now that beta is branched and API locked.
to...@gmail.com
BTW with Android 15 new way to deal with edge to edge and display cutout by default is there an official M3 bottomsheet design recommendation for the handling of those horizontal insets ?
Should the bottomsheet go under the cutout and nav bar with a content padding or should the bottomsheet have actual insets and show the below content in those areas?
to...@gmail.com
Can we have some feedback on this one ?
Maintaining a copy of M3 components, specially those migrated to multiplatform is a real pain. Knowing if something is at least planned would help to make a decision here.
to...@gmail.com
So I ended up doing a copy as previous version strangely no more support predictive back on last Android 15 beta 3, and the new version seems to have magically fixed the text selection popup menu.
Some other notes if there's any interest:
- On Android 9 / 10 there's no automatic navigation bar protection, the BottomSheet should provide it for consistency. (I don't support before Android 9 so maybe this apply to before versions too)
- Apps can override dark theme in their settings and theme, it's hard-coded and may cause issue. (Since the scrim color is passed as an argument, it can be derived from that color for a minimal consistency and avoid dark icons on dark scrim for example. To test pass a white scrim when phone is in dark mode and status bar icons are now invisible.)
- Apps can be immersive or hide the status bar and a few other options, new version enforce most things leading to bad UI/UX due to switching between modes. (Simple way would be to pass the window as argument to contentWindowInsets for clients to tweak or have another callback)
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jose Figueroa <
Link:
[Material3][ModalBottomSheet] Update inset handling to move modalbottomsheet content out of status bars
Expand for full commit details
[Material3][ModalBottomSheet] Update inset handling to move modalbottomsheet content out of status bars
This makes content more visible and interactable, per material spec
RelNote: "ModalBottomSheet content now moves content away from status bar."
Bug: 336553431
Bug: 321877275
Bug: 336962418
Bug: 342093067
Test: Manual testing
Change-Id: I5114c66808d155f5db97908520bad2efd93be08e
Files:
- M
compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ModalBottomSheet.kt
Hash: 8e198d739211999723660d6394ba6274730f564a
Date: Tue Oct 01 11:59:21 2024
be...@gmail.com
"Reason for revert: Causes a potential regression with content visibility" ??
Since 1.3, ended up creating my own shape with a top offset + top content offset.
How on earth could anyone think it's a good idea to have the bottom sheet going under the status bar ?!
Anything behind it becomes unaccessible, and adding a top offset makes the design super ugly (one could think of a solution where depending on the screen height and content height, the offset is applied, but man things are supposed to be simple and straightforward...)
Description
Jetpack Compose version: Last snapshot 11763555 (So containshttps://github.com/androidx/androidx/commit/33c32f65dd7879954cfa7a46a76eb959c977e291 )
Material Library Version (M2, M3 or Both?): M3
Material Compose component used: ModalBottomSheet
Applying content padding does not work for modalbottomsheets and status bar.
Try to build a proper modalbottomsheet that properly take in account the status bar when the sheet is longer than the screen.
This is currently not possible without setting contentColor to transparent and manually apply the shape to the header we use, completely breaking the purpose of the API that expose the color and the shape and should work.