https://kotlinlang.org logo
Title
y

ynsok

04/12/2022, 8:51 AM
Hi, I’m developing an application targeting desktop and android using compose multiplatform. I’ve started facing problems with android process death because all my states are lost for obvious reasons. I’ve checked that for android there is used SavedStateHandle to cover this case. But In my situation, I can’t use it because I need a multiplatform solution. Any idea how to solve this problem?
b

Big Chungus

04/12/2022, 9:20 AM
Expect/actual with mock implementation on desktop
y

ynsok

04/12/2022, 9:53 AM
Am I correct, if I want to use SavedStateHandle I need also to use SavedStateViewModelFactory in implementation? if yes, then also I need to use android ViewModel.
g

Grégory Lureau

04/12/2022, 9:55 AM
expect/actual the ViewModel too?
y

ynsok

04/12/2022, 11:16 AM
I think yes, this solution can be good for projects that already have an android ViewModel wrapper around a pure kotlin ViewModel. Currently, I’m thinking about saving state in the key-value store, don’t see other solutions
g

Grégory Lureau

04/12/2022, 2:09 PM
You may also be interested by libs that handle this kind of needs (like Decompose for example)
a

Adam Powell

04/12/2022, 2:18 PM
rememberSaveable
and the associated family of APIs are already mpp configured
l

Landry Norris

04/12/2022, 3:06 PM
I remember seeing an issue on compose-jb saying that rememberSaveable doesn’t work properly on desktop at the moment. I think it works on Android since compose-jb seems to just reference compose on Android. https://github.com/JetBrains/compose-jb/issues/1932
z

Zach Klippenstein (he/him) [MOD]

04/14/2022, 4:41 PM
I am guessing that there’s no built-in integration with every desktop OS’s state saving mechanism, because it’s probably not clear what that would even mean. Desktop apps aren’t arbitrarily killed by the OS in most cases, so state saving is much more deliberate in many cases (e.g. explicitly saving to a file). I could imagine that Compose for Desktop might want to support something like macOS’s “reopen windows” at some point, which I would imagine probably has some sort of state-saving API, but even then it might be more appropriate for an app to be explicit about how it wants to support that feature. You can always write your own
<https://developer.android.com/reference/kotlin/androidx/compose/runtime/saveable/SaveableStateRegistry|SaveableStateRegistry>
implementation that saves to a file or something.
a

Adam Powell

04/14/2022, 5:59 PM
it can be useful even for live process situations in navigation components, since it's a much smaller representation of selected UI state to keep around for things on your back stack that aren't visible
z

Zach Klippenstein (he/him) [MOD]

04/14/2022, 6:06 PM
Right, but for navigation stuff (using
SaveableStateHolder
) there's no serialization and the restoration is already implemented purely in memory, so I would expect that to already Just Work for desktop. If that's not the case, it sounds like a bug.
a

Adam Powell

04/14/2022, 6:10 PM
right. The github issue above seems to expect that
rememberSaveable
remembers state across conceptual task close operations, which is generally part of what closing a desktop app process means, but that's not the API contract of
rememberSaveable
one could see it as a sort of session state
close the window/app and you've closed the session so there's nothing to save. In a navigation scenario though, you're still in the same session, ditto Android restored state when you return to a task but the underlying process was killed. It's like you're continuing the same session but talking to a different frontend server than you started with
👍🏻 1