I am having difficulty finding a unified way to ha...

# compose

[Mbt925]

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)?

[Stylianos Gakis]

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.

[Mbt925]

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.

[Stylianos Gakis]

normal fragment navigation that’s still with androidx.navigation I suppose?

[Mbt925]

No, no navigation library 😅

[Stylianos Gakis]

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

[Mbt925]

Let's assume I am using androidx.navigation. How does that change your answer? 😊

[Stylianos Gakis]

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

[Mbt925]

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

[Stylianos Gakis]

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.