When ViewModels Go to Die: Saving ViewModel State

This is a presentation given at DroidCon Americas 2020: https://www.online.droidcon.com/americas-speaker/sumayyah-ahmed

Abstract:

Contrary to our hopes, ViewModel lifecycles are not infallible. The Android OS can kill running processes, which means killing your ViewModel and all the state that you’ve saved in it, spelling impending disaster for your Activity or Fragment. Luckily, we have a new tool to maintain a seamless user experience even through process death – SavedStateHandle. This talk will use code examples to demonstrate:
• How to use SavedStateHandle to gracefully save and resurrect your ViewModel state through process death
• How to leverage Jetpack to automate state restoration with SavingStateLiveData

Transcript

1. When ViewModels Go to Die: Saving ViewModel State November 17, 2020
2. 2 about me Github: https://github.com/sumayyah LinkedIn: https://www.linkedin.com/in/sumayyah-ahmed Twitter: @SumayyahAhmed13
3. 3 SavedStateHandle new Jetpack-recommended way of handling saved state with ViewModels
4. 4 ViewModels are vulnerable to System-Initiated Process Death
5. 5 Process 1 Process 2 ...
6. 6 ViewModel with status data In-process memory Android OS kills the process ViewModel data?? In-process memory
7. 7 Problem: The user expects that when they come back to the activity, the state is the same as when they left it. For example: search bar data
8. 8 ViewModel: Step 1 App A more serious problem: setting up Bluetooth-enabled hardware via an app Router: State 1 ViewModel: Step 2 App Router: State 2 Process death ViewModel: Step ?? App Router: State 2 Now your app and hardware are out of sync
9. :(
10. 1 0 Option: Persist data SharedPreferences, local DB, cloud
11. 1 1 Option: Use SavedInstanceState
12. 1 2 SavedInstanceState ViewModel data Process Death SavedInstanceState Activity/Fragment ViewModel data SavedInstanceState Restore! SavedInstanceState New Activity/Fragment New ViewModel Activity/Fragment
13. 1 3
14. 1 4 The Problems with SavedInstanceState Code needs to live in the LifecycleOwner -> Data usage/storage logic has to be in the view class ViewModel initiation delayed till you get SavedInstanceState data
15. 1 5 The Jetpack Way Use SavedStateHandle
16. 1 6 What is it? Map of key-value pairs, backed by Bundle VM-friendly wrapper around SavedInstanceState Allows ViewModel control over data state independent of lifecycle owner
17. 1 7
18. 1 8 Let’s code
19. 1 9 Behind the scenes Bundle SavedInstanceState SavedStateProvider SavedStateProvider SavedStateHandle ViewModel SavedStateRegistryOwner (aka Activity/Fragment) SavedStateRegistryController
20. 2 0 Limitations • Should be used to store simple data types: • Primitives • LiveData objects have to be parcelable • Data limit • NOT a permanent form of storage! Tied to SavedStateRegistryOwner lifecycle. So if the activity is finished, so is SavedInstanceState