Status Update
Comments
il...@google.com <il...@google.com>
mg...@google.com <mg...@google.com>
ap...@google.com <ap...@google.com> #2
Branch: androidx-main
commit dce95f0a931da95ad38e24c94d3496241e0c1954
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Wed Jan 26 19:38:35 2022
Support content types in Lazy grids
Relnote: You can now specify the content type for the items of LazyVerticalGrid - item/items functions on LazyGridScope now accept such parameter. Providing such information helps item composition reusing logic to make it more efficiently and only reuse the content between the items of similar type.
Fixes: 215372836
Test: LazyGridSlotsReuseTest
Change-Id: I7b3550cf626b6ef6f65029b1e55465266bfacb18
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyGrid.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/grid/LazyGridItemsProviderImpl.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/grid/LazyGridScopeImpl.kt
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/grid/LazyGridSlotsReuseTest.kt
il...@google.com <il...@google.com>
pr...@google.com <pr...@google.com> #3
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.8.0-alpha02
he...@reaktor.com <he...@reaktor.com> #4
Thanks for adding dropUnlessResumed()
, it's perfect for preventing accidental navController.popBackStack()
invocations. What it fails to handle though, is when the wrapped callback takes an argument. I believe this is a common practice as it's recommended not to pass the NavController
to the composables, but offer callbacks that perform the actual navigation.
It's also bit unfortunate that the function is @Composable
as it makes it impossible to call it from these callbacks. But it does make it more ergonomic to call, especially since you need to be very careful to use the correct LifecycleOwner
.
Am I misinterpreting the use of this API by using it close to the navigation component? Or should I wrap the user interactions instead, such as Button.onClick
, where the callbacks share the () -> Unit
signature?
il...@google.com <il...@google.com> #5
Re
Am I misinterpreting the use of this API by using it close to the navigation component? Or should I wrap the user interactions instead, such as Button.onClick, where the callbacks share the () -> Unit signature?
You should be wrapping the user interaction side, yes.
ha...@gmail.com <ha...@gmail.com> #6
I am curious - is there a difference to checking currentBackStackEntry.lifecycle.currentState
instead? This way we don't need to be in a composable context, which seems like a more flexible solution.
Description
When using Compose navigation, calls to navigate should be guarded by lifecycle state to prevent invoking navigation methods while composable is transitioning as an effect of navigation. Given navigation destination:
navigation calls should be guarded by
backStackEntry
lifecycle state to prevent invoking navigation from composable that's under transition:It would be really useful to have a set of lifecycle aware function wrappers for guarding execution of calls, for example:
or standalone composable version which will use
LocalLifecycleOwner
to access lifecycle state: