I apologize if this has already been asked; has an...

# compose

[Tash]

I apologize if this has already been asked; has anyone used Compose without an Arch Component ViewModel to cache state across configuration changes?

[Adam Powell]

It's probably the easiest way to do it if you have a mixed Compose+Views app. If you have a Compose-only app you can skip ViewModel entirely and just declare all config changes as handled for that activity in your manifest. Compose can handle those configuration changes without the activity restart at all

[Tash]

Nice! Good to know. Working on a Compose-only app, but started out using an AAC ViewModel. Will be interesting to get rid of that. Thank you!

[Tash]

And Compose can handle savedInstanceState , so that takes care of that. Nice.

[Jordi Saumell]

I wrote about this here, although it did not attract a lot of attention. I’m about to release a sample with my approach to handling several things without AAC VM

[Mark Murphy]

just declare all config changes as handled for that activity in your manifest

I'm a bit nervous about this advice.

android:configChanges would need to be reviewed with each Android release, as new configuration change types show up from time to time. IOW, there is no way to create a future-proof android:configChanges value. Is there some trick to this that I missed along the way?

Also, is there anything in CTS that prevents a device manufacturer from adding some new sort of configuration change? Particularly an undocumented one?

[Adam Powell]

No trick. In the event that you do get a config change activity recreation, it'll be just as if you were restoring from saved instance state after a process death. Generally not a big deal, presuming you don't make a habit of scoping sources of truth for things to viewModelScope, which imo is a pretty bad idea whether you're working with compose or not

[Jordi Saumell]

Regarding saving state, something I had not thought about is how to save state for app wide data (what would typically be stored in a SharedViewModel). With process death my activity saveInstanceState is not being called and I haven’t found a way of getting a savedStateHandle without a ViewModel or a navEntry. For my screens I get a savedStateHandle from navEntry and it does save the state, the problem is in the activity…

[Adam Powell]

can you post an example of the issue you're having?

[Jordi Saumell]

I attach a minimum repro project. What I do is open the app, go home, press the stop button in AS (force process death), open the app again. And the result is that what I try to save with activity’s onSaveInstanceState is not saved, whereas what I save with a savedStateHandle (obtained with the navEntry of the navComponent) is saved and restored properly. Maybe I am doing something wrong (it’s been a while since I last used onSaveInstanceState) but I can’t see what, as it is supposed to be quite simple.
So:
• Why does onSaveInstanceState not work while savedStateHandle works?
• How do I fix it and/or how can I retrieve a savedStateHandle in the activity without a viewModel? (I want to persist data which is not bound to a screen, but to the whole activity)