Those of you using sealed classes to wrap state, how are you persisting them? (e.g. onSaveInstanceS...

# android

[tenprint]

Those of you using sealed classes to wrap state, how are you persisting them? (e.g. onSaveInstanceState/onRestoreInstanceState) @alostpacket

[ghedeon]

imho, ViewModel is supposed to keep it between configuration changes and stuff. For longer periods I'd consider pushing the state down to Repository.. Can't think of a proper onSaveInstanceState use case.

[tenprint]

I have something like

sealed class ViewState {
  useCase1(val useCase1Data) ...
  useCase2(val useCase2Data)...
  [etc]
}

Keeping that in ViewModel. Then activity displays different things depending on which ViewState

However when user backgrounds app, Activity+ViewModel are getting killed

[tenprint]

And ViewState comes back null when activity is restored

[ghedeon]

a few things here. Activity is not necessarily killed when the app is in the background. Most of the times, if user comes back soon, the viewmodel should still have the value.
Second, if the activity and viewmodel is actually killed, then coming back shouldn't be different from the fresh start. Basically, just reload your data, like it's a first start of the activity. It's a totally normal flow and later you can think of possible measures to reduce delays, like disk/memory cache, etc.

[tapchicoma]

your state can implement Parcelable with @Parcelize kotlin android extension, so it is easy to save/restore using Bundle in onSaveInstanceState()

[tenprint]

@tapchicoma That feature is experimental. Are people using it safely in production?

[tapchicoma]

yes, it is pretty stable