https://kotlinlang.org logo
#compose
Title
# compose
m

Mbt925

11/01/2023, 12:17 PM
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)?
s

Stylianos Gakis

11/02/2023, 2:19 PM
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.
m

Mbt925

11/02/2023, 2:33 PM
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.
s

Stylianos Gakis

11/02/2023, 2:36 PM
normal fragment navigation
that’s still with
androidx.navigation
I suppose?
m

Mbt925

11/02/2023, 2:39 PM
No, no navigation library 😅
s

Stylianos Gakis

11/02/2023, 2:41 PM
Welp, I am afraid this is where my knowledge ends then, I don’t think I can help you there unfortunately 😅
😄 1
m

Mbt925

11/02/2023, 2:45 PM
Let's assume I am using
androidx.navigation
. How does that change your answer? 😊
s

Stylianos Gakis

11/02/2023, 2:51 PM
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
m

Mbt925

11/02/2023, 3:04 PM
But not all the destinations are fragments. I am gonna have a compose NavHost which contains multiple composable screens inside a fragment.
s

Stylianos Gakis

11/02/2023, 3:14 PM
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.
👍 1