Best practices for saving UI state on Android

Saving a UI state properly is essential for providing a great UX experience. Your users might be disappointed if your screen doesn't preserve its state during a configuration change, activity recreation, or system-initiated process death. Learn best practices to save UI state properly in both the View system and Jetpack Compose by comparing APIs such as remember, rememberSaveable, onSaveInstanceState, ViewModel, and SavedStateHandle.
Chapters:
0:00 - Introduction
0:41 - Losing app state
2:10 - ViewModel
4:08 - Persistent storage
5:35 - Saved State APIs
8:45 - Testing saved state APIs
9:29 - SavedStateHandle
10:49 - Contribute to saved state from your own classes
14:33 - Control rememberSaveable value's lifecycle
19:00 - Recap
Resources:
Saving UI state on Android docs → goo.gle/438zaus
Save UI state in Compose → goo.gle/3KwbwQb
Speaker: Manuel Vicente Vivo
Watch more:
Watch all Android and Play Sessions → goo.gle/IO23_android_play
Watch all the Technical Sessions from Google I/O 2023 → goo.gle/IO23_sessions
Watch more Mobile Sessions → goo.gle/IO23_mobile
All Google I/O 2023 Sessions → goo.gle/IO23_all
Subscribe to Android Developers → goo.gle/AndroidDevs
#GoogleIO #Featured #AndroidDevelopers #foundation

[@AndroidDevelopers]

Watch all the Android and Play Sessions → goo.gle/IO23_androidplay_pin

[@mdalikazi]

Amazing example of SavedStateProvider for View system!

[@RowanGontier]

Love the passion, and command of subject. Just wish it was a lot more dumbed down, with clear as mud explanations of what we are trying to do.

[@_runtime]

The first advanced case is quite interesting - a reusable UI element having a complex state (NewsSearchState) depending on a repository (NewsRepository). Since we don't use ViewModels there, it would be interesting to know what's the best practice of using that component. I assume that the repository will have suspend functions and in the UI element itself we cannot call those suspending functions with the coroutine scope available - it is a UI-bound scope but we need a view model scope to run the backend calls.

[@deepakbisht4957]

Same here. Looking for the best practices to do that. As we are developers we have a thing of keeping Ui and State less coupling in our mind with different layers of our architecture...

[@mg508]

As for some previous comments about leaving the responsibility to the developer and/or SaveInstanceState being easier, it's quite the opposite. All the difference is in the viewModel being lifecycle-aware. With the saveInstanceState mechanism all the saving is done manually by the developer as the user navigates back and forth from one activity to the other. The view model, instead, not only survives configuration changes but also follows the activity's lifecycle hence saving and restoring the state accordingly.

[@walterjfranck]

me parece un montón de boilerplate entre Navigation y State Holder para integrar todo, agregar funcionalidad / personalización y mantener los estados en la navegación 🤯😭 ... Pero se entiende perfectamente

[@SnoopyDoofie]

As usual, overly complex. Hopefully someone has the interest in writing an open source library that drastically simplifies how state is managed.

[@LiranBarsisa]

I don't get the advantage of using these over what we already have, of onSaveInstanceState for saved-state and of sharedPreferences over the storage solution presented here. It's much longer and complicated here.

[@deepakbisht4957]

Well it's not complex...

[@gekylafas]

Not to mention, not type-safe. It's very easy to store data in SavedStateHandle that will crash your app due to their type. For example, storing data of type Set. Set is supported (because LinkedHashSet is Serializable), Parcelable is supported, but their combination isn't! Once you use Set, your items need to be Serializable too. But due to type erasure, SavedStateHandle won't detect that the combination is invalid and the app will simply crash in runtime. The relevant comment in SavedStateHandle's code says it all: // type erasure ¯\_(ツ)_/¯, we won't eagerly check elements contents Thanks Google!

[@mdalikazi]

What is the mono font seen in the slides?

[@varadgalgali453]

At 12:45, the rememberNewsSearchState composable returns an object of type rememberSaveable. But, aren't composable functions supposed to have a Unit return type?

[@codeone6423]

wow this was great thank you

[@kirwakelvinkering3122]

If viewmodels can survive configuration changes , what is the newd to intergrate it with SavedStateHandle api ?

[@llothar68]

My best way: Safe them in the C++ business layer via NDK. I share all the logic for all the 5 big operating systems via C++. Of course if you app doesn't really do something ... it's different

[@kalidsherefuddin]

Thanks for

[@LiranBarsisa]

1:14 "it is impossible to completely opt out of activity recreation. Some configuration changes will always recreate the activity." Which ? When do they happen? As for the implementation here, it seems much much longer and complicated than what it used to be, of just using onSaveInstanceState, and the storage is also much longer and complicated compared to just SharedPreferences. What's the point in using those if the original method works fine and it's much simpler and shorter? This is true for both Compose and for the View model.

[@scottbiggs8894]

There are more ways to have configuration changes than simply orientation changes. Some android devices have mechanical keyboards that fold in and out. Some androids have screens that get bigger or smaller (Samsung Galaxy Fold, for example). Both of these are configuration changes that cannot be disabled by forcing the app to landscape or portrait mode. But you're very right--this does seem MUCH more complicated than the old method of using onSaveInstanceState and SharedPreferences. In my code, I am using a hybrid of SharedPreferences and ViewModel stuff. It's messy, but it also works in all cases. And it doesn't use any @Experimental annotations either.

[@LiranBarsisa]

@@scottbiggs8894 The examples you've mentioned are already covered if you check the available values in the configChanges. My question was: Which aren't supported? About ViewModel, it works only as long as the process is alive. Better to use onSaveInstanceState too. Of course, it depends on your needs.

[@ismaelsanchez3492]

Really confusing stuff, basically you are transferring the responsibility of what happens to the app when the system kills it to the developer, when this should be the responsibility of whoever kills the app in the first place. The system, Android, should be able to restore the app as it was, or at least, give the option to the developer of what to do, to restore it, restart it or personalize what to do and then yes, put it in the hand of the developer.

[@unitbunsen7120]

I won't to see look on the three

[@KrisjanSenci]

Always save your states is a key

[@lost-prototype]

Very confusing

[@JesusChrist-qf9mh]

This is not framework, it is just crazy, you are copying ios just copy it correctly without hoisting(this is what smart naming is all about) us and your selfs.