A modern programming language that makes developers happier.

kotlinlang

Quick theoretical Compose question, ladies and gents. What situations would you ever use `remember{ mutableStateOf()}` _instead of_ `rememberSaveable{ mutableStateOf()}`? If you get saving across configuration and process death with the latter, why ever use the former?

That's quite an interesting question. It's been bothering me a bit so looking forward to an answer.

You should use `rememberSaveable` whenever you want the value to survive process death but there definitely some situations where you don't need this. Besides, large objects can't be store in the bundle anyway.

By the way, consider letting Compose handle all the configuration changes.
<https://kotlinlang.slack.com/archives/CJLTWPH7S/p1618760507089400?thread_ts=1618691113.058800&amp;cid=CJLTWPH7S>

For sure, if you had a large set of data you might need to `remember` it instead and perhaps have your ViewModel use a SaveStateHandler to get certain properties perhaps

Also, `remember` is good for caching results of expensive operations. Not sure why `rememberSaveable` wouldn't be in the same situation, but perhaps there is a reason given the size constraints for a Bundle

&gt;  If you get saving across configuration and process death with the latter, why ever use the former?
Besides the size issue, bear in mind that not everything can be saved. You cannot save a socket across process termination, for example. The "saveable" data has to be something that can passed across process boundaries.

We have been dealing with "what can we put in the saved instance state `Bundle`" concerns for ~13 years. This is just Compose's API on top of that.

Also, I don't know if `rememberSaveable()` works on Compose for Desktop, as there is no saved instance state `Bundle` outside of Android. Perhaps it falls back to behaving like normal `remember()` on other platforms -- I have not tried it on Compose for Desktop yet.