Considering the latest tendencies towards Compose driven architecture . Would not make sesne to have some sort

remember

function that saves the state in a similar way AAC survive configuration changes? Any Google devs here know if something like this is even on the radar?

rememberSavable saves into a bundle, thats not the same, right?

You can have a singleton

rememberSaveable saves in the same way that AAC does. when you re-create the same structure, all the same automatic keys will match up.

Didn't rememberSavable required the data to be parcelable? ViewModel can handle non parcelable

rememberSaveable

stores UI element state in a

Bundle

through the saved instance state mechanism.

And we've always been told there is a limti to Bundle storage and not to sore complex data

Not just that it is a limitation but is painful to parcelize large data

yes, and that is the same for fragment state as well

AAC dont have that limation

Has always been a pain

Also AAC viewmodels are not parcelable so I doubt they are stored in bundles sorry

I'm not sure what you think survives process death, but anything which isn't parcelable doesn't

I never said process death

if you merely want to survive configuration changes then Compose already just works

🙂

One way to achieve it could be to have a holder

object

that holds your data during the configuration transition. The key is detecting when the transition is going to happen. You can place a DisposableEffect in your root composable and place your data in the holder object in the disposing lambda then recover the data when the composable starts, making the holder reference null after so it doesn't leak, it just hold it for a couple of milliseconds. Or perhaps instead of having a DisposableEffect in your root composable you can just listen for Activity lifecycle and do the same in onDestroy/onCreate

Actually something like this https://github.com/slackhq/circuit/blob/main/circuit-retained/README.md Soudns like exactly what I'd want. It'd be great if this is in Compose foundation (There might be a clear reason why is not and I might be too slow to know why 😄 )

Sounds good but without a backing ViewModel as implementation, a pure compose implementation instead. Otherwise, you keep depending on the architecture components.

Yeah but not directly, which is more than fine for my usecase. Eventually we could replicated what VM uses underhood (onGetLastCoonfig change if am not mistaken)