Status Update
Comments
jb...@google.com <jb...@google.com>
cl...@google.com <cl...@google.com> #2
Could you please provide a minimal sample that reproduces this issue?
ap...@google.com <ap...@google.com> #3
Yes, of course
@Composable
private fun DemoNavHost() {
val controller = rememberNavController()
NavHost(
navController = controller,
startDestination = "mainRoute",
modifier = Modifier.fillMaxSize()
) {
composable("mainRoute") {
Surface() {
Box(Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
Button(
onClick = {
controller.navigate("demoDialog")
controller.navigate("demoDialog") // Simulate a quick click by the user
}
) {
Text(text = "show dialog")
}
}
}
}
dialog("demoDialog") {
val context = LocalContext.current
val lifecycle = LocalLifecycleOwner.current
Surface() {
Column() {
Text(text = "I'm demo dialog")
Button(
onClick = {
Toast
.makeText(
context,
"${lifecycle.lifecycle.currentState}",
Toast.LENGTH_SHORT
)
.show()
}
) {
Text(text = "check lifecycle")
}
Button(onClick = controller::popBackStack) {
Text(text = "close")
}
}
}
}
}
}
Steps:
Step 1: Click the show dialog
button on mainRoute
Step 2: Because 2 pop-up windows pop up, we close the top one
Step 3: Click the check lifecycle
button on the pop-up window, you can see STARTED
instead of RESUMED
I have also checked the cause, which is consistent with the description in my question.
ap...@google.com <ap...@google.com> #4
In fact, I found another problem. When the tester frequently clicks the button, the button event is to display a Dialog
, Dialog
is set to be destroyed by external click, so Dialog
is always displayed and destroyed
Interesting thing, because it may be too fast, causing DialogHost
to not notice that Dialog
appears and disappears, but it has actually joined NavController#_visibleEntries
But because NavHost#DialogHost
did not process DisposableEffect
, it will not execute dialogNavigator#onTransitionComplete
, so it will not be removed from NavController#_visibleEntries
, and a NavBackStackEntry
leak occurs
The reason may be that the pop-up window appears and disappears within one frame
ap...@google.com <ap...@google.com> #5
Hi, can you please file a separate bug for the issue you see in
On initial bug - when multiple dialogs are open at the same time and the top one is dismissed, the second dialog in backstack is marked as transitioning to hold it in STARTED state until the top dialog has completed transitioning. But the second dialog was not marked as complete when composed so it stays in STARTED state instead of moving to expected RESUMED state.
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #6
Thank you for your answer, I will open a separate post to ask a separate question;
jb...@google.com <jb...@google.com> #7
Thanks for filing the new bug! I was thinking a separate bug for the issue you see in commment#4 with NavBackStackEntry
possibly leaking. I'm gonna update the new bug's description to match that.
Description
Component used: Navigation
Version used: Latest snapshot
Devices/Android versions reproduced on: Any
This bug report is to track the discussion that has started over at https://issuetracker.google.com/issues/358137294#comment6
The problem is that in minified builds, even though navigation now has support for enum classes, kotlinx.serialization at that point knows the name of the class before it was obfuscated by r8, and the navigation library is trying to find it by using the obfuscated name. That's my understanding of the issue.
The real effect this has when using the type-safe apis is that one is simply not able to have enums inside their serializable type-safe destinations.
The one workaround which works is to annotate the enum class with
@androidx.annotation.Keep
, however this is not mentioned anywhere, there is no compile-time warning for it, nor any lint which could help.I am reporting this here with the hopes that there can be some improvement in this area. Optimally this should "just work", even in minified builds, but if that turns out to be infeasible, perhaps some lint could help us out. And if that is infeasible too, perhaps a special error message at compile time could inform the user that they should use this annotation, or whatever other solution may be considered best.
There is a repro project herehttps://github.com/StylianosGakis/navigation-predictive-back-breaking-shared-element/tree/b401ce64c0d2b48585d92f96f626b970fb01bb4a which as seen here https://issuetracker.google.com/issues/358137294#comment9 shows this crash happening.