I think there is something wrong with the Navigati...

# compose

[Mehdi Haghgoo]

I think there is something wrong with the Navigation docs in the Interoperability section. Navigating from fragment-based screens to Compose screens is fine. You just wrap the Compose UI in a ComposeView and go! But, I don't understand what the docs say when the reverse is to be done; Navigate from a Compose UI to a Fragment. The example snippet is not clear if not wrong.

[Ian Lake]

I think that last code snippet should be composeView.setContent to indicate that the Fragment's content is built using Compose, but the general idea of having your screen take lambdas rather than having a direct dependency on Navigation / NavController seems to align well with the Testing section on that same page

[Ian Lake]

It just happens to be that NavController is owned by the NavHostFragment that created the fragment (as per the recommendation in those first paragraphs in the Interop section); there's no NavHost at all in the interop case

[Mehdi Haghgoo]

So, if the fragment content is made using XML files the old way, navigation to it from Compose code will not work?
I just tried to run the following code, but it crashed and tells me that the NavHost must be inside this activity :

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent{
        ComposeScreen(onNavigate = { findNavController(R.id.nav).navigate(it)})

    }
}

[Ian Lake]

That code would not be following the recommendation for hybrid apps that the Interop section specifically calls out:

Therefore, the recommendation for hybrid apps is to use the fragment-based Navigation component and use fragments to hold view-based screens, Compose screens, and screens that use both views and Compose. Once each screen fragment in your app is a wrapper around a composable, the next step is to tie all of those screens together with Navigation Compose and remove all of the fragments.

[Ian Lake]

Are you following that recommendation?

[Mehdi Haghgoo]

I am following the first recommendation when navigating from fragment-based screens to Compose-based ones by wrapping fragments around Composables (using ComposeView), but the reverse is confusing for me.
I suppose the second recommendation (the alternative) says I can navigate from Composable destinations to fragments only if the fragments have been defined under the same NavHost, probably using AndroidView.

NavHost(navController, startDestination = "start"){
composable("start"){
StartScreen()
}

composable("fragment-wrapper"){
AndroidView(modifier = Modifier.fillMaxSize(),
factory = {context->
MyFragment().apply{
//...
}
}
){
}
}
}

Is this right for navigting from Compose to fragments?

[Ian Lake]

There is only one recommendation: hybrid apps should always use NavHostFragment and never NavHost. That's what that paragraph says and the line right above that paragraph:

Define a navigation graph with a NavHost in Compose using Compose destinations. This is possible only if all of the screens in the navigation graph are composables.

[Ian Lake]

What that code is showing you is how an onClick within the composable UI of a Fragment can bubble up that event to the Fragment itself, thus allowing you to access the NavHostFragment owned NavController and navigate to another fragment

[Mehdi Haghgoo]

So, basically the 2nd statement talks about non-hybrid (Compose-only) apps, where all screens in the nav graph are composables.

[Ian Lake]

correct

[Mehdi Haghgoo]

If I get it right, this makes things easier, as I was having really hard time inflating a Fragment inside a NavHost node 😁🤦
I like the term bubble up. Very descriptive of what events do in Compose.