IssueTracker

Oh I forgot to mention that I thought it might be connected to this issue: https://issuetracker.google.com/issues/243778589. But after trying 2.5.2 I can say that the issue persists.

Please provide a minimal sample project along with the minimal steps to recreate the issue in the project.

Sorry for the delay. I got a working example here: https://github.com/Del-S/issues. The project is set up to crash when navigating to ThirdFragment (nested nav graph) with poping the graph.

I poked into it a little bit and it seems to be connected to SafeArgs gradle plugin. When safe args is used to navigate to ThirdFragment (with nested graph poped) it will try to recreate te parent but there were no arguments passed so it crashes.

Steps to reproduce:

1. Navigate from Second Fragment to Child nav graph (with non-nullable parameters).
2. Navigate to Third fragment using SafeArgs and the app crashes.

Crash log:

Process: cz.dels.issues, PID: 1743
java.lang.NullPointerException: null cannot be cast to non-null type kotlin.Long
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:352)
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:342)
at androidx.navigation.NavArgument.verify(NavArgument.kt:76)
at androidx.navigation.NavDestination.addInDefaultArgs(NavDestination.kt:502)
at androidx.navigation.NavController.addEntryToBackStack(NavController.kt:1865)
at androidx.navigation.NavController.addEntryToBackStack$default(NavController.kt:1813)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1721)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1719)
at androidx.navigation.NavController$NavControllerNavigatorState.push(NavController.kt:287)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:246)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:162)
at androidx.navigation.NavController.navigateInternal(NavController.kt:260)
at androidx.navigation.NavController.navigate(NavController.kt:1719)
at androidx.navigation.NavController.navigate(NavController.kt:1545)
at androidx.navigation.NavController.navigate(NavController.kt:1472)
at androidx.navigation.NavController.navigate(NavController.kt:1930)
at cz.dels.issues.SecondFragment.onViewCreated$lambda-0(SecondFragment.kt:38)
at cz.dels.issues.SecondFragment.$r8$lambda$XDYnOS_cYrafiNQ5rcCu1WCn0IE(Unknown Source:0)
at cz.dels.issues.SecondFragment$$ExternalSyntheticLambda0.onClick(Unknown Source:2)

Note: If in step 2 SaveArgs is not used then navigation works correctly. More information is here: https://github.com/Del-S/issues/blob/master/app/src/main/java/cz/dels/issues/SecondFragment.kt#L37.

Ups a typo: Navigate from Second First Fragment to Child nav graph (with non-nullable parameters).

Note: sorry for the spam but I am not able to edit my own comment.

This has been fixed and will be available in navigation 2.6.0-alpha08

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

• androidx.navigation:navigation-runtime:2.6.0-alpha08

This has been fixed internally and will be available in the Navigation 2.3.0-alpha02 release.

With this change, you can now get a SavedStateHandle from a NavBackStackEntry and use the given SavedStateHandle to pass a result between two entries.

If Fragment A needs a result from Fragment B..

A should get the savedStateHandle from the currentBackStackEntry, call getLiveData providing a key and observe the result.

findNavController().currentBackStackEntry?.savedStateHandle?.getLiveData<Type>("key")?.observe(
    viewLifecycleOwner) {result ->
    // Do something with the result.
}

B should get the savedStateHandle from the previousBackStackEntry, and set the result with the same key as the LiveData in A

findNavController().previousBackStackEntry?.savedStateHandle?.set("key", result)

Because this uses SavedStateHandle, all results need to be types that can be added to a Bundle (i.e Parcelable, Serializable, etc.).

Re #58 - the documentation specifically calls out:

If you’d only like to handle a result only once, you must call remove() on the SavedStateHandle to clear the result. If you do not remove the result, the LiveData will continue to return the last result to any new Observer instances.

The result is scoped to the NavBackStackEntry you access and will otherwise live as long as that destination is on the back stack.

Re #60 - there's two separate things to keep in mind:

1. previousBackStackEntry is not tied to your Fragment at all, it is agnostic to what type of destination you are using (it would equally well if you were using Views or Composables for your destinations). It therefore provides no way to access anything related to your Fragment. This is intentional.

2. A NavBackStackEntry (such as the one returned by previousBackSTackEntry) is a ViewModelStoreOwner and therefore can be used to store any ViewModels you want via by navGraphViewModels(R.id.your_previous_id) or by viewModels({ findNavController().previousBackStackEntry!!}). The SavedStateHandle we provide is just a shorthand for creating a ViewModel in the NavBackStackEntry and getting its SavedStateHandle.

Re #57

You could theoretically instead "previousBackStackEntry" use "getBackStackEntry(int destinationId)" and get its' savedStateHandle.. But it would be a very bad practice to hardcode a fragment to return it's result 2 steps back..
For your use case it's much more appropriate to use navGraphScoped ViewModel which would be common and shared among all A, B, C: https://developer.android.com/reference/kotlin/androidx/navigation/package-summary#navgraphviewmodels.
Or just pass it back through B...

What if I want to reuse fragments B&C in another nested graph so I don't want to hardcode the nav graph id in navGraphScoped? The only solution I found is to pass the graph id trough fragment args.

Re #62 - that's certainly a valid option if you want to deliver results to a specific destination on your back stack. previousBackStackEntry is just a helper for the most common case, nothing more.

Re #65 - yes, you can use the new Fragment Result APIs between Fragments when using the Navigation Component. Note that much of the Additional Considerations for Dialog destinations have no direct equivalent in the Fragment Result API.

Re #67 - please see b/154405007 which covers that problem in detail.

#68 Is that link require googler account?

Re #69 - sorry, you'll want to follow the issuetracker.google.com version of that link.

Well, apparently I can't paste links correctly today. It's https://issuetracker.google.com/issues/154405007