The New Retain API in Jetpack Compose - Everything You Need to Know

Summary

In this video, the speaker introduces Google's new Retain API for Jetpack Compose, highlighting its benefits in managing state during configuration changes. While solutions like `remember` and `remember savable` can persist state across recompositions or rotations, the Retain API offers a more flexible approach, allowing non-serializable states, such as large objects or instances like ExoPlayer, to survive across configuration changes. The video also discusses the trade-offs between using the Retain API and traditional solutions like ViewModels, with the former being a simpler, quick solution while ViewModels offer more structure for larger apps.

Takeaways

• 😀 The new Retain API in Jetpack Compose allows developers to retain composable states across configuration changes without needing to serialize them.
• 😀 Configuration changes in Android, such as device rotations or theme changes, can cause the composables to reset, losing their state.
• 😀 While `remember` helps retain state across recompositions, it doesn’t persist across configuration changes. `rememberSavable` addresses this by serializing and saving state.
• 😀 `rememberSavable` works well for saving small objects but isn’t recommended for large objects like bitmaps, as they can be difficult to serialize and may consume too much memory.
• 😀 The Retain API provides a solution for retaining non-serializable objects like ExoPlayer instances across configuration changes, unlike `rememberSavable` which requires serializability.
• 😀 Unlike `rememberSavable`, the Retain API allows the retention of state in composables without the need for serialization, making it more flexible for certain use cases.
• 😀 The `retain` function works with a composition local and can be customized using a lifecycle-aware value store to manage how state is saved and restored.
• 😀 The `RetainedEffect` composable is similar to `DisposableEffect`, but it only triggers cleanup when the composable is permanently removed (not during a configuration change).
• 😀 While ViewModels have traditionally been used to persist state across configuration changes, the Retain API offers a new, composable-centric approach to state management.
• 😀 The Retain API is suitable for use in libraries where you may need to retain state without coupling it to a ViewModel or activity lifecycle. For most production apps, however, ViewModels are still recommended for better structure and testability.

Q & A

What is the main issue discussed in the video related to Jetpack Compose?

The main issue discussed is that when an Android device undergoes a configuration change, such as screen rotation, the state of the composable (like an image picker) is lost because the activity is recreated. This leads to the loss of previously selected data, like an image.

How does `remember` function in Jetpack Compose, and what limitation does it have?

`remember` retains the state during recompositions but does not persist across configuration changes like screen rotation. The state will be lost if the activity is recreated due to a change in configuration.

What does `rememberSavable` do differently from `remember`?

`rememberSavable` allows the state to survive not only recompositions but also configuration changes. It does this by serializing the state, making it possible to restore the state after an activity is recreated due to a configuration change.

What are the drawbacks of using `rememberSavable` for large in-memory objects like bitmaps?

Bitmaps can be large, and serializing them for persistence across configuration changes is not recommended due to performance concerns. While bitmaps are serializable, storing them in this way can be inefficient and result in high memory usage.

What problem does the **Retain API** solve that `remember` and `rememberSavable` cannot?

The **Retain API** allows non-serializable objects, like `ExoPlayer` instances or large in-memory objects, to be retained across configuration changes without requiring serialization. This is particularly useful for objects that cannot be easily serialized, unlike `rememberSavable`, which requires serializable data.

How does the **Retain API** work under the hood in Jetpack Compose?

The **Retain API** uses a **Composition Local** to store values that need to be retained across configuration changes. It leverages a `retain` block and a `retain value store`, which can be overridden by lifecycle-aware components like activities or fragments to handle retention correctly on Android.

What is the difference between `retain` and `rememberSavable` in terms of object serialization?

The key difference is that `rememberSavable` requires the state to be serializable, meaning it can be written to and restored from disk. On the other hand, `retain` does not require serialization, making it suitable for non-serializable objects that need to be retained across configuration changes.

What is the role of **RetainedEffect** in Jetpack Compose, and how does it differ from **DisposableEffect**?

The **RetainedEffect** is similar to the **DisposableEffect**, but it does not trigger when a composable leaves the composition due to configuration changes. It is used for resources that need to be cleaned up when they are no longer needed, but it ensures they are not disposed of during configuration changes.

Why does the speaker recommend using `ViewModels` over the **Retain API** for large-scale applications?

For large-scale applications, **ViewModels** provide a more structured and testable approach to managing state across configuration changes and process death. They help separate UI logic from business logic, ensuring better architecture and maintainability. The **Retain API** is more suited for smaller, simpler cases or temporary state retention.

In what situations would the **Retain API** be particularly useful, according to the speaker?

The **Retain API** is particularly useful for library authors or smaller applications where you need to retain state across configuration changes without coupling state management to a `ViewModel`. It's also useful for non-serializable objects, like media players, that need to be preserved across activity recreations.