Status Update
No update yet.
Comments
ra...@gmail.com
This happens when fragments use animation whereby it doesn't wait for animations to complete and moves directly to RESUMED state.
The entry's listener to Fragment state does not get attached because it was attaching only if Fragment was in CREATED / STARTED state.
jb...@google.com
cl...@google.com
Branch: androidx-main
commit 16afaea63fc18ca7cc298e6650e0463083ba8ad7
Author: Clara Fok <clarafok@google.com>
Date: Mon Feb 27 17:27:15 2023
Fix FragmentNavigator resume states
Entries previously were not attaching fragment lifecycle observers because it would do so only if Fragment was STARTED or CREATED. But when using animations, Fragments would jump straight to RESUME and no observers would be attached.
Observers are now attached as long as Fragment is atleast STARTED. Since initial entry is not added to backStack, we store its entry to later attach an observer when its fragment is attached.
This CL also lays the foundation for attaching observers upon configuration changes / recreates.
Test: ./gradlew navigation:navigation-fragment:cC
Bug: 269646882
Relnote: "Fixes regression in navigation 2.6.0-alpha06 where NavBackStackEntry is not moved to RESUMED state"
Change-Id: Ib35896636c187da5bd11ea06234a3ea815fdeb68
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
A navigation/navigation-fragment/src/androidTest/res/anim/fade_enter.xml
A navigation/navigation-fragment/src/androidTest/res/anim/fade_exit.xml
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
ap...@google.com
This has been fixed internally and will be available in navigation 2.6.0-alpha07
cl...@google.com
Branch: androidx-main
commit c73552953192ba60a879f5e51218f6e157a24beb
Author: Clara Fok <clarafok@google.com>
Date: Tue Feb 28 14:47:30 2023
Add FragmentNavigator test
Ensure initial fragments and their entries are correctly replaced and destroyed when navigate and popping consecutively
Test: ./gradlew navigation:navigation-fragment:cC
Bug: 269646882
Change-Id: I552ddd3d74f20612c4c91336eb4af9e6aa99c146
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/navigation-fragment/src/androidTest/res/navigation/nav_simple.xml
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-fragment:2.6.0-alpha07
ra...@gmail.com
NavBackStackEntry is still not triggering RESUMED on androidx.navigation:navigation-fragment:2.6.0-alpha09 in certain cases, where after a locale or uiMode change with
AppCompatDelegate.setApplicationLocales
AppCompatDelegate.setDefaultNightMode
Issue can be reproduced with attaching LifecycleObserver to the currentBackStackEntry of a Home fragment like so:
findNavController().currentBackStackEntry?.lifecycle?.let {
if (it.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "resumed")
} else {
val testLifecycleObserver = object : DefaultLifecycleObserver {
override fun onResume(owner: LifecycleOwner) {
Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "onResumed")
it.removeObserver(this)
}
}
it.addObserver(testLifecycleObserver)
}
}
After performing a config change as mentioned above on a Settings fragment, upon performing a popBackStack/navigateUp to Home fragment, the DefaultLifecycleObserver's onResume will not be triggered. Issue does not occur if a config change is not performed.
Description
Component used: Navigation
Version used: 2.6.0-alpha05
Devices/Android versions reproduced on:
Not relevant, it will happen on all.
If this is a bug in the library, we would appreciate it if you could attach: Sample project to trigger the issue.
I'll add a couple of simple kotlin files instead, just use them with any version after 2.6.0-alpha05 navigation dependency and you'll be able to reproduce it.
MainActivity_rook.kt File
If we add destinations directly on "root" (route passed to NavHost call), then this will be the log of the back stack as we navigate:
MainActivity_no_root.kt File
If we add a navigation graph ("home_graph") as the only direct child of "root" and add destinations on that instead, it will work as expected, we'll see this:
This was a breaking change that could introduce bugs for anyone relying on that "root" sent on the NavHost and popping up to that, since after updating navigation it would instead just pop their last screen.