DevBits
DevBitsAndroid Handbook
Android Fundamentals

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.

AF-005Intermediate~45 sec

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 lifecycleFragment view lifecycle
Represents the lifetime of the Fragment instanceRepresents one particular view hierarchy created by that Fragment
Begins as the Fragment is attached and createdBegins after onCreateView() returns a view
Can continue while no Fragment view existsEnds when onDestroyView() is called
Owns non-UI state and coordinates the screenOwns 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.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more

On this page