Hi, I’m developing an application targeting desktop and android using compose multiplatform. I’ve st...

# compose-desktop

[ynsok]

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?

[Big Chungus]

Expect/actual with mock implementation on desktop

[ynsok]

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.

[Grégory Lureau]

expect/actual the ViewModel too?

[ynsok]

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

[Grégory Lureau]

You may also be interested by libs that handle this kind of needs (like Decompose for example)

[Adam Powell]

rememberSaveable and the associated family of APIs are already mpp configured

[Landry Norris]

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

[Zach Klippenstein (he/him) [MOD]]

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.

[Adam Powell]

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

[Zach Klippenstein (he/him) [MOD]]

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.

[Adam Powell]

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

[Adam Powell]

one could see it as a sort of session state

[Adam Powell]

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

[Trejkaz]

I experimented a bit with SaveableStateHolder , it did seem to trigger a call to save() on my saver at least, but only once, and it was never clear how to get it to call it again, and I also never saw it call restore()

[Trejkaz]

replacing LocalSaveableStateRegistry really seemed to be the viable workaround but it was a bit too much work for me at the time. trying to write apps, not implement large portions of the app framework 😞

[Trejkaz]

I will most likely just do my important app state the same way I do it in Swing, calling out to Preferences