Perhaps I'm doing something wrong, but it seems like I cannot popBackStack(route: String, inclusive: Boolean) and pass in a NestedNavGraph route string. When I pass in the route string for a nested nav graph that I know is on the backStack, the entire backStack is popped and the function returns false. However if I provide the startDestination route of that nested nav graph to popBackStack it works. When looking at the list of the navController.currentBackStack.value I can see the nested navgraph routes there. Am I doing something wrong? and in this situation what's the difference between poppingBackStack to a specific destination in the backStack versuses navigating to a specific destination and launchingSingleTop? (I understand that navigating to a destination and launching singleTop will work even if the destination is not on the backStack whereas popBackStack() will not work if the destination is not already on the backStack, but assuming that the destination is always on the backStack, what's the difference, and how would you decide which to use?) Edit: I also mean while poppingUpTo in the case of navigating. This is in Jetpack Compose using Jetpack Navigation and Nested nav graphs to "modularize" certain sections of my app. probably not kotlin but kotlin colored

The fact that it actually pops something means that it did work - the reason it returns false is because you've popped every destination on the back stack, which leaves you at an empty screen (which means you need to pop the activity or navigate somewhere new to show something to users).

Ian Lake, right, I understand. I gave it a route that was in the third position in the backStack which was a route that belonged to a nested nav graph, it decided to pop the entire backStack and return false as if it was an invalid destination or something.

Maybe you're not reading the currentBackStack correctly (which is why it isn't part of the public API surface)? That back stack has both NavGraph destinations and composable destinations (e.g., the first thing in that graph is always the root graph, the second one would be a nested NavGraph you are in, and only the third one is an actual composable screen)

Oh I see, that's what's happening then, the stack currently is [null, authenticated_graph, inventory_graph, inventory_list_screen]. inventory_graph is the route I'm passing in to pop, which is just going to clear the entire stack because there's no children screens anymore. I guess for some reason I was expecting the inventory_graph to recreate it's start destination again for some reason, similar to if I navigated to the inventory_graph, popUpTo, launchSingleTop

if you popped inventory graph's start destination off your back stack, nothing is going to magically bring it back - you'd have to explicitly do that

Maybe you already answered this and I didn't understand, but is there a clear distinction on whether I'd want to popBackStack("inventory_list_screen", inclusive = false), now that I know I don't want to pop back to the graph. Or just navigate with popUpTo of inventory_graph? I'm basically navigating from a ListScreen to a FilterSelectionScreen which also has a nested TagSelectorScreen, it seems intuitive to popBackStack from FilterSelectionScreen in when I press my "Apply Filters" button, but this button composable also exists on the TagSelectionScreen but it's it's own button, and I'm not sure whether the buttonPress should popBackStack back to the destination I would expect to be two destinations back, or to navigate back to that specific destination I would expect to be two destinations back.

You could just call

popBackStack()

twice

I see, I wasn't sure if that would give an interesting animation of showing the FilterScreen briefly, I haven't upgraded to the latest Compose Navigation which includes a bunch of the Accompanist animation stuff yet due to other issues my app has with that, but I figured there might have been a U.I. reason not to do that. I guess I can just upgrade the dependency again and check that specific case and see. But would you expect there to not be any issues doing that?

If you're calling

popBackStack()

on the UI thread (as you have to) and call it back to back (i.e., without any

delay

in between or anything silly), then there cannot be a composition happening i between those two calls

Cool, that's good to know!

Personally I'd probably just put those two screens in a

filter

graph and

popBackStack("filter", true)

when you want to leave the filter flow

Oh, smart, they're already in a FilterGraph.

Then it doesn't matter how many steps you have in the filtering process

Sweet, yeah that makes sense and I'm not sure why I didn't think of that! So many different ways to do the same or a similar thing.