Hello! I have migrated to Jetpack Compose navigation and I have to say that it works pretty well. Th...

# multiplatform

[Enol Simón]

Hello! I have migrated to Jetpack Compose navigation and I have to say that it works pretty well. The only thing I am struggling is with recomposition. I have a main composable function with a navigation drawer which renders some different screens on it. My problem is when I actually try to open a new composable over it (for example to show a detail screen when I click in an element of a list.

The structure is:
NavHost 1 -> This NavHost shows the main screen or the detail screen.
• MainScreen (With navigation drawer)
◦ NavHost 2 -> This NavHost changes screens inside the Navigation Drawer
▪︎ DashboardScreen.
▪︎ ListScreen.
• DetailScreen
When I change between screens from the NavHost 2, all the screens are rendered only once (I have logs in each of the screens so I can see how many times they are rendered).

I pass as parameter NavHost1 to the different screens, so when for example I click on an element of the ListScreen, I use the NavHost1 to navigate to the DetailScreen. Then I pass the NavHost1 to the DetailScreen too, so I can navigate back.

The main problem is that when I open the DetailScreen, I see that it Is re-rendered ListScreen and then DetailScreen few times.
The same happens when I navigate back, it renders again DetailScreen and then ListScreen few times.

Anybody else is having or is aware of having the same problem? Why the screen that I am leaving is rendered again when I navigate or I navigate back to it?

Thank you in advance

[eygraber]

@Ivan Matkov this sounds similar to the issue I'm having

[Ivan Matkov]

Yep pretty similar. But that bug should not affect released versions, only "dev" ones 🤔 Since the problem is not in navigation may be that issue in compiler plugin can affect previous version too somehow

@Enol Simón please specify platform and lib/kotlin versions that you're using

cc @Oleksandr Karpovich [JB] (who working on the fix)

[Pablichjenkov]

I would expect it to refresh at least once but no more than once

[eygraber]

@Ivan Matkov I have to double check but I think I saw the issue on 2.7.0-alpha07 as well while I was testing

[Enol Simón]

The problem is in Android, compose 1.6.11, agp 8.4.2, kotlin 2.0.0, navigation 2.7.0-alpha07

[Enol Simón]

I see that also happens on iOS but both platforms has different problems though. To give a realistic number of renders:

iOS
• When i am in the list and I press in one item: DetailScreen, DetailScreen, DetailScreen, DetailScreen.
• When I press back: DetailScreen, Detail Screen, ListScreen
Android
• When i am in the list and I press in one item: DetailScreen, DetailScreen, ListScreen, DetailScreen, DetailScreen.
• When I press back: DetailScreen, List Screen, DetailScreen, ListScreen, ListScreen

[eygraber]

False alarm: not happening for me on 2.7.0-alpha07 😅

[Ivan Matkov]

Android

On android it's original Google's binary, so it's better to file issue not to multiplatform - it's not the change in JB fork

[Enol Simón]

But it happens in both platforms, I have it implemented in the common code. It is very strange because it happens in both, but the extra renders are different in both platforms, as I wrote in my previous comment.

Something that I would like to point, I changed the code to pass lambdas instead the NavHost, and it recomposes anyway.

And I am not handling any other state, so I am sure that the renders are provoked by the navigation because if I don't pass this argument, it doesn't recompose.

I could prepare a minimum example on github if it is useful for you guys.

[Ivan Matkov]

But it happens in both platforms

It means that it's not the change during multiplatform adoption

I could prepare a minimum example on github if it is useful for you guys.

Yep, thanks. If the issue is about difference between Multiplatform and original Android - CMP GitHub is the right place. If the problem happens on Android - it's better to open an issue to Google's issue tracker (should be reproducible without multiplatform setup)

I know it's sounds not supper clear, but initial implementation owned by Google and our fork is handling only multiplatform adaptation. Changes in the fork will NOT affect Android anyhow