Architectural smell aside, what are the technical ...

# compose-android

[Travis Griggs]

Architectural smell aside, what are the technical downsides of doing something like:

object Forever {
    var characterCount by mutableIntStateOf(20)
    val text by derivedStateOf {
       "It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness.".take(
          characterCount
       )
    }
    var textSize by mutableIntStateOf(21)
    var lowerSize by mutableIntStateOf(14)
}

at the "root" of one's MainActivity file (I know this is bad coding and all that, I'm interested on what (if anything) breaks when you do this)

[Stylianos Gakis]

The answer is most likely that you simply don't really have a good reason to do this in the first place.

A follow up answer would be that now since you didn't make a nice state holder class with a Saver implementation, you got no way to have your state survive configuration changes

[Travis Griggs]

but it will survive config changes. where i understand "config changes" mean "rotate the device" and see that a new Activity and all of the compositions get redone. That's the point.

[Travis Griggs]

I was taking this line in the Application documentation at face value:

"In most situations, static singletons can provide the same functionality in a more modular way."

[Travis Griggs]

to clarify, I paced this outside of my MainActivity class

[Michael Paus]

@Stylianos Gakis Have you recently created a new project via the Jetbrains Wizard? If you look into the generated Mainifest you will notice this line:

android:configChanges="orientation|screenSize|screenLayout|keyboardHidden|mnc|colorMode|density|fontScale|fontWeightAdjustment|keyboard|layoutDirection|locale|mcc|navigation|smallestScreenSize|touchscreen|uiMode"

You will see that all relevant config change resets are disabled because Compose deals with them. So why are people constantly overcomplicating things and argument with things that are not really relevant anymore? (I am not talking about old legacy apps here.)

You could even create a main Application class in addition to the Activity and place the singleton there. That Application class would even survive the reset of all Activities. See: https://guides.codepath.com/android/Understanding-the-Android-Application-Class I don’t say one should do that but why not? The argument brought forward agains such an approach should at least be valid.

[shikasd]

fwiw, I don't think anything is going to break if you do this and use those states in composition, as snapshots guarantee consistency regardless of the change.
measure/layout/draw might be a bit more broken though if you mutate it from a different thread, so you might want to use Snapshot.withMutableSnapshot to ensure state changes are mutated atomically.

[Travis Griggs]

@Michael Paus thanx for that. It's kind of what i've been wondering. there's all this ceremony around some of these legacy layers. I'm relatively new to taking responsibility for writing an Android app at our place; but I've watched a former colleague wrestle with this for a few years before that. First it was just Activitities and Intents. And then there were Fragments. And ViewBindings. Then DataBindings. And ViewModels. And now compose. It feels a bit like christianity, with this weird amalgamation of tradition and and ritual combined with theology that people pick and choose from (no offense meant to any christians, i myself do a flavor thereof). So I've been taking a very "do I really need this?" to each piece, and enjoying a more minimalist approach where possible.

[Mark]

@Michael Paus I noticed neither the NIA, nor Sunflower apps do that (regarding configChanges). And they are fully compose.

[Colton Idle]

Technically even if you override all available configChanges you can still get a configuration change due to wallpaper changes

[Colton Idle]

but im mostly just mentioning that for completeness. in most cases. im assuming its fine to just disregard that. but 🤷

[Stylianos Gakis]

Wallpaper config changes is one. Process death is actually an even more important one, which is what I should've written instead tbh.

But with that said, @Michael Paus trust me I've tried to add all config changes to my manifest and every time I do that a new bug pops up and I end up regretting it.
This https://issuetracker.google.com/issues/321896385 is the latest one that I encountered where I had to get rid of the "locale" one as well. There were more in the past, don't have a link at hand but yeah. That solution is so enticing, but it's not stable yet. Which is also why this suggestion is nowhere to be found in the official android documentation. Only Jetbrains and people in this slack channel are proposing it.

[dorche]

One more example (thread says it's a Google bug) https://github.com/raamcosta/compose-destinations/issues/566

[Stylianos Gakis]

Don't get me started with m3 bottom sheets and them doing all the wrong things on rotation when you got the manifest setup in that way 😂 this is just one of the filed bugs: https://issuetracker.google.com/issues/292204649
It's hell

[dorche]

Absolutely, imo the ModalBottomSheet*Layout* is one of the worst things in Compose atm

[Colton Idle]

i too am saddened with modal bottom sheet. I still just use https://github.com/oleksandrbalan/modalsheet shoutout to @Oleksandr Balan for always keeping it updated

[Oleksandr Balan]

Keeping it updated

Last release 17 Aug 2023

homer disappear 😅

[Colton Idle]

well it works for me and anytime theres a breaking issue you seem to fix it. lol