https://kotlinlang.org logo
#compose
Title
# compose
t

Tash

02/05/2021, 9:38 PM
I apologize if this has already been asked; has anyone used Compose without an Arch Component
ViewModel
to cache state across configuration changes?
a

Adam Powell

02/05/2021, 9:43 PM
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
👆 1
💯 6
🙏 3
👍 2
t

Tash

02/05/2021, 9:46 PM
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!
And Compose can handle
savedInstanceState
, so that takes care of that. Nice.
j

Jordi Saumell

02/06/2021, 10:34 AM
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
👍 5
m

Mark Murphy

02/07/2021, 5:06 PM
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?
a

Adam Powell

02/07/2021, 6:05 PM
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
🆗 1
🙏 1
☝🏼 1
j

Jordi Saumell

02/07/2021, 10:54 PM
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…
a

Adam Powell

02/08/2021, 12:32 AM
can you post an example of the issue you're having?
j

Jordi Saumell

02/08/2021, 10:02 PM
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)
2 Views