How do you share a ViewModel across multiple Fragments?
Tests ViewModel scoping and Fragment communication. A strong answer names activityViewModels or navGraphViewModels, warns about Activity memory retention and hidden coupling, and suggests a parent Fragment or data flow alternative.
What's really being asked
Your understanding of ViewModel scoping APIs, lifecycle ownership, and safe inter-Fragment communication. The interviewer wants to see that you know how to share state without creating memory leaks or tight coupling between UI controllers.
The full answer
First, name the exact APIs: activityViewModels in Kotlin or ViewModelProvider with the Activity as ViewModelStoreOwner to scope the instance to the Activity lifecycle. Second, mention navGraphViewModels or ViewModelProvider with a NavBackStackEntry when the shared scope should match a navigation subgraph rather than the entire Activity. Third, describe the observable state pattern: the ViewModel exposes LiveData, StateFlow, or a data stream, and Fragments collect it without holding direct references to each other. Fourth, list concrete risks: the Activity retains the ViewModel until it finishes, so heavy state or many shared ViewModels increase memory pressure; Fragments become implicitly coupled to the same backing state, making independent testing and reuse harder; and improper scoping can outlive the intended Fragment pair if the Activity survives. Fifth, mention alternatives: a parent Fragment scope via by viewModels with a shared owner, or a repository layer with application scope, depending on the actual data lifetime needed.
The mistakes people make
Using a singleton or static instance to share data bypasses lifecycle awareness and leaks across configuration changes. Creating a new ViewModel in each Fragment and trying to sync them manually with callbacks or interfaces creates fragile two-way coupling. Holding a direct reference to another Fragment inside the ViewModel defeats the purpose of the pattern and crashes after configuration changes.
What usually comes next
How would you test a shared ViewModel in isolation? When would you choose a navigation graph scope over an Activity scope? How do you clear shared state when the user leaves a specific flow but the Activity remains alive?
A concrete example
In a checkout flow with three Fragments for address, payment, and review, a CheckoutViewModel scoped to the checkout navigation graph via navGraphViewModels holds order state. The address Fragment updates a shipping address field, the review Fragment collects the same field as StateFlow, and the ViewModel is automatically cleared when the user pops the checkout graph, even though the host Activity continues running.
Interview question
What is the main benefit of using navGraphViewModels instead of activityViewModels to share state between Fragments in a single Activity?
- a.It allows Fragments to share data without exposing LiveData or StateFlow to observers.
- b.The ViewModel is cleared automatically when the user pops the navigation graph, reducing memory pressure.Correct
- c.It prevents configuration changes from destroying the shared ViewModel when Fragments are recreated.
- d.Fragments can hold direct references to each other inside the ViewModel to simplify communication.
Why? this is the answer
A navigation graph scope ties the ViewModel to the NavBackStackEntry and clears it when the user pops that graph, whereas an Activity scope retains it until the Activity finishes. Option C is tempting because ViewModel survival through configuration changes is a well-known feature, but both scopes already provide this, so it is not a unique benefit of navGraphViewModels.
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