Long shot, but after updating (Compose Compiler `1...
# compose
m
Long shot, but after updating (Compose Compiler
1.1.0-beta03
, Kotlin
1.5.31
) to (Compose Compiler
1.1.0-beta04
, Kotlin
1.6.0
) I am having a weird issue where after navigating back to a Fragment the Fragment's UI (View-based, not Compose) is no longer responsive. Single-activity app with navigation component, issue appears with any View-based Fragment after navigating back to it (fine on Compose Fragments). I am having a hard time debugging this, or seeing why would updating the Compose Compiler affect non-Compose Fragments, did anyone see a similar issue?
b
I think I have the same exact issue, reported here. Confirmed by downgrading compose compiler to
1.1.0-beta03
and kotlin to
1.5.31
(I was on
1.2.0-beta01
before). It's working as expected on
1.1.0-beta03
and this weird behavior starts happening with
1.1.0-beta04
We need to find a simple reproducible example..
I'm glad I saw your report here, this has been bugging me since Friday 😄
m
I'm seeing exactly the same behavior as in your message: all code seemingly works, breakpoints are hit, but UI is as if inflated with no code ran. I have now removed all of Compose from my app, and confirmed the issue appears only due to adding
buildFeatures { compose true }
, even with no Compose usage whatsoever.
b
@Ian Lake Do you have any suggestions on how to debug this?
a
Check your resolved library dependency versions with Gradle before and after to see if you've pulled along any other library version updates, that'll give a place to start from
b
I ran
./gradlew app:dependencies
before and after changing
1.1.0-beta03
to
beta04
+ kotlin version, but it doesn't seem to give any useful info. Here's the diff: https://pastebin.com/FcRjPa5V
m
Just updating Kotlin to 1.6.0 does not trigger the bug, but toggling on
buildFeatures { compose true }
does. There is nothing to diff in that case: just enabling the compose build feature triggers the bug.
I found the problem, the bug happens only on screens that use Kotlin synthetics for views. Once I removed Kotlin synthetics and replaced them with
findViewById
the bug is gone. Of course this doesn't answer why it happens, but it seems the Compose Compiler breaks something in Kotlin synthetics for views. High time to migrate away I guess, although they were supposed to work until Kotlin 1.8, and I was hoping to skip View Binding and migrate straight to Compose by the time Kotlin 1.8 comes out. @Berkeli Alashov Can you confirm the issue is gone for you if you remove Kotlin synthetics from an affected Fragment/screen?
🎉 2
b
I see usages of kotlin synthetics in affected fragments, but it would take too much time to migrate rn. I'm going to try add kotlin synthetics where we're using view binding (simpler to migrate since smaller screen) to see if it breaks.
m
I tried it with a simpler Fragment, where putting some `findViewById`s instead was quick to test.
It will be quite time consuming for me to migrate 30+ screens from synthetics to View Binding but I don't see another option now.
b
Can confirm, kotlin synthetics + compose compiler 1.1.0-beta04 + kotlin 1.6.0 causes this bug. Tested by adding kotlin synth to unaffected screen. Migrating that many screens rn isn't an option for me either (found 86 files using using
kotlinx.android.synthetic
..) I guess now we can create reproducible example & report the bug.
m
Are you sure about these versions? On 1.1.0-beta03 it's fine for me. Bug appears from 1.1.0-beta04.
b
my bad.. I meant 1.1.0-beta04 and 1.6.0 (fixed now)
👍 1
Created reproducible example/demo here: https://github.com/alashow/MultipleBackStackNavComponent @Marcin Wisniowski Could you create an issue with this demo? (I can do it tomorrow if you have not)
m
Thanks for raising it, I was away. I just finished migrating 30+ screens from synthethics to View Binding so that it doesn't affect me anymore. Not fun.
b
Seems like we will have to migrate too.. https://kotlinlang.slack.com/archives/CJLTWPH7S/p1653687605042499 What part of the migration wasn’t fun? Hopefully it’s just bulk renames of variables from
myView
to
binding.myView
m
In theory, yes, but there is a lot of it, and there are complications in custom Views and RecyclerView adapters. Nothing problematic but just tedious.