Thread by @theapache64

X: I know what is `remember`, but what is `rememberSaveable`? How are they different? 🤷🏼

Y: Well, as you know, `remember` is to survive your value during recomposition...

#compose #thread_ahead 🧵 ⬇️

...`rememberSaveable` is to survive the value during both recomposition and activity recreation

X: Ahm...Okay, how do I use it? 🤔
Y: Let's look at the method's signature first.👀

X: What is that `inputs`? and Why is it `vararg`?🤷🏼

Y: `inputs` are something that we give to `rememberSaveable` to tell something like, "Hey, if any of the inputs are changed during recomposition, ...

... I want you to invalidate the old value (if exists), and create a new instance of the object by calling the `init` block I passed"

X: Okay, that's nice. Tell me about the `saver`? 🤨

Y: By default, `rememberSaveable`, can only save values that can live inside a Bundle. Such as Int, String, Parcelable, Serializable, etc. It doesn't know how to serialize/deserialize your "custom" object.

So, to do that, we need to teach how it can save/restore a custom object/class. That's the purpose of Saver. It provides two callbacks. One to save the object, and another one to restore the object.

Very similar to Room's @TypeConverter, but different syntax.

X: Cool. Is there any real-world example I can look into? 😮
Y: Sure. The `navigation-compose` library uses this technique to restore the `navController`'s state during activity recreation.

Source: cs.android.com/androidx/platf…

NOTE: If you think any of the above points are incorrect, please correct me. Also, you're free to hijack this thread if I missed anything about `rememberSaveable` 😉