Is there any need to allow Android to destroy and ...

# compose-android

[MarkRS]

Is there any need to allow Android to destroy and recreate the activity in a single activity compose setup?
Preventing it with the configChanges option in the manifest seems to work just fine. Compose rebuilds the screen correctly when, for example, the orientation changes.
What are the downsides to this?

[Sergey Y.]

I believe Ian Lake answered this somewhere. If I remember correctly, you can override about 95% of configuration changes, and Compose will gracefully handle resource updates for you. However, you’re still obligated to handle saving and restoring data in the remaining 5%, as it’s crucial for the user experience.
The Activity may (and likely will) be recreated to conserve system resources when the user moves your app to the background, for example, when they take an incoming call or open the gallery/camera, handle runtime permissions, etc.

[KamilH]

I think there is a wallpaper-change related configuration change that can't be disabled, which doesn't seem like a common use case, but shows that we can't trust it 100%.
The use case Serhii mentioned (with limited resources) sounds more like a "process death" to me than activity recreation. The latter can be handled by using the ViewModel (or any other retained object) while for handling the former you need to persist your state using either Bundle (SavedStateHandle) or disc (file, database or whatever).
In the Compose world you should simply use rememberSaveable

[MarkRS]

Thanks @Sergey Y. How to save data without a ViewModel?
I've been avoiding ViewModels since according to Vasiliy Zukanov and (apparently) @jw, they're unnecessary, but I wonder if this is the step that means they're required.
@KamilH, the config setting is triggered for specific events, I've just picked orientation and locale changes. Does the wallpaper change trigger either of those I wonder. It's probably a rare enough thing that I don't really care (?)

[eygraber]

Activity recreation - your Activity is restarted for whatever reason, ViewModel or saved state will help

Process death - your process is killed in the background, saved state will help

I usually just use saved state because it covers both cases. In the rare instance where the data can't go into saved state I use a ViewModel, but I try to avoid that whenever possible.

An alternative to a ViewModel would be any object that outlives the Activity, although you'd lose the ability to scope data to that Activity, unless you build that, in which case just use ViewModel

[KamilH]

I don’t like ViewModel either, but in some use cases it’s useful. For example, your long-running operation can survive the configuration change. If we agree that we don’t really care about those rare configuration changes you can’t disable, then it’s fine to use “your” object with saved state injected to persist the user’s input, for example. As Eliezer mentioned, the “saved state” covers both process death and Activity recreation in terms of data.
There are also other solutions that allow you to survive configuration changes without the need for the ViewModel ceremony. For example, the Circuit framework provides the `rememberRetained`:
https://slackhq.github.io/circuit/api/0.x/circuit-retained/com.slack.circuit.retained/remember-retained.html
There is also a separate library with similar functionality built by Google’s employer:
https://github.com/marcellogalhardo/retained
Both of them use the ViewModel under the hood, but you don’t need to deal with it directly. In my opinion, it’s like it should have been implemented from scratch. So simple retain(owner) { ... } function without the viewModelScope, : ViewModel() etc.

[jw]

You're basically forced to use view models for that because Google locked down the actual framework mechanism (retained instance) without providing a general purpose mechanism on which view models and other things could be built.

[eygraber]

There's always a singleton and a Map 🙃

[jw]

If you look at the commit history of the framework I managed to sneak a reusable mechanism in during my last week but then we reverted it with a plan to make it AndroidX only but I had already left and no one else hates view models enough (like me) to do it

[eygraber]

That's a shame. I went my entire career without having to use a ViewModel until this year when I needed it to persist paging3 state between composables. What a terrible experience.

[ephemient]

so basically somebody needs to https://twitter.com/swaglord__420/status/1377051721655066629 android badvice

[eygraber]

1751831375106.png