How do you save UI state during screen rotation?
Tests your grasp of the Activity lifecycle and state restoration. A great answer explains the destroy/recreate cycle, notes that EditText handles its own state via its ID, and contrasts the modern ViewModel + SavedStateHandle with the older…
What's really being asked
This question probes your understanding of the Android Activity lifecycle, specifically how it handles configuration changes. The interviewer is testing if you know the modern, recommended patterns (ViewModel, SavedStateHandle) and can contrast them with older ones (onSaveInstanceState). It separates senior candidates who understand architecture from junior developers who may only know one, possibly outdated, solution.
The full answer
First, explain what happens: a screen rotation is a configuration change that causes the Activity to be destroyed and recreated by default. The lifecycle methods onPause, onStop, and onDestroy are called, followed by onCreate, onStart, and onResume for the new instance.
Second, address the EditText directly: if the EditText has a unique ID (android:id), the Android framework automatically saves and restores its state, including the text. No custom code is needed for this specific case.
Third, introduce the modern solution for other UI state: use a ViewModel to hold the state. ViewModel objects are designed to survive configuration changes, so the data remains available in memory for the new Activity instance. This is efficient as it avoids disk I/O.
Fourth, cover process death: a ViewModel alone does not survive process death. To make the solution robust, use the SavedStateHandle within the ViewModel. This combines the lifecycle awareness of ViewModel with the persistence mechanism of onSaveInstanceState, ensuring state is restored even if the OS kills your app process while it's in the background.
The mistakes people make
Only mentioning onSaveInstanceState. This is an outdated answer that ignores modern Android Architecture Components. A senior candidate must know about ViewModels.
Suggesting to prevent rotation by adding android:configChanges="orientation|screenSize" to the manifest. This is a huge red flag. It's a lazy fix that avoids solving the underlying state management problem and creates a poor user experience on many devices.
Forgetting that standard views like EditText with an ID save their own state. This shows a gap in practical, hands-on knowledge.
What usually comes next
"What's the difference between saving state in a ViewModel versus onSaveInstanceState?" (ViewModel survives configuration changes in memory; onSaveInstanceState survives process death via serialization. SavedStateHandle combines the best of both.)
"What are the limitations of onSaveInstanceState?" (It's for small amounts of data, typically under 100KB, and requires data to be Parcelable. It also involves more boilerplate in the Activity/Fragment.)
A concrete example
A user types "Hello" into an EditText with android:id="@+id/name_input". They rotate the phone. The Activity is destroyed and recreated. Because the EditText has an ID, the system automatically saves the text "Hello" and restores it. If there was also a non-standard custom view on screen showing a counter, its value should be stored in a MutableStateFlow within a ViewModel, which is in turn backed by a SavedStateHandle to survive both rotation and process death.
Interview question
When an Android Activity with an EditText (unique ID) and a custom counter (TextView) undergoes screen rotation, how should their states be preserved to survive both rotation and process death?
- a.Prevent the Activity from recreating on rotation using android:configChanges in the manifest.
- b.Store both states in a ViewModel, relying solely on the ViewModel's lifecycle for persistence.
- c.Both states should be saved in the Activity's onSaveInstanceState method.
- d.The EditText's state is automatically handled; the counter's value should be stored in a ViewModel with a SavedStateHandle.Correct
Why? this is the answer
The Android framework automatically saves the state of an EditText with a unique ID. For custom UI state, like a counter, the recommended modern approach is to use a ViewModel with a SavedStateHandle, which ensures data persistence across configuration changes and process death. Option B is incorrect because EditText state is automatic, and a ViewModel alone doesn't survive process death without SavedStateHandle.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #activity lifecycle
- #viewmodel
- #state management
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles