Practical technology learning
Android UI State: Plan Configuration Changes, Process Recreation and Storage Separately
Choose a state lifetime before choosing where a screen stores its values. A search query and a selected filter are useful teaching examples because their restoration can be checked visibly. This exercise uses invented text and distinguishes configuration changes, system-driven process recreation and durable records.
Write a restoration expectation sheet
List the query text, selected filter, loaded results and any saved record separately. For each item, state whether it can be recomputed, whether it should survive a configuration change and whether it needs to exist after the current app session.
Do not use “keep everything” as the only requirement. Some values are small reconstruction inputs, some are expensive data that can be loaded again, and some represent records that must be stored deliberately.
Understand the configuration-change case
Use an appropriate ViewModel to hold screen-related state that should survive configuration changes. Recreate the activity through a configuration change in the local learning setup and compare the query and filter with the written expectation.
Keep references to destroyed views or activities out of long-lived state holders. Retaining the value needed to build a new view is different from retaining the old view itself. Record the actual setup and observation rather than claiming that every device configuration was tested.
Treat process recreation as a separate case
A ViewModel alone is not persistent storage and does not survive process death. Review suitable saved-state mechanisms, such as SavedStateHandle for small reconstruction values, in the context of the chosen application architecture.
Use the platform’s documented development procedure for the scenario you are testing. Note the difference between system-driven recreation and a user deliberately dismissing or stopping the app. Do not infer a universal restoration promise from a single rotation test.
Keep durable data in its proper place
If the exercise later saves an actual draft record, define the persistence requirement and choose an appropriate local data source. Restore the screen using small identifiers or parameters and reload durable content rather than putting a large result set into saved UI state.
Use only harmless teaching values. Credentials and unnecessary personal information do not belong in a demonstration of state restoration. The size and sensitivity of a value are part of the design decision, alongside lifetime and access.
Review the state-lifetime plan
- Every screen value has an explicit lifetime.
- Configuration changes and process recreation are separate cases.
- ViewModel retention is not described as permanent storage.
- Small reconstruction inputs are distinguished from loaded datasets.
- The visible restored screen matches the stated expectation.
Keep the test record with the screen
A short scenario-and-result log is more useful than saying the app “remembers state”. Mango Engineers’ Android course includes lifecycle and storage foundations; discuss the current prerequisites and practical learning sequence with the team.