Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
I attach a project to reproduce the issue.
There are 2 buttons: one add a named fragment transaction (which you can remove with back) and the other navigate to another fragment using nav graph.
There are 2 buttons: one add a named fragment transaction (which you can remove with back) and the other navigate to another fragment using nav graph.
ap...@google.com
You should be using childFragmentManager, not requireFragmentManager(). As of Alpha 04 and https://issuetracker.google.com/issues/111345778 , back button presses are automatically passed to the child FragmentManager of the active Fragment, allowing you to do whatever FragmentTransactions you want in that child FragmentManager (using Navigation or not).
We can improve the error message though.
We can improve the error message though.
ga...@gmail.com
Ah, of course I should....
shame on me.
Improving the error message will surely help fools like me :) thanks
shame on me.
Improving the error message will surely help fools like me :) thanks
fo...@google.com
We've added a better error message in https://android-review.googlesource.com/861401 and this will be available in 1.0.0-alpha10.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 64a958a72265aa72aae6dea6e78d531d0d5be096
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:20:11 2021
Fix deep link ids from a navGraph's id to one of its siblings.
For a nested NavGraph N with startDest=A, and another dest B in N:
addDestination(N)
addDestination(B)
Would previously result in:
[N, N, B]
This change fixes the result to:
[N, B]
(which implies [A, B], since A is the startDest)
Because B's buildDeepLinkIds(prevDestination = N) would generate both [N, B], even though N was already navigated to (literally set as the previousDestination).
Test: New unit tests included. All existing tests pass.
BUG: 147913689
Change-Id: I42da530ebb72be1a90164416b7ca7f95e7834bba
M navigation/navigation-common/src/main/java/androidx/navigation/NavDestination.kt
M navigation/navigation-common/src/test/java/androidx/navigation/NavDestinationTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavDeepLinkBuilderTest.kt
A navigation/navigation-runtime/src/androidTest/res/navigation/nav_non_start_nest.xml
https://android-review.googlesource.com/1773621
Branch: androidx-main
commit 64a958a72265aa72aae6dea6e78d531d0d5be096
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:20:11 2021
Fix deep link ids from a navGraph's id to one of its siblings.
For a nested NavGraph N with startDest=A, and another dest B in N:
addDestination(N)
addDestination(B)
Would previously result in:
[N, N, B]
This change fixes the result to:
[N, B]
(which implies [A, B], since A is the startDest)
Because B's buildDeepLinkIds(prevDestination = N) would generate both [N, B], even though N was already navigated to (literally set as the previousDestination).
Test: New unit tests included. All existing tests pass.
BUG: 147913689
Change-Id: I42da530ebb72be1a90164416b7ca7f95e7834bba
M navigation/navigation-common/src/main/java/androidx/navigation/NavDestination.kt
M navigation/navigation-common/src/test/java/androidx/navigation/NavDestinationTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavDeepLinkBuilderTest.kt
A navigation/navigation-runtime/src/androidTest/res/navigation/nav_non_start_nest.xml
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 793e098ad770115fda31a1ae1264a62bf85ca3ec
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:24:24 2021
Use explicit task stack in navigateUp() when on another app's stack.
This change uses the synthetic task stack created by the NavDeepLinkBuilder#addDestination() API when deep-linked on top of another app's task stack when the user navigates up, rather than generating a stack based on navGraph parenting rules.
Test: New unit tests included. All existing tests pass.
Change-Id: I58f4694022fec38f8c06f5901b3001a1a700a529
BUG: 147913689
M navigation/navigation-runtime/build.gradle
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavDeepLinkBuilder.kt
https://android-review.googlesource.com/1714510
Branch: androidx-main
commit 793e098ad770115fda31a1ae1264a62bf85ca3ec
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:24:24 2021
Use explicit task stack in navigateUp() when on another app's stack.
This change uses the synthetic task stack created by the NavDeepLinkBuilder#addDestination() API when deep-linked on top of another app's task stack when the user navigates up, rather than generating a stack based on navGraph parenting rules.
Test: New unit tests included. All existing tests pass.
Change-Id: I58f4694022fec38f8c06f5901b3001a1a700a529
BUG: 147913689
M navigation/navigation-runtime/build.gradle
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavDeepLinkBuilder.kt
Description
When defining an explicit deep-link using NavDeepLinkBuilder, only a single Argument bundle can be provided for every Fragment destination inferred from XML. This can cause conflicts between arguments of the same name shared by different Destinations, and no argument verification is performed, so it's possible for parent Fragments to crash at navigateUp() time.
Request: A NavDeepLinkBuilder api that allows composition of explicit [destId, args] pairs to construct a destination stack. Preferably, accepting NavDirections as the parameter, so existing SafeArgs generated wrappers can be reused for argument safety.