Status Update
No update yet.
Comments
il...@google.com
Is this specific to navigation? Or can this be reproduced with another other Composable component?
t....@gmail.com
It only happens inside of a NavHost. So, yes, it seems to be specific to navigation.
il...@google.com
This was caused by the fix to BackHandler lifecycle aware. The problem here is that the NavController registers its lifecycle and added an observer to the Activity Lifecycle in composition while the BackHandler registers its observer on the Activity Lifecycle in a DisposbleEffect. This means that the NavController will always get Lifecycle callbacks before the BackHandler, so the components listening the the NavController's lifecycle (like the NavBackStackEntry) will always get their Lifecycle callbacks before the BackHandler as well.
This should be addressed by work coming in 2.7 to integrate the BackHandler into the NavHost.
t....@gmail.com
Branch: androidx-main
commit d2c5efe67531a30fb9f1a129d52beb1e9ece0b29
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 31 23:09:54 2023
Integrate BackHandler into NavHost
Instead of NavHost taking over the onBackPressedDispatcher from the
Activity, we should just make it use a BackHandler. This will ensure
that it interacters with the other BackHandlers in Compose correctly.
RelNote: "`NavHost` now correctly intercepts system back calls even
after the Activity has been `STOPPED` and `RESUMED`."
Test: modified tests
Bug: 279118447
Change-Id: Icb6deab996d122487243f0d3d775af8c15fc7c25
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
il...@google.com
This has been fixed internally and will be available in Navigation 2.7.0-beta01.
t....@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.7.0-beta01
si...@gmail.com
il...@google.com
I wouldn't say this is fixed. If you add a back-callback in the activity which is lifecycle aware, and then background->foreground the app, the activity back-callback will be put on top of the callback pile. This leads to that any BackHandler in your composable will NOT be triggered.
The best workaround I have for now is to use the non-lifecycle aware function in the activity.
class MainActivity : FragmentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// open fragment which hoists the composables
...
if (savedInstanceState == null) {
onBackPressedDispatcher.addCallback(onBackPressedCallback = someBackHandling())
// onBackPressedDispatcher.addCallback(owner = this, onBackPressedCallback = someBackHandling) // not this one
}
}
t....@gmail.com
sm...@gmail.com
il...@google.com
Bug Fixes : NavHost in Navigation Compose now correctly intercepts system back calls even after the Activity has been STOPPED and RESUMED.
It works fine for me.
Description
Version used:
androidx.navigation:navigation-fragment-ktx:2.2.0-rc01
androidx.navigation:navigation-ui-ktx:2.2.0-rc01
Devices/Android versions reproduced on:
Pixel 3
Android 10
When switching tabs (using BottomNavigation / setupWithNavController()), when the destination Fragment contains a call to postponeEnterTransition() in onCreate() or onCreateView(), the onCreateView() lifecycle method gets called twice. This behavior is visible to the user, via a sort of 'flicker' (depending on the layout), as the fragment's view is recreated.
I suspect this may be due to some code in
`FragmentManager.addAddedFragments(@NonNull ArraySet<Fragment> added)`
It appears the destination Fragment (which invoked postponeEnterTransition()) has moveToState() called on it twice (vie addAddedFragments()). My guess, is that the destination fragment hasn't completed its first moveToState() before the second moveToState() is called, so the secondMoveToState() is attempting to move from a stale state.
I'm not able to provide a sample project for you at this stage.