Compose Navigation Let's have A -> B -> C -&...
# compose
Compose Navigation Let's have A -> B -> C -> D nested navigation. Something like
Copy code
NavHost(startDestination = "A") {
   composable("A") {}
   navigation(startDestination = "B") {
     composable("B") {}
     navigation(startDestination = "C") {
       composable("C") {}
       composable("D") {}
I struggle with navigateUp(). It seems that it nicely utilize startDestination. So when deeplinking "D", navigate Up ends up in C. But when I continue with navigateUp in C, I skip to the "A", not "B" as I would expect. Is it a bug? Some debugging info in thread.
So the behavior is that the firstNavigateUp() recreates the activity and adds the "tree" to to backstack. However, the tree resolution seems buggy to me. First, it happens three times. Not sure why. First for the Navhost#A, then Navhost#B and Navhost#C. There is backQueue that consists of NavBackStackEntry with destination of either NavHost or Destination. After the first navigateUp() and activity recreation, the backQueue consist of 5 entries: • NavHost#A • Destination A • NavHost#B • NavHost#C • Destination C So Destination B is missing. I'd guess this is alreay wrong. But maybe the navigateUp should be able use this backQueue and properly create DestinationB. But from now on, pop is utilized so I expect this queu should be final.
Looks like a bug, I had a similar issue but it was only happening for deeplinks to me. You can try putting a breakpoint here, it might be the cause[…]ime/src/main/java/androidx/navigation/NavController.kt;l=1289
👍 1
Otherwise, I think it’s worth filing a bug if you have a minimal repro
Yes, that's a bug, being tracked in
👍 1
thanks for the link!
Hi Ian, this fix get merged, but this makes me feel unsure a bit. • the complexity of navigation code is extreme; debugging what's happening, which layers does something wrong, understanding the code is really difficult. • in the end the fix doesn't contain a unit test. simple and obvious usecase that "some inputs" get resolved to "some stack"; 😱 it puzzles me why, both possible answers scary me - the code is not easily testable due to the complexity || devs don't care. Do you have any comforting word for me? 🙂