Hi everyone, I’m currently exploring the possibili...

# compose

[Natasha Jordanovska]

Hi everyone,
I’m currently exploring the possibility of migrating our app to use Compose Navigation. All our screens are currently built with fragments that utilize ComposeView. We are interested in transitioning to Compose Navigation, but we’d like to do this incrementally, ideally by mixing traditional fragment navigation with Compose Navigation.
From my initial research, including insights from the Android documentation on incremental migration to Navigation Compose and a relevant open issue on the Issue Tracker, it seems this is not possible. On the other hand, attempting a complete migration in one go could be overly complex.
Has anyone here successfully implemented a mixed navigation system or managed an incremental migration to Compose Navigation? I’m particularly interested in any strategies or examples that could guide us in integrating Compose Navigation step-by-step with existing fragment-based screens.
Thanks for any insights or advice you can provide!

[Stylianos Gakis]

Is this https://developer.android.com/jetpack/androidx/releases/navigation#2.8.0-alpha07 something which would help you here?

[Natasha Jordanovska]

Yes, the new features introduced in androidx.navigation:navigation-fragment-compose version 2.8.0-alpha07 are very relevant to our needs. The addition of ComposableNavHostFragment, which allows for including Composable destinations within traditional Navigation XML files, could potentially facilitate a smoother incremental migration from Fragment-based navigation to Compose Navigation. This is especially beneficial for integrating Compose components step-by-step into our existing application.

However, it’s important to note that this is still an alpha release. This means that while it offers the functionalities we’re interested in, it also comes with the risks typically associated with pre-release software, such as potential bugs and breaking changes in future updates.

[Stylianos Gakis]

You can always wait a few weeks/months

[agrosner]

We’re also moving to compose navigation. And tested out the new Android fragment composables hosted in a composable route, and didn’t notice crazy issues in a POC. Where we define all routes using compose navigation, and then eventually move compose only screens directly to compose only navigation

[agrosner]

“AndroidFragment” composable

[agrosner]

Also going to test if we can intercept direct fragment pushes with a generic route class that holds the fragment class and arguments we wanted to send and switch it to use the navigation controller

[Stylianos Gakis]

Did you notice any not crazy issues then? 😅

[agrosner]

in a simple POC it seemed to work, but havent tested in our production app yet for all of the nuances associated with it.

[Altynbek Nurtaza]

the next step of incremental migration in my company was trying to combine multiple fragments into a single one with its own compose navigation. So if you previously had FragmentA -> FragmentB -> FragmentC then your new hierarchy would be FragmentA -> FragmentBC where the latter has NavHost as its root component with screenB and screen C inside it

[Stylianos Gakis]

Having nested nav hosts are more or less never what you want to do.
Nested nav graphs inside one nav host is the right approach for this.

[Altynbek Nurtaza]

there were obstacles with popUpTo from composable C to fragment A or navigating from fragment A to composable C, which we had to work around, duplicate deeplinks, but other than that we had no major issues. our app navigation is now fully compose, and this approach was useful to us pre navigation 2.8.0-alpha07.
Asking out of curiosity, Could you please indicate other potential problems with this approach? @Stylianos Gakis

[Stylianos Gakis]

Now that it's full compose, is there a need for the second NavHost?

[Natasha Jordanovska]

@agrosner I don’t think that AndroidFragment is useful in our case, as we’ve already converted all our Fragments to use ComposeView and are directly setting their content within Compose. My understanding is that the AndroidFragment @Composable is primarily intended for integrating traditional Fragments into a Compose-based UI, allowing us to use Fragments directly inside Compose. However, since we have already adapted our Fragments to return ComposeView, this approach might be redundant for our needs.

[dazza5000]

Thank you for all of the help everyone!