Fixed
Status Update
Comments
ta...@gmail.com <ta...@gmail.com> #2
BTW, the source code for this is fairly straightforward. I just added the source into the sample for now, but it would be nicer if we had the function.
From source:
/**
* Gets the current navigation back stack entry as a [MutableState]. When the given navController
* changes the back stack due to a [NavController.navigate] or [NavController.popBackStack] this
* will trigger a recompose and return the top entry on the back stack.
*
* @return a mutable state of the current back stack entry
*/
@Composable
public fun NavController.currentBackStackEntryAsState(): State<NavBackStackEntry?> {
return currentBackStackEntryFlow.collectAsState(null)
}
il...@google.com <il...@google.com>
to...@gmail.com <to...@gmail.com> #3
il...@google.com <il...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
commit 804463f3f416212296133fe53e30b5d5cbc2fba9
Author: stevebower <stevebower@google.com>
Date: Wed Jan 05 15:04:02 2022
Add currentBackStackEntryAsState to Wear Compose Navigation.
Test: Run tests for wear.compose.navigation.
Bug: 212739653
Relnote: "We have added NavController.currentBackStackEntryAsState()
to the Wear.Compose.Navigation library."
Change-Id: If90286c7debe623df926a091f15766abf04f2ecc
M wear/compose/compose-navigation/api/restricted_current.txt
M wear/compose/compose-navigation/api/current.txt
M wear/compose/compose-navigation/src/androidTest/kotlin/androidx/wear/compose/navigation/SwipeDismissableNavHostTest.kt
M wear/compose/compose-navigation/api/public_plus_experimental_current.txt
M wear/compose/compose-navigation/src/main/java/androidx/wear/compose/navigation/SwipeDismissableNavHostController.kt
https://android-review.googlesource.com/1926189
Branch: androidx-main
commit 804463f3f416212296133fe53e30b5d5cbc2fba9
Author: stevebower <stevebower@google.com>
Date: Wed Jan 05 15:04:02 2022
Add currentBackStackEntryAsState to Wear Compose Navigation.
Test: Run tests for wear.compose.navigation.
Bug: 212739653
Relnote: "We have added NavController.currentBackStackEntryAsState()
to the Wear.Compose.Navigation library."
Change-Id: If90286c7debe623df926a091f15766abf04f2ecc
M wear/compose/compose-navigation/api/restricted_current.txt
M wear/compose/compose-navigation/api/current.txt
M wear/compose/compose-navigation/src/androidTest/kotlin/androidx/wear/compose/navigation/SwipeDismissableNavHostTest.kt
M wear/compose/compose-navigation/api/public_plus_experimental_current.txt
M wear/compose/compose-navigation/src/main/java/androidx/wear/compose/navigation/SwipeDismissableNavHostController.kt
ta...@gmail.com <ta...@gmail.com> #5
Hi Steve, which version of the library will this be released in?
il...@google.com <il...@google.com> #6
Never mind, it's in alpha15, missed that. Thanks!
il...@google.com <il...@google.com> #7
This has been fixed and will be available in future Support Library releases. When a Loader is replaced with restartLoader(), the existing Loader won't be reset() until the replacement Loader returns data - this ensures that resources remain valid. When using restartLoader(), the previous LoaderCallbacks won't get a callback to onLoaderReset() - this ensures that your UI (such as a CursorAdapter) is not cleared.
vo...@gmail.com <vo...@gmail.com> #8
Any ET on hotfix release date for 27.1x?
kk...@google.com <kk...@google.com> #9
This bug has been fixed in Support Library 27.1.1.
ku...@gmail.com <ku...@gmail.com> #10
Racave varjan
ku...@gmail.com <ku...@gmail.com> #11
Racave varjan
ku...@gmail.com <ku...@gmail.com> #12
Racave varjan
gs...@gmail.com <gs...@gmail.com> #13
Mise a jour
Description
Callback order is changed when calling restartLoader.
The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."
But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).
This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.