IssueTracker

Dany, I believe this is fixed in a new release of safeargs ?

Safeargs still needs AndroidComponentsExtension to get the applicationID from the variants (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigation/navigation-safe-args-gradle-plugin/src/main/kotlin/androidx/navigation/safeargs/gradle/SafeArgsPlugin.kt;l=73). Did AGP 7.2.0-alpha05 remove the extension?

it moved to a different package : com.android.build.api.variant

Safeargs still relies on AGP 4.2. We need some of the BaseVariant APIs to have replacements before we can upgrade to 7.0+ (https://issuetracker.google.com/203557189).

The BaseVariant API are deprecated but still available in 7.x, so you should be able to release a newer version that uses the new package and still relies on the old API you require. Or am I missing something ?

I'll try updating to the latest stable to see if we run into any issues. I can check to make sure changing the package name in 7.2.0-alpha05 works, but we would need it to be stable before we could do a release with this change.

FYI this also breaks the latest Studio (2021.1.1 Beta 5)/AGP (7.1.0-beta05) beta where com.android.build.api.extension.AndroidComponentsExtension has been removed.

Is there a particular reason why https://issuetracker.google.com/203557189 and this issues don't have a higher priority?

As it stands, no one can upgrade either AGP/Studio Beta or Canary and take advantage of fixes in the latest versions because Navigation still uses the old AGP APIs.

Was this fixed in Studio 2021.1.1 RC 1?

I do not think so https://developer.android.com/studio/releases/fixed-bugs/studio/2021.1.1#android-studio-bumblebee-rc-01-2021.1.1.19.

Pretty disappointing though.

This will be fixed in the Navigation Safe Args 2.5.0-alpha01 and 2.4.1 versions. You can follow the snapshot instructions and try this out with build id #8054565.

Thank you! 2.4.1 is at least two weeks out (possibly 4, if I'm not mistaken).

I applaud the AGPs team decision to stick to the new APIs though. Hopefully its not too long before Navigation fixes this.

So we are talking mid february ?

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Dolphin Canary 5 (2021.3.1.5)
• Android Gradle Plugin 7.3.0-alpha05

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Is this included in the Dolphin Beta 1 build? 7.3.0-beta01?

I'm able to consistent reproduce this when having the namespace field setup in my gradle file. Removing it (and adding the value back to the Manifest files) does not cause the issue. Not sure if the same case here, or a new one.

May be related to this one ? https://issuetracker.google.com/231704909

Right, the direct incompatibility between AGP and Safe Args is fixed, I believe, but there's another issue related to the use of applicationId vs namespace, tracking at http://issuetracker.google.com/232107688. Thanks!

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