Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
Branch: androidx-master-dev
commit 87f4c988b713e43deef88a0df6a31c507f11b4a8
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 27 11:20:32 2020
Use setMaxLifecycle for FragmentScenario moveToState
Current FragmentScenario uses ActivityScenario to for the moveToState
method. That means moving to STARTED does not work prior to API 23. This
also means that tests including DialogFragment cannot be moved to
CREATED, only ACTIVITY_CREATED.
This change uses setMaxLifecycle instead, so that FragmentScenario is
decoupled from ActivityScenario and there are no longer any restrictions
on moving to API 23 and DialogFragment's can be properly moved to
CREATED.
Test: ran tests on API 21 device and they passed
Bug: 156527405
Change-Id: I63d5facfcce9875acf06e39029686cb535cc3ea6
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioDialogFragmentTest.kt
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioTest.kt
M fragment/fragment-testing/src/main/java/androidx/fragment/app/testing/FragmentScenario.java
ap...@google.com
This has been fixed internally and will be available in Fragment 1.3.0-alpha07.
ga...@gmail.com
Would it be possible to add a NavDirections overload to NavDeepLinkBuilder for this? It has both the id and the args so it's a nice way to add destination. I can also create an extra ticket.
fo...@google.com
Currently deep links always start with the nav_graph's startDestination. This is a problem for apps which use multiple root-level destinations in a bottom-navigation view, and unexpected for explicitly created synthetic task stacks using only addDestination().
I'm using an invocation like: navDeeplinkBuilder.addDestinaton(frag_two).addDestination(frag_three), where start_destination = frag_one. Using an initial setDestination doesn't seem to change anything. frag_one is always at the bottom of the back stack, with two and three above.
After building the deep link, I can see the first R.id is always 0 (or the android:id of the nav_graph, if you remembered to set one), as a result of NavDeepLinkBuilder's
When navController receives the deep link, it will attempt to navigate to 0 (the navGraph itself), which NavGraphNavigator always substitutes with the startDestination.
Separately, the navGraph will be explicitly added above it as the parent of that startDestination using the mGraph id set on the end Fragment.
So it seems like both NavDeepLinkBuilder and NavController are attempting to set the mGraph to the bottom of the task stack. I think the initial navGraph should just be implicit in the NavDeepLinkBuilder-created Intent, since there's already a stated dependency on the navGraph being the same at Intent-build-time and when the deep link is executed.
ap...@google.com
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
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.