I'm struggling to implement a rather simple behaviour (automatic navigation without user interaction) using the recommended Architecture pattern where only a ViewModel is passed to a Composable and some navigation block to trigger on a user interaction. I've tried to pass a route as a State to the Composable (which triggers navigation when not null) in order to treat it as simple data in the ViewModel but I'm then stuck because when the user hits Back it navigate him back to the most recent screen automatically. I think I would need some kind of transient state which is restored to null when processed by the Composable view but I really don't know how to do it... Any input/help would be very very appreciated 🙏

When you find yourself wanting to reset or null out a state or otherwise mark something as consumed during composition, that's a sign that you have an event that should be processed into state instead. Think of your route like a URL bar; it stays put the whole time you're at that location in the app, it's not consumed by the act of navigating to it.

If I understand well, what you mean is that my current architecture where i set the route "to navigate to" as a State of my composable is the right way to solve my problem ?

I think generally you'd want

data class MyState(val currentScreen: String)

and then you'd have

if(state.currentScreen=="a") { ScreenA() ) }

I understand what you suggest but it means you don't use the Navigation component and the NavGraph, you're making your own navigation by using conditional logic inside a Composable right ?

Yes

I'm using

navigation-compose

I actually have the same idea of make the route a state...

class MyViewModel : ViewModel() {
    val currentRoute: MutableStateFlow<String>()

    ....
}

@Composable
fun MyScreen(
    navController: NavController,
    myViewModel: MyViewModel,
) {
    val route = myViewModel.currentRoute.collectAsState(startRoute)
    navController.navigate(route)
}

But I don't how

popBackStack()

or even

popBackStack(id)

would be done this case? Any idea?

do you mean the popBack to MyScreen or from MyScreen ?

@David Attias regardless? i guess?

So, my problem with this architecture is indeed the fact ,once you navigate to the other screen and that when you will want to popBack to

MyScreen

, it will immediately navigate back to the new route....

How would that work? Could you show it? I kinda think that to do

popBackStack()

in this architecture, we would also have to set the

currentRoute

to

previousRoute

, which means holding on to the

backStack

(consumed route) itself. I hope there would be an official sample for this in the future...

I'm currently trying to implement it, I will share it asap. I'm currently stuck, I can't wait for an official way to do it...

I'm still not quite sure I understand; if you're using navigation-compose you already have an object with methods you can call to navigate to a destination in response to an action, right? 🙂 if you have a state that represents what content you're looking at and the stack of content beneath it, that's a form of navigation construct as well. If you handle the back button, you can nest one inside the other if, when, and where it makes sense for the app

Yes but my use case is that I don't have a user interaction, I want to initiate a navigation based on a ViewModel logic so it doesn't fit with the typical navigation-compose examples where the navigate() is injected in a button callback.

can you call navigate from the viewmodel method?

I could but from what I read, it sounds like a bad practice to reference the NavController in the ViewModel

I think we're coming around to the desire for observing a callback or event again then, to launder that call a bit in the abstraction layering 🙂

Yes, you're right, this is a bad idea to model that as a state

If you're looking for a way to bridge a channel-derived flow of viewmodel events to navigation calls when the navigator lives in a composable, this pattern for managing the scope of an observer without its events becoming state might be useful:

LaunchedEffect(navigator, viewModel) {
  viewModel.navEvents.collect { navigator.navigateTo(it) }
}

Thanks, I will look into that pattern to see how it could fit my needs.

@Adam Powell Is this still the recommended way to trigger navigation from a ViewModel / to handle one-shot events?

All the same principles of distinguishing state vs. events still apply, yes. Where you scope a collector/observer may vary based on your app, the above snippet is just one example.