Compose Navigation Let's have A -> B -> C -&...

# compose

[Jan Skrasek]

Compose Navigation
Let's have A -> B -> C -> D nested navigation. Something like

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.

[Jan Skrasek]

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.

[allan.conda]

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
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigati[…]ime/src/main/java/androidx/navigation/NavController.kt;l=1289

[allan.conda]

Otherwise, I think it’s worth filing a bug if you have a minimal repro

[Ian Lake]

Yes, that's a bug, being tracked in https://issuetracker.google.com/issues/214383060

[Jan Skrasek]

thanks for the link!

[Jan Skrasek]

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? 🙂