Fixed
Status Update
No update yet.
Comments
ja...@gmail.com
One more detail here.
The body of navigateUp() method of NavController class (1.0.0-rc01) looks like this:
if (mBackStack.size() == 1) {
// If there's only one entry, then we've deep linked into a specific destination
// on another task so we need to find the parent and start our task from there
...
} else {
return popBackStack();
}
If I put a breakpoint on the very first line of that code and invoke this method anyhow, I can see that the size of mBackStack is actually 2 (with both root and child fragments).
So, the code doesn't consider the current case a deeplink case, but as a regular opening of the child destination.
The body of navigateUp() method of NavController class (1.0.0-rc01) looks like this:
if (mBackStack.size() == 1) {
// If there's only one entry, then we've deep linked into a specific destination
// on another task so we need to find the parent and start our task from there
...
} else {
return popBackStack();
}
If I put a breakpoint on the very first line of that code and invoke this method anyhow, I can see that the size of mBackStack is actually 2 (with both root and child fragments).
So, the code doesn't consider the current case a deeplink case, but as a regular opening of the child destination.
ja...@gmail.com
Partially agree, but my case doesn't use nested graphs at all, so my issue is just simpler.
However, the actual problem seems to be the same: the library treats absence of Intent.FLAG_ACTIVITY_NEW_TASK as it is actually set, because all 'start destinations' are still added before the actual deeplink destination (as it is explained in the documentation where the flag is set).
However, the actual problem seems to be the same: the library treats absence of Intent.FLAG_ACTIVITY_NEW_TASK as it is actually set, because all 'start destinations' are still added before the actual deeplink destination (as it is explained in the documentation where the flag is set).
il...@google.com
il...@google.com
This is a regression caused by https://android-review.googlesource.com/833717 where the NavGraph destinations would always be added to the back stack (it isn't both the root and child fragments, but the root graph and the child fragment) to avoid IllegalArgumentExceptions. Unfortunately, that broke the navigateUp() behavior, which is something we'll fix :)
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/912258
https://goto.google.com/android-sha1/781d0178da33d84f615b409b17975c8ba290401c
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
il...@google.com
A fix will be available in Navigation 1.0.0-rc02. Thanks for reporting it and the great sample app!
ja...@gmail.com
Thanks, Ian.
Description
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: 7.0, 9.0 (Emulators)
According to
if a destination is opened with IMPLICIT deeplink and WITHOUT Intent.FLAG_ACTIVITY_NEW_TASK flag, then the destination is opened in the same task. After that if user clicks UP, then the actual parent should be recreated in a separate task, but it doesn't work. The UP button in this case does nothing, as well as manual navigateUp() method call.
I tried to modify the code to check both Toolbar and ActionBar approaches and also tried to create the NavHostFragment via xml and code. In all this cases, the behavior of UP button remained the same.
I attached a simple project that shows this situation. It contains 2 modules:
- app - an app with 2 fragments (root and child). The child fragment's destination supports a deeplink.
- deeplinkstarter - one button app, that starts an implicit deeplink to the child fragment of the 'app'.
I consider this as major defect because the library doesn't behave as it is explicitly said in the documentation.
Please, improve.