Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ma...@gmail.com <ma...@gmail.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 44991c9a6f7d832decb7a19b9d795f8644bc8503
Author: jbwoods <jbwoods@google.com>
Date: Fri Mar 15 10:58:23 2019
Add NavDirections overload for createOnClickListener in Navigation
Gives developers the convenient option of just passing navDirections to
createOnClickListener instead of manually exactings the ActionID and
Bundle.
Test: ./gradlew checkApi
BUG: 127631752
Change-Id: Icfc3762570ccf5efac83afc0375cbdb8c0acee11
M navigation/runtime/api/2.1.0-alpha01.txt
M navigation/runtime/api/current.txt
M navigation/runtime/src/main/java/androidx/navigation/Navigation.java
https://android-review.googlesource.com/930453
https://goto.google.com/android-sha1/44991c9a6f7d832decb7a19b9d795f8644bc8503
Branch: androidx-master-dev
commit 44991c9a6f7d832decb7a19b9d795f8644bc8503
Author: jbwoods <jbwoods@google.com>
Date: Fri Mar 15 10:58:23 2019
Add NavDirections overload for createOnClickListener in Navigation
Gives developers the convenient option of just passing navDirections to
createOnClickListener instead of manually exactings the ActionID and
Bundle.
Test: ./gradlew checkApi
BUG: 127631752
Change-Id: Icfc3762570ccf5efac83afc0375cbdb8c0acee11
M navigation/runtime/api/2.1.0-alpha01.txt
M navigation/runtime/api/current.txt
M navigation/runtime/src/main/java/androidx/navigation/Navigation.java
ch...@moqi.co.uk <ch...@moqi.co.uk> #3
This has been added internally and will be available in Navigation 2.1.0-alpha01
il...@google.com <il...@google.com> #4
The original issue was fixed as a result of https://android-review.googlesource.com/833717 and a number of other internal changes and that will be available in alpha08.
Discovered another issue when doing this specific set of navigation actions, so leaving this open until that part is also fixed.
Discovered another issue when doing this specific set of navigation actions, so leaving this open until that part is also fixed.
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d3507cb9dab82264070c72a37dbde1dfb43ef578
Author: Ian Lake <ilake@google.com>
Date: Tue Dec 04 14:24:32 2018
Split pop and dispatch logic
When using popUpTo, navigate() would
internally call popBackStack(), resulting
in additional dispatch calls to
OnDestinationChangedListener before the
navigate() operation itself was done.
By separating the logic, we can ensure that
we don't prematurely remove NavGraph destinations
that should still exist after the navigate()
operation and that developers only see a
single final OnDestinationChangedListener callback.
Test: new test
BUG: 113611083
Change-Id: Ib63e4156521259a945ffecf679ccb404ac192017
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/runtime/src/androidTest/res/navigation/nav_nested_start_destination.xml
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/840996
https://goto.google.com/android-sha1/d3507cb9dab82264070c72a37dbde1dfb43ef578
Branch: androidx-master-dev
commit d3507cb9dab82264070c72a37dbde1dfb43ef578
Author: Ian Lake <ilake@google.com>
Date: Tue Dec 04 14:24:32 2018
Split pop and dispatch logic
When using popUpTo, navigate() would
internally call popBackStack(), resulting
in additional dispatch calls to
OnDestinationChangedListener before the
navigate() operation itself was done.
By separating the logic, we can ensure that
we don't prematurely remove NavGraph destinations
that should still exist after the navigate()
operation and that developers only see a
single final OnDestinationChangedListener callback.
Test: new test
BUG: 113611083
Change-Id: Ib63e4156521259a945ffecf679ccb404ac192017
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/runtime/src/androidTest/res/navigation/nav_nested_start_destination.xml
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
Description
android.arch.navigation:navigation-fragment-ktx
android.arch.navigation:navigation-ui-ktx
Version used:
1.0.0-alpha05
Devices/Android versions reproduced on:
-SM-A510F, Android 7.0
-Emulator x86_64 API 28
Sample project:
Description:
Having this structure:
nav_graph.xml
<navigation
android:id="@+id/nav_graph"
app:startDestination="@id/startFragment">
<fragment
android:id="@+id/startFragment"
android:name="com.example.navbug.StartFragment"
android:label="StartFragment"
tools:layout="@layout/fragment_start">
<action
android:id="@+id/action_startFragment_to_nested_nav_graph"
app:destination="@id/nested_nav_graph" />
</fragment>
<include app:graph="@navigation/nested_nav_graph" />
</navigation>
nested_nav_graph.xml
<navigation
android:id="@+id/nested_nav_graph"
app:startDestination="@id/nestedStartFragment">
<fragment
android:id="@+id/nestedStartFragment"
android:name="com.example.navbug.NestedStartFragment"
android:label="NestedStartFragment">
<action
android:id="@+id/action_nestedStartFragment_to_nestedSecondFragment"
app:destination="@id/nestedSecondFragment"
app:popUpTo="@+id/nestedStartFragment"
app:popUpToInclusive="true" />
</fragment>
<fragment
android:id="@+id/nestedSecondFragment"
android:name="com.example.navbug.NestedSecondFragment"
android:label="NestedSecondFragment" />
</navigation>
I want to achieve this navigation pattern:
StartFragment => NestedStartFragment => NestedSecondFragment =(back)=> StartFragment
I'm trying to implement this by setting the action NestedStartFragment=>NestedSecondFragment with the options [popUpTo=NestedStartFragment, popUpToInclusive=true], so that the resulting stack would be:
0. NestedSecondFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When navigating from NestedStartFragment to NestedSecondFragment, the following execption occurs:
java.lang.IllegalArgumentException: Navigator androidx.navigation.fragment.FragmentNavigator@ccc9092 reported navigation to unknown destination id com.example.navbug:id/nestedSecondFragment
at androidx.navigation.NavController$2.onNavigatorNavigated(NavController.java:142)
at androidx.navigation.Navigator.dispatchOnNavigatorNavigated(Navigator.java:217)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:207)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.java:45)
at androidx.navigation.NavDestination.navigate(NavDestination.java:407)
at androidx.navigation.NavController.navigate(NavController.java:683)
at androidx.navigation.NavController.navigate(NavController.java:630)
at androidx.navigation.NavController.navigate(NavController.java:618)
at com.example.navbug.NestedStartFragment$onViewCreated$1.onClick(Fragments.kt:31)
at android.view.View.performClick(View.java:6597)
at android.view.View.performClickInternal(View.java:6574)
at android.view.View.access$3100(View.java:778)
at android.view.View$PerformClick.run(View.java:25885)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Right before the navigation, the stack is:
0. NestedStartFragment
1. NestedNavGraph
2. StartFragment
3. NavGraph
When NestedStartFragment is popped on my request, NestedNavGraph is also popped because
"// We never want to leave NavGraphs on the top of the stack" (from NavController.onNavigatorNavigated)
with the effect that eventually the requested destination NestedSecondFragment is pruned from the graph and cannot be reached anymore.
Unless I'm doing something wrong, it seems that NavGraph automatic popping should be avoided if the final destination actually belongs to it.