Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 83a3a2a451c1cd2a7cb7c7e9138fa5731ff7907e
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 06 09:39:23 2020
Ensure we disptachOnDestinationChanged when graph restored
When the nav graph is restored, since we already have the proper
backstack, we never make a call to navigate(). That means that we do not
disptach to any OnDestinationChanged listeners that may have been
registered on the restored nav graph.
If a graph is created and the backstack is already rebuilt, lets
dispatch to any OnDestinationChangedListeners that are added.
Test: NavControllerTest
Bug: 155218371
Change-Id: Ie50e57cc5fbacbde17af2e5eaca7cc1fdeecacba
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/1303858
Branch: androidx-master-dev
commit 83a3a2a451c1cd2a7cb7c7e9138fa5731ff7907e
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 06 09:39:23 2020
Ensure we disptachOnDestinationChanged when graph restored
When the nav graph is restored, since we already have the proper
backstack, we never make a call to navigate(). That means that we do not
disptach to any OnDestinationChanged listeners that may have been
registered on the restored nav graph.
If a graph is created and the backstack is already rebuilt, lets
dispatch to any OnDestinationChangedListeners that are added.
Test: NavControllerTest
Bug: 155218371
Change-Id: Ie50e57cc5fbacbde17af2e5eaca7cc1fdeecacba
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
jb...@google.com <jb...@google.com> #3
This has been fixed internally and will be available in the Navigation 2.3.0-beta01 release.
an...@google.com <an...@google.com> #4
il...@google.com <il...@google.com> #5
We've decided to release a Navigation 2.2.3 bug fix release and will be including this change in that release.
Description
Component used: Navigation Version used:2.3.0-alpha05
Devices/Android versions reproduced on: Emulator, Android 11 DP3
I'm trying out returning results from dialogFragments with the SavedStateHandle you provide in this latest versions. it works well, taking into account the "Additional Considerations" section advice, of observing the NavBackStackEntry lifecycle, so the weird stuff that happens of having the fragment and the dialog being resumed at the same time doesn't affect when we receive the result.
But, process death is problematic, first I encountered https://issuetracker.google.com/154405007
It's easy to fix once you know what's happening. But now the problem I'm seeing is that the lifecycle events do not work in the same way when process death has occurred and backstack state is restored.
Normally, what I see is this, on the currentBackStackEntry: onCreate -> onStart -> onResume -> (we open the dialog) -> onPause ... and then onResume again when we come back from the dialog. Everything is cool here.
But after process death, this happens: onCreate -> onStart -> onResume We never hit onPause, and so we never "come back" to onResume after dismissing the dialog. We will never receiver the ON_RESUME event again to get the result.
I'm not sure if this is a bug, or just a consequence of how the state restoration is done on the backstack, but it pretty much means that thishttps://developer.android.com/guide/navigation/navigation-programmatic#additional_considerations , won't always work.
I attach a minimal repo to reproduce this, just click on the dialog button, and on receiving a result on the first fragment a toast will appear. Now, if you go to dialog once again, leave the app, and trigger process death and return to the app, it won't work.https://github.com/MrMPN/NavEntryLifecycleMinRepo
It's not a common case I think, but given the info on the documentation, it was unexpected to see it fail like this.