Status Update
Comments
il...@google.com <il...@google.com> #2
This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
Description
Component used: Fragment
Version used: 1.2.4, 1.3.0-beta01
Devices/Android versions reproduced on: Pixel 4XL
Hello, my app currently uses Fragment 1.2.4, which we have been using to replace "top-level" Fragments in the app within a single Activity. When we do a
replace
FragmentTransaction fromFirstFragment
toSecondFragment
, this is the order of events we observe:The behavior we have implicitly been depending on is that the previous fragment has been paused, before the next Fragment has been resumed.
However when trying out the AndroidX Navigation library, which always sets
setReorderingAllowed(true)
, we observe a different ordering. Even though we are just executing a single standardreplace
operation.In this case, both
FirstFragment
andSecondFragment
are briefly in the resumed state at the same time, which was an unexpected change for us. I have been testing the 1.3.0-beta01 release, and noticed that this behavior changes yet again, depending on if the new fragment store manager is enabled. Here are my findings:1.2.4, allow-reordering = false
1.2.4, allow-reordering = true (UNEXPECTED)
1.3.0-beta01: enableNewStateManager = false, allow-reordering = false
1.3.0-beta01: enableNewStateManager = false, allow-reordering = true (UNEXPECTED)
1.3.0-beta01: enableNewStateManager = true, allow-reordering = false
1.3.0-beta01: enableNewStateManager = true, allow-reordering = true
Note: All of these were determined by adding a
log
in the overridden method, just before the super call in both Fragments.My questions are:
What is the intentional order of lifecycle events for a standard replace transaction, and should we expect it to be different when the
setReorderingAllowed
flag is enabled?Can we reliably depend on the order of these lifecycle events going forward, or is this seen as an implementation detail that application code should never depend on.