Can you describe the Fragment lifecycle and Fragment view lifecycle?
Explain why a Fragment and its view have different lifetimes, and how that affects UI work and cleanup.
What the interviewer is testing
The interviewer is checking whether you understand that a Fragment is not a single lifetime containing a permanent view hierarchy.
A strong answer explains why the separate view lifecycle exists, where UI setup and cleanup belong, and why observing UI state with the Fragment itself as the LifecycleOwner can keep work alive after the view has gone away.
❌ Common mistake
If they ask you to elaborate
| Fragment lifecycle | Fragment view lifecycle |
|---|---|
| Represents the lifetime of the Fragment instance | Represents one particular view hierarchy created by that Fragment |
| Begins as the Fragment is attached and created | Begins after onCreateView() returns a view |
| Can continue while no Fragment view exists | Ends when onDestroyView() is called |
| Owns non-UI state and coordinates the screen | Owns bindings, view listeners, adapters, and UI observation |
Ends in onDestroy() and onDetach() | Can be created again for the same Fragment instance |
Mental model: The Fragment survives; the View is disposable. The Fragment may stay alive while its View is destroyed and recreated multiple times.
The typical creation path is:
onAttach() → onCreate() → onCreateView() → onViewCreated() → onStart() → onResume()
When the Fragment's UI is removed, the view moves down through its lifecycle and onDestroyView() is called. The Fragment instance may still exist. If the user navigates back, the Fragment can receive onCreateView() and onViewCreated() again with a new view hierarchy.
This is the mental model to keep:
Fragment instance: onCreate() ───────────────────────────── onDestroy()
│ │
First view: onCreateView() ─ onDestroyView()
│
Recreated view: onCreateView() ─ onDestroyView()Use onCreate() for non-view initialization that belongs to the Fragment instance. Inflate or provide the layout in onCreateView(), then configure views, adapters, listeners, and UI observation in onViewCreated().
Clean up anything that directly references the current view hierarchy in onDestroyView(). Cleanup that belongs to the Fragment instance itself belongs later, when that instance is actually destroyed.
Code example
class OrdersFragment : Fragment(R.layout.fragment_orders) {
private var _binding: FragmentOrdersBinding? = null
private val binding get() = requireNotNull(_binding)
private val viewModel: OrdersViewModel by viewModels()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
_binding = FragmentOrdersBinding.bind(view)
binding.ordersList.adapter = OrdersAdapter(::openOrder)
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.uiState.collect { state ->
binding.progress.isVisible = state.loading
binding.ordersList.isVisible = !state.loading
}
}
}
}
override fun onDestroyView() {
binding.ordersList.adapter = null
_binding = null
super.onDestroyView()
}
private fun openOrder(orderId: String) = Unit
}The binding and adapter belong to the current view hierarchy, so they are cleared in onDestroyView(). The ViewModel is scoped to the Fragment and can continue holding screen state while that view is recreated.
Using viewLifecycleOwner.repeatOnLifecycle() ties collection to the view rather than the longer-lived Fragment instance. Collection starts when the view reaches STARTED, stops when it falls below that state, and is cancelled permanently when that view is destroyed.