IssueTracker

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