Does using rememberSavedInstanceState always inste...

# compose

[Shakil Karim]

Does using rememberSavedInstanceState always instead of remeber has any drawback?
val list = rememberSavedInstanceState { mutableListOf<Int>() }

[Dominaezzz]

Less drawback, more different behaviour. Just depends on how long you want the state to live for.

[Andrey Kulikov]

also you can use it only with types which are supported by Android Bundle class or you have to provide a custom Saver object

[Kshitij Patil]

I also tend to use it for all the TextFieldValue states, does this sound bad practice?

[Adam Powell]

You have a limited amount of space available for your entire app to share in savedInstanceState, and it doesn't survive a reboot or activity finish, such as when the user swipes your app away

[Adam Powell]

It's good for things like scroll position and navigation location within the app, but anything beyond the most basic draft of user data where it doesn't matter if it gets lost should be persisted to disk. (File, sqlite, room, sqldelight, etc.)

[Kshitij Patil]

No, I've many form inputs involved in app and I want to persist the TextField state even if user puts app in background and repoens the same. Is this ideal use case to use savedInstanceState ?

[Shakil Karim]

Yes, I think it's a valid use-case, previously editText does that by default.

[Adam Powell]

If the user presses the back button on your form screen, do you want to save the user's draft or should it be discarded? savedInstanceState discards it.