A modern programming language that makes developers happier.

kotlinlang

Hi team, I have a question about Navigation 3 interop. In our current setup, we still have some screens implemented as fragments and a few flows that rely on activity destinations. Nav3 seems to support only Compose → Compose navigation, so it doesn’t allow mixing fragment or activity destinations like Nav2 does.

Is there a recommended migration path or upcoming support for fragment/activity interop in Nav3? Or is the long-term expectation that apps fully move to Compose before adopting Nav3?

As far as I understand, the interop story is `AndroidFragment` and `ActivityLauncher` directly from your composables. There's no custom entryProvider for A/F like there is with Nav2.

Winson is correct, screens can certainly use `AndroidFragment` for all of their content.

Activities were 'exit points' in Nav2 anyways (they were never adding the NavController's back stack or anything), so they just do the same `startActivity` you can do yourself

(FWIW, there's a `LocalUriHandler` that is available in common if you want Android specifics and reference your other activities by a Uri that they handle)

Thanks, that’s very helpful! So just to confirm for apps that still rely on fragment/activity screens, staying on Nav2 is the recommended path until those screens are migrated to Compose, right?

If you are using Navigation Compose, then you should switch to Navigation3 no matter what. If you are using Nav2 with Fragments (e.g., `NavHostFragment`), then you're using Fragments for your transition system, which is a bigger change if you were to swap to a Compose based navigation system, but you'll be much better set up for 'stopping the bleeding' and building all your new screens in Compose from the start

This is really helpful regarding Activities.
My main blocker for adopting Nav 3 is that our app still relies heavily on legacy XML Fragments, and we aren't in a position to rewrite them all to Compose right now.
Can you confirm that Nav 3 fully supports this 'Interop' scenario if we wrap our legacy fragments in AndroidFragment? We want to make sure we aren't breaking our old screens by upgrading.

Are you coming from a Navigation Compose setup (`NavHost`) or Nav2 with Fragments setup (`NavHostFragment`)?

We are coming from a Navigation Compose `(NavHost)` setup. We do not use `NavHostFragment`.
However, we still have legacy Fragments in the codebase that we need to navigate to and display within our Compose graph when we adopt compose navigation.

And how do you navigate to those legacy fragments right now? Do you use the `navigation-compose-fragment` dependency and it's `fragment` destinations you can put in your Navigation graph you pass to `NavHost`?

Thanks Ian! Currently, we don’t use `NavHostFragment` or any fragment-based navigation setup. We also don’t have `NavHost` yet,  we’re still in the early stages of moving XML/fragment screens to `Compose`, so our legacy fragments are launched in the traditional way (regular fragment transactions).

At this point, we’re just trying to understand what the recommended interop path is while we gradually migrate those screens to `Compose`. Should we continue using the current fragment transaction approach during this transition, or is the `navigation-compose-fragment` dependency the right path even before adopting a full `NavHost` setup?