I'm trying to figure out how to pass arguments to the start of my compose nav graph. I haven't worked with composable navigation before and I'm most likely doing things in an unrecommended way a bit, but here's a little more detail with what I'm trying to do. I've got a fragment with a ComposeView, and that composable content contains the composable nav graph...the simplified version is something like this:

fun SomeComposableContent(startRoute: String) = 
    NavHost(
        route = "outer",
        startDestination = "inner/{userId}"
    ) {
        navigation(startDestination = "inner/start/{userId}", route = "inner/{userId}" {
            composable(route = "inner/start/{userId}") { backEntry ->
                val userId = backEntry.arguments?.getString("userId")
                ScreenOne(userId)
            }
        }

        composable(route = "next") {
            ScreenTwo()
        }
    }

If I use the "next" destination as my start and then navigate to the inner graph with passing an arg, things work, but if I want to start at the inner start destination, and I'm not calling navController.navigate(), how can I pass the argument? I'm basically trying to load the graph and pass the argument..is that possible?

Use `defaultValue`: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1623851605280400?thread_ts=1623841420.270700&cid=CJLTWPH7S

ok. since this userId, or argument, isn't like a set value and changes per user, can that default value be dynamic? i guess i would split the string and grab the argument? what's the structure of the navigation string if there are multiple arguments?

Yes, your defaultValue can certainly be a dynamic value set by your fragment - it is just Kotlin code. Your parsing code is still all correct - any

{userId}

is still going to be automatically parsed, using the

defaultValue

by default

ok cool. it feels a little odd to parse the arg myself sometimes and letting the nav controller parse it other times. it'd be cool if they graph could figure out somehow if there was an arg. i've got some nested graphs, and the way I've been setting up the routes has been like a folder type of structure. so in my first example, the inner graph composable route would be like "outer/inner/start". do you think that's a good convention?

You're not parsing anything; that's done for you. You're just getting the pre-parsed value out of the Bundle.

You're not parsing anything; that's done for you. You're just getting the pre-parsed value out of the Bundle.

if I want to set the default value when I first load the graph, then I will have to parse that value myself, right? that part feels weird to me...i'd rather not have to parse anything and somehow have the nav controller know there's an argument.

You haven't shared where you're getting your default value from or how this code snippet interacts with anything else, so I couldn't tell you

ok yeah fair enough. I'll give you the tl;dr because I would like your feedback, plus I have another question. so I have some feature modules with their own graph and then the app module that brings the graphs together in the main graph. this is all xml/fragments. I have a new feature module that is basically all composables. there's a root fragment with the ComposeView, and the composable graph is defined in there. since everything in this module is a composable, i figured I could get away with mixing the xml and compose graphs. I may not actually need to do this anymore, but I was trying to enter into this composable graph with the args. when I get to the root fragment, I grab the args from xml nav, and construct the destination basically.

I think the structure you've chosen is not sustainable - we have always recommended only a single host: https://developer.android.com/jetpack/compose/navigation#interoperability

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.

If you are in a fragment world, you should stay in a fragment world, even if your entire fragment's UI is built with Compose

I know it's not recommended to mix the two, but what kind of issues do you think I'll have doing the module of just composables w/ the root fragment for setting content? how is it different from just using a ComponentActivity with setContent? They're both setting the composable in a ComposeView it looks like, and having the compose nav graph in the compose views is normal. right?

@Ian Lake I was kinda trying to the same with nested NavHost & I'm wondering if I'm doing something not supported or doing something wrong. We have a hybrid views & compose app. All compose screens hosted in fragments. But in one of the new screens we were trying to use nested NavHostController via rememberNavController. The problem is: navigation state is not properly restored when coming back from process death (rememberNavController is resetting to initial state somehow during recompositions). Interestingly enough, when I host the compose screen directly in the activity, state restoration works:

MyComposeFeatureScreen:
      rememberNavController()
        FeatureScreenOne
        FeatureScreenTwo

// Navigation backstack not restored
MainActivity {
  onCreate:
    jetpack fragment navigation:
      fragment:
        setContent MyComposeFeatureScreen:
}

// Navigation backstack restored
MainActivity {
  onCreate:
    setContent MyComposeFeatureScreen:
}

Diff in logs when coming back from process death:

CustomersLaunchedEffect: navController: Destination(0x4998a1c7) route=customers/, androidx.navigation.NavBackStackEntry@198f9b8
 CustomersLaunchedEffect: customerActionResult: MutableState(value=null)@120014880
 CustomersFragment: LaunchedEffect
 CustomersLaunchedEffect: navController: Destination(0x9acde377) route=customers/{customerId}?isEditMode={isEditMode}&isInvoiceMode={isInvoiceMode}, androidx.navigation.NavBackStackEntry@73d12977
 CustomersLaunchedEffect: customerActionResult: MutableState(value=null)@50352885
 CustomersFragment: LaunchedEffect
 CustomersLaunchedEffect: navController: Destination(0x4998a1c7) route=customers/, androidx.navigation.NavBackStackEntry@e2b2011e
 CustomersLaunchedEffect: customerActionResult: MutableState(value=null)@80460568

CustomersLaunchedEffect: navController: Destination(0x4998a1c7) route=customers/, androidx.navigation.NavBackStackEntry@70ec0fac
CustomersLaunchedEffect: customerActionResult: MutableState(value=null)@101095983

So is the way we're trying to use compose NavHostController in Fragment is not right / supported? Or is it a bug in rememberNavController?

That's absolutely supported. There are no known cases where

rememberNavController

doesn't work but other things that rely on

rememberSaveable

do work, so that would be the first thing I'd try (just having a

rememberSaveable

integer that a button increments and seeing if that count works across process death). If neither work, then your issue is with your Fragment code

Hmm I think I was doing something very dumb.. I had a temporary code that was starting my MyComposeFeatureScreen on Fragment's onViewCreated.. Noticed it after trying simple ui with counter &`rememberSaveable`. The restored MyComposeFeatureScreen was behind the second newly opened MyComposeFeatureScreen.. Thanks for hint trying simple rememberSaveable!