I have a navigation issue/question I'm looking for...
# compose
s
I have a navigation issue/question I'm looking for help with. Here is basically the situation:
Copy code
NavHost(...) {
    ...
    composable(route = "inner") { 
        InnerFirst(viewModel, callback = object: Callback { 
            fun goToNext() { outerNavController.navigate("innerTwo") } 
        }) 
    }
    composable(route = "innerTwo") { 
        Second()
    }
}

@Composable
fun InnerFirst(viewModel, callback) {
    val innerNavController = rememberNavController()
    viewModel.navigation.observe(LocalLifecycleOwner.current) {
        event?.consume { navigation ->
            when (navigation) {
                is InnerInnerOne -> innerNavController.navigate("innerInnerComposable")
                is InnerInnerTwo -> innerNavController.navigate("")
                is Outer -> callback.goToNext()
            }
        }
    }

    NavHost(innerNavController) {
        ...
        composable(route = "innerInner") { InnerInnerComposable() }
    }
}
So I nav from the outer graph to the inner composable destination, which lands me in the inner graph, and then I navigate from the inner graph to another destination in the outer graph via the callback. All works well except when i go back from Second composable to the InnerFirst. If I go forward through the flow, and go back, when I try to navigate to another destination in the inner graph, the nav controller seems to be processing the navigation event (I see the destination on the back stack) but I don't see the navigation. It's like the inner nav host doesn't react to the innerNavController. Anyone have any insight what might be happening?
s
Nested NavHosts are very very rarely a solution to some navigation issue in the first place https://kotlinlang.slack.com/archives/CJLTWPH7S/p1628603770177000?thread_ts=1628589309.155500&cid=CJLTWPH7S In your situation, why do you have a nested NavHost situation instead of making the “inner” route to be a nested navGraph with its own distinct destinations?
s
Hm I see. I'm not using the inner NavHost to solve an issue per se, and it actually works pretty well outside of this back nav scenario. I have the InnerFirst view model that is created with nav args and from which I need to observe those events. plus the pattern we use for our other composables for the nav destinations has been event observation and invoking our content, and here I want to swap the typical composable content with another NavHost, so it was quite natural