I am having difficulty finding a unified way to handle deeplinks. I have a single activity, multiple fragments app, where I have migrated some of the screens to compose. The chain of calls for handling an incoming

intent

looks like the following: • Before migrating to compose:

Intent

-> Activity (

onCreate

&

onNewIntent

) -> RootFragment -> route to the destination • After migrating to compose:

Intent

-> Activity (

onCreate

&

onNewIntent

) -> RootFragment -> route to the compose

NavHost

-> route to the compose destination The hybrid solution looks too complicated. There are many paths to cover, to name a few: • The

intent

delivered to

onCreate

call is handled automatically by compose

NavHost

, but not in other cases. Moreover, the handled

intent

is not cleared, thus the compose

NavHost

will handle the

intent

every time we navigate to it. • If the compose

NavHost

is already open and active, the behavior is different than when it's not. If it's active, we can have an

Intent

consumer listener set and act upon the incoming

intent

, if not, we need to deliver the deeplink somehow to the

NavHost

. Is it the way we're supposed to implement this? Is there a simpler, more unified way of handling deeplinks that works for a hybrid app (View & Compose)?

Which navigation solution are you using in your project? I think the suggestion with nav in general is to not go half-half, but go all in or one or the other. This is why even for a 90% compose project, it’s suggested to keep the fragment navigation, even if the fragment simply wraps a compose screen, until 100% of the screens are compose, and then you can migrate all those wrapper fragments to no longer be fragments, but normal compose destinations.

I am not using the Navigation component, just normal fragment navigation. I wanna start migrating to compose navigation gradually and I am doing the first flow fully in compose. As you said, it's hosted in a fragment at the moment.

normal fragment navigation

that’s still with

androidx.navigation

I suppose?

No, no navigation library 😅

Welp, I am afraid this is where my knowledge ends then, I don’t think I can help you there unfortunately 😅

Let's assume I am using

androidx.navigation

. How does that change your answer? 😊

You can then just off-load all of the deep-links to the library itself https://developer.android.com/guide/navigation/design/deep-link#handle, and since you’ll have all destinations be fragments, then all destinations will be handled the same, compose or not should not matter in the slightest. After the migration is done, then you can again offload all the deep link work to the library, by specifying your destination’s deep links using the library dsl, kinda like here https://github.com/HedvigInsurance/android/blob/b736f1d031d956171643de3914d28f8df4[…]onnect/payment/trustly/navigation/ConnectTrustlyPaymentGraph.kt

But not all the destinations are fragments. I am gonna have a compose NavHost which contains multiple composable screens inside a fragment.

Yes, which is what I was talking about up here https://kotlinlang.slack.com/archives/CJLTWPH7S/p1698934747616249?thread_ts=1698841061.239999&cid=CJLTWPH7S I believe the most painless transition path you can take is to not mix and match the two approaches, and either: • Have a single NavHost and do everything with compose destinations (some destinations could be composables wrapping fragments). • Do not use NavHost at all, and use normal Fragment navigation everywhere until you are ready to get rid of it and go with a single top level NavHost.