Navigation component not accepting arguments in Dialogs that doesn't inherit from DialogFragment directly [168584987]

Fixed

Bug

Status Update

No update yet.

Description

ca...@gmail.com

created issue #1

Sep 15, 2020 05:57PM

Component used:
- androidx.navigation:navigation-fragment-ktx:2.2.1
- androidx.navigation:navigation-ui-ktx:2.2.1
Version used:
Devices/Android versions reproduced on: Cannot compile

STEPS:

Create a DialogFragment class called MyDialog
Now create another class called MyNewDialog that inherits from MyDialog instead of DialogFragment(for example, to inherit styles or UI)

Now in a XML graph, try to add it and put it some arguments:

<dialog
    android:id="@+id/my_new_dialog"
    android:name="com.example.app.dialogs.MyNewDialog"
    tools:layout="@layout/my_dialog">

    <argument
        android:name="argument_1"
        app:argType="string"/>

    <action
        android:id="@+id/action_1"
        app:destination="@id/destination_1" />

</dialog>

Then, when trying to build the application, it won't compile and the navigation generated code will throw:

This function must return a value of type MyNewDialogArgs

However, no problem with actions (Why it doesn't throw same error with type MyNewDialogDirections??)

No problem if we use MyDialog(that inherits directly from DialogFragment) instead of MyNewDialog(that inherits from MyDialogand this last, from DialogFragment

Comments

il...@google.com <il...@google.com> #2Sep 15, 2020 06:28PM

So there does seem to be a bug in Navigation that causes this to fail.

When it navigates with popUpTo and removes SecondFragment, that removal in fragment is set for a frame later and before it is actually removed the navigate call in the onViewCreated of SecondFragment enqueues another call to add it back. But we still need to destroy SecondDetailFragment which ends up marking the NavBackStackEntry associated with SecondFragment as complete before navigation has received the call from the fragment that it has been added back. So by the time it hits this check, the SecondFragment is in the correct state, but Navigation has no way of referencing it so it assumes that it is not associated with an entry.

But this is not the way this type of situation should be implemented. Instead of having the destinations as part of the NavGraph, they should:

be managed by the childFragmentManager of SecondFragment. So instead of going back to SecondFragment just to go somewhere else, each of the fragments take the entire content of SecondFragment and are swapped out.
for some sort of a/b testing, set different graphs in the Activity. The graphs would keep the same SecondFragment id, but swap out the names and then you choose the correct graph based on the condition.

ca...@gmail.com <ca...@gmail.com> #3Sep 16, 2020 01:06PM

Please example,what do you mean by that?

NavTestApp.zip

26 MB

Download

il...@google.com <il...@google.com> #4Sep 16, 2020 04:21PM

Assigned to jb...@google.com.

Have SecondFragment as part of your graph and then inside of SecondFragment call the childFragmentManager and replace with the fragment you actually want to show, whether that is SecondTypeOne or SecondTypeTwo.
Create different graphs and follow along with the docs on using different graphs dynamically and inflate and set the one needed based on logic in your Activity.

ap...@google.com <ap...@google.com> #5Sep 24, 2020 01:37AM

Thank you very much. Now the issue does not occur. When I added this code below in SecondFragment

shardViewModel.onGetTypeSecond.observe(viewLifecycleOwner) { isType1 ->
if (isType1) {
val graph = findNavController().graph
val carInstallmentNavGraph =
graph.findNode(R.id.nav_second) as NavGraph
carInstallmentNavGraph.setStartDestination(R.id.secondTypeOneFragment)
findNavController().navigate(SecondFragmentDirections.actionSecondFragmentToSecondTypeOneFragment())
} else {
val graph = findNavController().graph
val carInstallmentNavGraph =
graph.findNode(R.id.nav_second) as NavGraph
carInstallmentNavGraph.setStartDestination(R.id.secondTypeTwoFragment)
findNavController().navigate(SecondFragmentDirections.actionSecondFragmentToSecondTypeTwoFragment())
}
}

and removed app:popUpTo="@id/secondFragment" and app:popUpToInclusive="true"

<fragment
android:id="@+id/secondFragment"
android:name="com.example.navigationdeeplink.SecondFragment"
android:label="fragment_second"
tools:layout="@layout/fragment_second" >
<action
android:id="@+id/action_secondFragment_to_secondTypeOneFragment"
app:destination="@id/secondTypeOneFragment" />
<action
android:id="@+id/action_secondFragment_to_secondTypeTwoFragment"
app:destination="@id/secondTypeTwoFragment"
app:popUpTo="@id/secondFragment" />
</fragment>

jb...@google.com <jb...@google.com> #6Sep 24, 2020 08:37AM

Marked as fixed.

Is there a planned fix for this issue? We've been stuck on Navigation 2.5.3 for some time due to issues in 2.6.x and now this issue, and the suggested workaround of restructuring our navigation graph is a pretty big lift. If that's the only recommended path it would be helpful to know so we can try to plan for that work, otherwise we'd want to just wait for the fix that doesn't require restructuring.

ap...@google.com <ap...@google.com> #7Sep 24, 2020 09:34AM

This was fixed by https://issuetracker.google.com/301887045 and will be available in the Navigation 2.7.4 release. We are also adding a regression test for this particular case.

ap...@google.com <ap...@google.com> #8Sep 24, 2020 09:36AM

Project: platform/frameworks/support
Branch: androidx-main

commit b292676aa37122f0ca0215023dcdbe27168b2469
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 27 21:25:35 2023

Add a test for navigate with popUpTo nested graph

Adding a test to ensure that if the start destination of a nested graph
is popped off the back stack when a fragment is created, Navigation does
not crash and gets to the correct position.

Bug: 287133013
Test: adding a test
Change-Id: Ie1e03aeeb00b730b7688311741847b2312bdbaa0

M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/NavControllerWithFragmentTest.kt

https://android-review.googlesource.com/2765553

ap...@google.com <ap...@google.com> #9Sep 24, 2020 10:08AM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-fragment:2.8.0-alpha01

ap...@google.com <ap...@google.com> #10Sep 24, 2020 10:10AM

Project: platform/frameworks/support
Branch: snap-temp-L31300000699869852

commit 998afa5a45306f1096a053e0f9eb275481fe79ab
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 23 14:44:52 2020

Keep long arg names from wrapping

When using safe-args with a long argument name, kotlin does an
automatic line wrap at 100 characters which makes it place the argument
return and variable on different lines, which fails.

We should add `·` to emit a space that never wraps.

Test: Added KotlinNavWriterTest
Bug: 168584987
Change-Id: Ibc31f91fd6b1c4a94f0b7c05b9b9679ffa09b625
(cherry picked from commit 766a3ad47da73e1179ce6419693a825c4d665cfd)

M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/KotlinNavWriterTest.kt
A navigation/navigation-safe-args-generator/src/test/test-data/expected/kotlin_nav_writer_test/ReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongNameMainFragmentArgs.kt

https://android-review.googlesource.com/1436918

ap...@google.com <ap...@google.com> #11Sep 24, 2020 11:30AM

Project: platform/frameworks/support
Branch: snap-temp-L53700000699921463

commit 0e594474451b1e1a2f6927179c703f1547dbfe7c
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 23 14:44:52 2020

Keep long arg names from wrapping

When using safe-args with a long argument name, kotlin does an
automatic line wrap at 100 characters which makes it place the argument
return and variable on different lines, which fails.

We should add `·` to emit a space that never wraps.

Test: Added KotlinNavWriterTest
Bug: 168584987
Change-Id: Ibc31f91fd6b1c4a94f0b7c05b9b9679ffa09b625
(cherry picked from commit 766a3ad47da73e1179ce6419693a825c4d665cfd)

M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/KotlinNavWriterTest.kt
A navigation/navigation-safe-args-generator/src/test/test-data/expected/kotlin_nav_writer_test/ReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongNameMainFragmentArgs.kt

https://android-review.googlesource.com/1436921

ap...@google.com <ap...@google.com> #12Sep 24, 2020 11:32AM

Project: platform/frameworks/support
Branch: snap-temp-L25200000699921867

commit c9e5aa95317da82d339c362a3dae64a9f331e214
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 23 14:44:52 2020

Keep long arg names from wrapping

When using safe-args with a long argument name, kotlin does an
automatic line wrap at 100 characters which makes it place the argument
return and variable on different lines, which fails.

We should add `·` to emit a space that never wraps.

Test: Added KotlinNavWriterTest
Bug: 168584987
Change-Id: Ibc31f91fd6b1c4a94f0b7c05b9b9679ffa09b625
(cherry picked from commit 766a3ad47da73e1179ce6419693a825c4d665cfd)

M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/KotlinNavWriterTest.kt
A navigation/navigation-safe-args-generator/src/test/test-data/expected/kotlin_nav_writer_test/ReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongNameMainFragmentArgs.kt

https://android-review.googlesource.com/1436925

ap...@google.com <ap...@google.com> #13Sep 24, 2020 11:52AM

Project: platform/frameworks/support
Branch: snap-temp-L07700000699933785

commit f3069dc913eb8d41e6cc3859df5d6ef204fdf18c
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 23 14:44:52 2020

Keep long arg names from wrapping

When using safe-args with a long argument name, kotlin does an
automatic line wrap at 100 characters which makes it place the argument
return and variable on different lines, which fails.

We should add `·` to emit a space that never wraps.

Test: Added KotlinNavWriterTest
Bug: 168584987
Change-Id: Ibc31f91fd6b1c4a94f0b7c05b9b9679ffa09b625
(cherry picked from commit 766a3ad47da73e1179ce6419693a825c4d665cfd)

M navigation/navigation-safe-args-generator/src/main/kotlin/androidx/navigation/safe/args/generator/kotlin/KotlinNavWriter.kt
M navigation/navigation-safe-args-generator/src/test/kotlin/androidx/navigation/safe/args/generator/KotlinNavWriterTest.kt
A navigation/navigation-safe-args-generator/src/test/test-data/expected/kotlin_nav_writer_test/ReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyReallyLongNameMainFragmentArgs.kt

https://android-review.googlesource.com/1436930

ma...@syslogic.io <ma...@syslogic.io> #14Jun 3, 2022 01:44PM

Just gotten into a similar situation (the title matches): When calling method getArguments() in the constructor, it returns null. While in public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) it returns the Bundle Alike this I can obtain the arguments of a DialogFragment inside a library, which doesn't know about the Navigation at all.