- Including the ViewModel Dependency
- Adding a ViewModel
- Saving Data Across Process Death
- ViewModel vs Saved Instance State
- For the More Curious: Jetpack, AndroidX, and Architecture Components
- For the More Curious: Avoiding a Half-Baked Solution
This chapter is from the book
This chapter is from the book
This chapter is from the book
For the More Curious: Avoiding a Half-Baked Solution
Some people try to address the UI state loss on configuration change bug in their app by disabling rotation. If the user cannot rotate the app, they never lose their UI state, right? That is true – but, sadly, this approach leaves your app prone to other bugs. While this smooths over the rough edge of rotation, it leaves other lifecycle bugs that users will surely encounter, but that will not necessarily present themselves during development and testing.
First, there are other configuration changes that can occur at runtime, such as window resizing and night mode changes. And yes, you could also capture and ignore or handle those changes. But this is just bad practice – it disables a feature of the system, which is to automatically select the right resources based on the runtime configuration changes.
Second, handling configuration changes or disabling rotation does not solve the process death issue.
If you want to lock your app into portrait or landscape mode because it makes sense for your app, you should still program defensively against configuration changes and process death. You are equipped to do so with your newfound knowledge of ViewModel and saved instance state.
In short, dealing with UI state loss by blocking configuration changes is bad form. We are only mentioning it so that you will recognize it as such if you see it out in the wild.