Status Update
No update yet.
Comments
jb...@google.com
cl...@google.com
On first blush, this doesn't appear to be related to my current changes, as this is an error in the recomopser not the composer. However, the fact it requires an inline function seems suspiciously close.
ap...@google.com
The issue appears to be that, starting in 1.4.3, the composer used in the inlined lambda is the one captured from the parent. This is not the right one when a dialog is being presented as it is the composer for the dialog, not the dialog host.
ap...@google.com
ap...@google.com
Note to Andrei: After the aosp/2423347, the cross-inline lambda is capturing the $composer parameter from the caller instead of using the $composer parameter passed in to the lambda it was inlined into. This causes changes to be made to the composer that is not currently being used for composition which confused the recomposer.
cl...@google.com
ap...@google.com
This issue affects crossinline lambdas that are inlined into another lambda, as demonstrated by the repro case above, when the composable lambda is executed with a different composer than the function declaring the lambda. A different composer is used when a lambda is invoked in a subcomposition such as a dialog, BoxWithConstraints, and LazyColumn, amoung others.
A crossinline lambda is requred because it is illegal to invoke an non-crossinline lambda in a realized lambda (which is what crossinline allows).
The easiest work-around is to remove inline from the function which avoids the expanding of the lambda in another lambda required for this bug to manifest.
jb...@google.com
Thank you for the elaboration! The non-inline workaround is what I've been using since this code broke.
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
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