Why is `LiveData<Boolean>` bad for one-time ViewModel events?
This tests your grasp of state vs. events. A LiveData<Boolean> is state; it re-triggers on rotation. Instead, expose events via a StateFlow and have the UI call an eventConsumed() function on the ViewModel to maintain unidirectional data flow.
What's really being asked
This question probes your understanding of the critical difference between representing UI state and handling one-time UI events. It specifically targets a common pitfall with LiveData: its "sticky" nature. An interviewer wants to see if you recognize why a state-holding mechanism is unsuitable for ephemeral events and if you know the modern, lifecycle-safe patterns that respect unidirectional data flow (UDF).
The full answer
A strong answer identifies the core problem and then offers a robust solution. First, explain that LiveData is designed to hold state. When a configuration change occurs (like screen rotation), the new UI component re-subscribes and immediately receives the last emitted value, causing the one-time event (like a Toast) to incorrectly trigger again. Second, propose a solution where the ViewModel exposes events, and the UI consumes them. The modern approach is to use a StateFlow for the event's data and a separate ViewModel function (e.g., userMessageShown()) that the UI calls after handling the event. This clears the event state in the ViewModel, respecting UDF. Third, you can mention older patterns like a custom SingleLiveEvent class or using a SharedFlow as an alternative for pure event streams.
The mistakes people make
A major red flag is suggesting the UI should "fix" the problem by directly setting the LiveData back to false or null after observing it. This violates the principle of UDF, where only the ViewModel should modify its own state. Another weak answer is simply saying "use SingleLiveEvent" without explaining why it works or what problem it solves. This suggests rote memorization rather than deep understanding. Failing to mention the configuration change problem at all is a clear sign of inexperience.
What usually comes next
"How would you implement the state-based event handling with a StateFlow? Show me the code for the ViewModel and the Fragment/Activity." "What are the pros and cons of using a SharedFlow for events versus a StateFlow with a consumption function?" "What if two observers are listening for the same event? How would you ensure only one handles it?"
A concrete example
The ViewModel holds a mutable state flow for a user message ID, initially null: private val _userMessage = MutableStateFlow<Int?>(null). The public, immutable flow is val userMessage: StateFlow<Int?> = _userMessage. When a network call fails, the ViewModel posts a string resource ID: _userMessage.value = R.string.network_error. The UI collects this flow. If the value is not null, it shows a Toast and immediately calls viewModel.userMessageShown(). This ViewModel function simply sets _userMessage.value = null, preventing the Toast from re-appearing on rotation.
Interview question
What is the primary issue when using LiveData<Boolean> for one-time UI events like showing a Toast?
- a.The boolean type is too restrictive for complex event payloads.
- b.It requires the UI to update the ViewModel's state to clear the event, violating Unidirectional Data Flow.
- c.It can lead to memory leaks if the observer is not properly removed.
- d.It re-emits its last value to new observers, causing the event to re-trigger on configuration changes.Correct
Why? this is the answer
The core problem is LiveData's 'sticky' nature; it re-emits its last value to new observers, causing one-time events to incorrectly re-trigger after configuration changes. While attempting to clear the event can lead to UDF violations (B), this is a consequence of the re-emission problem, not the primary issue with LiveData itself.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
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