https://kotlinlang.org logo
Join Slack
Powered by
Perhaps I'm doing something wrong, but it seems li...
# compose-android
b
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
i
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).
Popping up to a graph or popping to the first destination in that graph really only differs when you navigate with popUpTo to another child in that graph
b
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.
i
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)
So if you pop the "third" thing in that stack, that certainly might be the only actual screen on the back stack
The point is when you pop the last actual screen on a navigation graph, the graph gets popped too (graphs only live as long as they actually have real child screens on the back stack)
b
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
i
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
which is actually the case where 
navigate
with a 
popUpTo
of 
inventory_graph
vs 
inventory_list_screen
would differ (assuming what you navigate to is also part of 
inventory_graph
)
as 
popUpTo(inventory_graph) { inclusive = true }
would destroy any state at the 
inventory_graph
level, while using 
inclusive = false
or popping to 
inventory_list_screen
would keep any state attached to the graph around so that your new child screen of that graph could continue to reference it
b
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.
i
You could just call 
popBackStack()
twice
b
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?
this is pretty short if this helps to give context.
see results.webm
i
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
b
Cool, that's good to know!
i
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
b
Oh, smart, they're already in a FilterGraph.
i
Then it doesn't matter how many steps you have in the filtering process
b
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.
I appreciate your time and help.
👍 1
23 Views
Open in Slack
PreviousNext
Powered by