I have a question concerning Compose Multiplatform...
# compose
m
I have a question concerning Compose Multiplatform's default setup in the
AndroidManifest.xml
.
Copy code
<activity
  android:exported="true"  android:configChanges="orientation|screenSize|screenLayout|keyboardHidden|mnc|colorMode|density|fontScale|fontWeightAdjustment|keyboard|layoutDirection|locale|mcc|navigation|smallestScreenSize|touchscreen|uiMode"
  android:name=".MainActivity"
>
Why is the activity given the responsibility of handling all possible config changes? I've grown accustomed to handling config changes in all my years of Android development so I'm curious about the possible drawbacks of this approach, especially regarding fetching/updating resources (strings, drawables, etc). Is there something unique about Compose Multiplatform (compared to the usual Android development) that allows this approach work well?
m
Compose is supposed to handle these changes for you automatically. So, you don’t have to care anymore.
m
Thank you, so if I were building a new modern Android application, using Jetpack Compose, single activity and no xml layouts, would this still be acceptable?
m
Actually it only works automatically in this way in a pure Compose application.
m
That makes sense. Thanks again. I'm guessing the example I mentioned wouldn't count as a "pure Compose application"
s
Be careful though, there are still things that will silently fail to work which you would not expect. I got this https://issuetracker.google.com/issues/321896385 and this https://issuetracker.google.com/issues/292204649 just from a quick search, but I’ve definitely had to remove entries from the list of
configChanges
before because it introduced problems. And all this has been in a pure compose app.
m
I am talking about how Compose is designed and how it is supposed to work. Of course there may be and actually are bugs which deviate from the expected behaviour but hopefully these bugs will be fixed soon.
s
The ideal world sounds nice, but I would absolutely not recommend doing this in a real app yet.
c
i currently do this in one of my apps, but still test state restoration and config changes and that list doesn't cover all config changes
m
The current list is
Copy code
android:configChanges="orientation|screenSize|screenLayout|keyboardHidden|mnc|colorMode|density|fontScale|fontWeightAdjustment|keyboard|layoutDirection|locale|mcc|navigation|smallestScreenSize|touchscreen|uiMode"
which you get automatically when you create a new project with the Compose Multiplatform Wizard.
s
My concerns are not even about missing one of them or that state restoration doesn't work. It is as I said above that this starts introducing subtle bugs in your codebase that you are most likely will miss