implement result API based on NavBackStackEntry

[gabrielittner]

This removes the fragment navigation result APIs and replaces them with new result APIs that work for both fragment and compose navigation.

How the API works

Inside your navigator you register for the results like before

val imageResultRequest = registerForNavigationResult<FooRoute, ImageResult>()

The new part here is that you need to specify FooRoute which is the route to the destination of the navigator.

The returned NavigationResultRequest is a ResultOwner like before so the results can be collected through imagePickerResultRequest.results.

What's new is that the request also holds a key. This key should be passed to the destination from which we want to retrieve a result:

@Parcelize
data class ImagePickerDirections(
    val key: NavigationResultRequest.Key<ImageResult>
)

The image picker in this example can then call deliverNavigationResult with this key to return a result. To keep the API simple there is no automatic back navigation anymore like we had in navigateBackWithResult:

navigator.deliverNavigationResult(imagePickerDirections.key, imageResult)
navigator.navigateBack()

Advantages

• works for compose as well
• no more extra FragmentNavEventNavigator class
• the string key for the result doesn't need to be a shared constant anymore it's only used in registerForNavigationResult

Disadvantages

• internally going through the SavedStateHandle of a NavBackStackEntry isn't as nice as the very direct Fragment API

[gabrielittner]

Maybe we can also remove the string key from registerForNavigationResult<FooRoute, ImageResult>("my-request-key") we could create it internally using the classes of FooRoute and ImageResult. The only limitation that this would bring is that you'd only be able to have one result request per result type. So you couldn't have to separate requests for ImageResult in the same screen, but I'm also not sure if there is a use case for that.

[gabrielittner]

If we later on find a use case for multiple requests for the same result from the same screen we could internally have an AtomicInteger that we increment and append to the key in registerForNavigationResult. We'd need to require ordering for calls to it but that's the same already for the activity and permission APIs were the underlying AndroidX APIs require ordering. So I'd say we can remove the string key

[gabrielittner]

Removed the string key in c8df194

[kboyarshinov]

LGTM 👍