https://kotlinlang.org logo
Title
m

Marco Pierucci

05/09/2023, 11:10 PM
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?
e

ephemient

05/09/2023, 11:15 PM
m

Marco Pierucci

05/09/2023, 11:17 PM
rememberSavable saves into a bundle, thats not the same, right?
p

Pablichjenkov

05/09/2023, 11:19 PM
You can have a singleton
e

ephemient

05/09/2023, 11:21 PM
rememberSaveable saves in the same way that AAC does. when you re-create the same structure, all the same automatic keys will match up.
p

Pablichjenkov

05/09/2023, 11:23 PM
Didn't rememberSavable required the data to be parcelable? ViewModel can handle non parcelable
m

Marco Pierucci

05/09/2023, 11:24 PM
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
p

Pablichjenkov

05/09/2023, 11:24 PM
Not just that it is a limitation but is painful to parcelize large data
e

ephemient

05/09/2023, 11:25 PM
yes, and that is the same for fragment state as well
m

Marco Pierucci

05/09/2023, 11:25 PM
AAC dont have that limation
unless
getLastNonConfigurationInstance()
with that as well ( which in that case I learnt something. new today)
p

Pablichjenkov

05/09/2023, 11:26 PM
Has always been a pain
m

Marco Pierucci

05/09/2023, 11:27 PM
Also AAC viewmodels are not parcelable so I doubt they are stored in bundles sorry
e

ephemient

05/09/2023, 11:29 PM
I'm not sure what you think survives process death, but anything which isn't parcelable doesn't
m

Marco Pierucci

05/09/2023, 11:29 PM
I never said process death
you can check my initial message
I said configuration changes
e

ephemient

05/09/2023, 11:29 PM
if you merely want to survive configuration changes then Compose already just works
m

Marco Pierucci

05/09/2023, 11:29 PM
🙂
if you merely want to survive configuration changes then Compose already just works
Thats not the case, at least not by default, you need to disable all configuration changes on your activity for that to be the case. And there are changes that cant be disabled
p

Pablichjenkov

05/10/2023, 12:28 AM
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
m

Marco Pierucci

05/10/2023, 11:44 AM
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 😄 )
p

Pablichjenkov

05/10/2023, 12:27 PM
Sounds good but without a backing ViewModel as implementation, a pure compose implementation instead. Otherwise, you keep depending on the architecture components.
m

Marco Pierucci

05/10/2023, 4:58 PM
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)