How do you share a ViewModel between Fragments?

WHAT THIS TESTS: This question assesses your practical knowledge of the Android Jetpack ViewModel component and its role in modern app architecture. The interviewer is looking for more than just the basic by viewModels() delegate. They want to see if you understand how to correctly scope a ViewModel's lifecycle to a component that outlives a single Fragment, such as a parent Activity or a navigation graph. This demonstrates your ability to manage shared state and handle inter-fragment communication in a clean, lifecycle-aware, and testable way.

A GOOD ANSWER COVERS: A strong answer outlines a clear, modern approach. First, identify the shared lifecycle owner for the fragments, which is typically the host Activity or a navigation graph if using the Navigation component. Second, explain the mechanism: use the activityViewModels() KTX delegate in each fragment to retrieve a ViewModel instance scoped to the Activity. Alternatively, and preferably for more granular control, use navGraphViewModels(R.id.my_nav_graph) to scope the ViewModel to a specific subgraph. Third, describe the communication flow: one fragment updates data in the shared ViewModel (e.g., a MutableStateFlow), and other fragments observe that data to react to changes. Finally, state the key benefit: this decouples the fragments, as they only need to know about the ViewModel.

COMMON WRONG ANSWERS: A major red flag is suggesting non-lifecycle-aware or outdated patterns. This includes creating a singleton object to hold state (which can cause memory leaks), using setTargetFragment (which is deprecated and creates tight coupling), or defining interfaces on the host Activity that fragments must call. While the interface pattern works, it's boilerplate-heavy and less scalable than a shared ViewModel. A weak answer just says "use a shared ViewModel" without specifying the scoping mechanism (activityViewModels or navGraphViewModels) or explaining how it works.

LIKELY FOLLOW-UPS: Be prepared for questions about the risks. For example, "What's the risk of scoping to the Activity?" The ViewModel might live longer than necessary, holding onto memory if only a few fragments in a deep navigation stack need it. This is why navGraphViewModels is often better. Another follow-up could be, "How would you handle dependency injection for this shared ViewModel using Hilt?" The answer is to use @HiltViewModel and inject it normally; Hilt respects the scoping requested by the KTX delegate.

ONE CONCRETE EXAMPLE: In a master-detail flow, a ProductListFragment and a CartFragment need to share cart state. Create a CartViewModel scoped to the parent Activity. In each fragment, get the instance via private val cartViewModel: CartViewModel by activityViewModels(). When a user adds an item in ProductListFragment, it calls cartViewModel.addItem(product). The CartFragment observes cartViewModel.cartItems (a StateFlow) and automatically updates its UI when the list changes, without ever directly communicating with the ProductListFragment.