I’m having some issues with navigation in compose ...

# compose-android

[Almeric]

I’m having some issues with navigation in compose and I’m wondering if it’s expected behaviour…

I have a bottom navigation bar with two top-level destinations (A and C) A is a nested navigation graph which also contains destination B.
If I navigate A -> B, then click on the bottom nav item to go to C and then click on the first bottom nav item I’m back at B (as expected). But if I go back using the system navigation I return to A, but I expected to return to B (as that’s the current ‘active’ item in A’s graph).

More info in thread

[Almeric]

This is my NavHost:

NavHost(
    modifier = Modifier.padding(it),
    navController = appState.navController,
    startDestination = "homeGraph"
) {
    navigation(
        startDestination = "home",
        route = "homeGraph"
    ) {
        composable("home") {
            Home("A") {
                appState.navController.navigate("home2", null)
            }

        }
        composable("home2") {
            Greeting("B")
        }
    }
    composable("settings") {
        Greeting("C")
    }
}

[Almeric]

Navigating to top level destinations is done as follows:

fun navigateToTopLevelDestination(topLevelDestination: TopLevelDestination) {
    val topLevelNavOptions = navOptions {
        popUpTo(navController.graph.findStartDestination().id) {
            saveState = true
        }
        launchSingleTop = true
        restoreState = true
    }
    when (topLevelDestination) {
        TopLevelDestination.HOME -> navController.navigate("homeGraph", topLevelNavOptions)
        TopLevelDestination.SETTINGS -> navController.navigate("settings", topLevelNavOptions)
    }
}

And here’s a recording of the issue:

Screen_recording_20231030_085137.webm

[Almeric]

I expected to return to B when swiping back from C. Am I wrong in my assumption, or is there something I’m doing wrong? Thanks!

[Stylianos Gakis]

Hmm, I am not sure what the navigation principles say for this one, but it does make sense that B is not also restored, since you only pop the backstack, you don’t also explicitly ask for it to restore the state right? From that perspective it makes sense I would say.

[Almeric]

The weird part is that after I use the system back from C I go to A, but if I then click on the first item in the bottom navbar (which is already active) I’m back on B. I can imagine that’s confusing from a users’ perspective.

[Stylianos Gakis]

Not necessarily. There’s two things at play here:
• Clicking at the bottom nav to go somewhere, is connected with also remembering where you were in that tab previously and restoring it accordingly
• When you are at the root of C, going back you expect to go back to the start destination of the app, where another back will then make you exit the app.
I think the navigation principles really put a lot of emphasis on getting predictable and consistent behavior when going back from the root of a bottom nav bar destination. And this may be more important than point #1.

I don’t know what your UI in the real app really looks like, but for us when you are in A, if we navigate somewhere from there which is not a top level destination, then the bottom nav is hidden, so that interaction can never happen when you are in A -> B and then you go to a top level destination after saving state. If this is not the case for you, not sure if there’s something to be done here.

Sorry for the ping, but this in general is an interesting question for navigation I think @Ian Lake. Is this specified anywhere in the docs? Because I haven’t found anything myself.

[ascii]

Start destination is key here. If you set startDestination = "home2" you'll see that pressing back from C will always open B.

[ascii]

I don't know if there's a way to remember nested destinations when going back, other than mutating startDestination via remember + mutableStateOf.

[Stylianos Gakis]

If you set startDestination = "home2" you’ll see that pressing back from C will always open B.

Then you are breaking the entire graph, why would they want to change the entire start destination for this?

other than mutating startDestination via remember + mutableStateOf

That to me sounds like a bad idea. If you do that, then if you are in B and you want to do the back gesture, then what, would you exit the app directly from “home2"? If that’s the start destination you’d also want it to be the beginning of the backstack, so as you try to go back you’ll see the back gesture exiting the app and then you’d actually exit the app, no?

[ascii]

why would they want to change the entire start destination for this?

Just an example to help them understand

[Ian Lake]

You said popUpTo(navController.graph.findSta rtDestination().id) so the only thing left on the back stack (e.g., what happens when you do system back) is the start destination of the graph, so what you're seeing is exactly what you said you wanted to see.

[Ian Lake]

That aligns with the expectation here: users shouldn't be popping back through many back stacks (e.g., no stack for tab c or stack for tab a either) - once they finish the stack on tab b, they see the start destination (their signal that the next back press will take them out of the app), then the next system back takes them out of the app.

[dorche]

On that last bit "they see the start destination (their signal that the next back press will take them out of the app)" - is that the start destination of the inner graphs? Does that assume that the start destination is not one of the bottom nav items itself?

[Ian Lake]

If you say popUpTo(navController.graph.findStartDestination().id), that is the start destination of your entire graph. It is actually assumed that it is part of your bottom nav, not the opposite, but that's more of a convention than requirement

[Almeric]

Thanks for looking in to this everyone! So in short I’d say it’s expected behaviour. I hoped that by using saveState = true in the PopupToBuilder this would also restore the state when popping ‘back’ to this destination.

[glancy]

Sorry to join this conversation so late. I was just running into a similar issue and came across this thread in my research.

I can accept the argument that the user wouldn't want to go through multiple back stacks to leave the app. However, there is still one thing I can't accept.

So far you guys covered:
A (home tab) -> B -> C (settings tab) -> System back to land on A

Now say you continue on from there and navigate to a different screen from screen A. Let's call it B Prime. If you then click the C (settings) tab, and then back to the A (home) tab again, what is expected?
I would expect to see B Prime since that is the last thing I had seen on the A (home) tab.

Unexpectedly, I am seeing the original B screen get restored!

demo.mp4

[Ian Lake]

When you hit system back, you didn't restore the stack of destinations on the A stack, so that stack still has A -> B. That's why that's the stack that is restored when you go to C and then actually restore the stack of A - that data was never lost in the first place.

[glancy]

Thank you for the quick response. I just though when I navigated to B Prime and then went to C, it would overwrite the state. In other words, I expected...

Initial state:
[A]

Launch screen B with button:
[A] [B]

Click tab C:
(With popUpTo start, save state)
[A] [C]
(With a saved state at A of [B])

Click system back:
[A]
(No state is restored, so it remains saved)

Launch screen B Prime with button:
[A] [B Prime]

Click tab C:
(With popUpTo start, save state)
[A] [C]
(With a saved state at A of [B Prime], overwriting the original back stack at A of [B])

Click tab A:

Expected:
[A] [B Prime]
(Since the state is restored)

Actual:
[A] [B]
(Original back stack state is restored, not the last back stack seen)

So if the B Prime stack on tab A didn't overwrite the original tab A back stack, did it actually save? How would I restore that? Because it seems like a weird user experience to restore an older back stack on tab A, not your most recent back stack.