Fragment Lifecycle Quiz
ANDROID › Lifecycle
A fragment is replaced with addToBackStack(null) and the user later presses Back. Which callback runs again on the returning fragment that did NOT run on its first appearance steps before onCreateView?
- onAttach
- onCreate
- onCreateView
- onViewStateRestored only
Answer: onCreateView
On Back, the retained instance (still CREATED) skips onAttach/onCreate and re-enters at onCreateView to rebuild its destroyed view, then onViewCreated and onStart/onResume.
Why is observing viewModel.data.observe(this) { } in a fragment a bug?
- this is not a LifecycleOwner, so the fragment code won't compile
- The observer survives onDestroyView and leaks or updates a stale view
- It delivers each LiveData emission twice to the same observer
- LiveData cannot be observed from fragments; only activities can observe it
Answer: The observer survives onDestroyView and leaks or updates a stale view
The fragment lifecycle outlives its view on the back stack, so the observer keeps firing into the old view tree after onDestroyView, leaking it; use viewLifecycleOwner instead.
What is the correct relationship between the fragment's view lifecycle and the fragment's own lifecycle?
- They are the same single Lifecycle object throughout the fragment's life
- The view lifecycle can restart multiple times in one fragment lifecycle
- The fragment lifecycle always ends before the view lifecycle does
- The view lifecycle always reaches RESUMED before the fragment lifecycle
Answer: The view lifecycle can restart multiple times in one fragment lifecycle
A back-stacked fragment keeps its instance while its view is destroyed and recreated, so the separate view lifecycle goes through CREATED..DESTROYED multiple times within the single fragment lifecycle.
Which sequence is the correct downward (teardown) callback order for a fragment being destroyed?
- onStop, onPause, onDestroy, onDestroyView, onDetach
- onPause, onStop, onDestroy, onDestroyView, onDetach
- onPause, onStop, onDestroyView, onDestroy, onDetach
- onDestroyView, onPause, onStop, onDestroy, onDetach
Answer: onPause, onStop, onDestroyView, onDestroy, onDetach
Teardown mirrors setup: onPause, onStop, then the view is destroyed (onDestroyView) before the fragment (onDestroy), with onDetach always last.
Calling requireView() or getViewLifecycleOwner() at which point throws IllegalStateException?
- Inside onViewCreated, after the fragment view is ready
- Inside onResume, once the fragment is fully visible
- Inside onCreate, before onCreateView() has run
- Inside onStart, after the fragment has started
Answer: Inside onCreate, before onCreateView() has run
The view and its viewLifecycleOwner exist only between onCreateView (returning non-null) and onDestroyView, so accessing them in onCreate throws because no view lifecycle exists yet.
ViewPager2 keeps offscreen fragments at which maximum lifecycle state by default?
- RESUMED
- STARTED
- CREATED
- INITIALIZED
Answer: STARTED
ViewPager2 caps offscreen pages at STARTED via setMaxLifecycle so only the visible page reaches RESUMED, saving work while keeping adjacent pages' views ready.
An activity is in the STARTED state. What is the maximum state any fragment it hosts can reach right now?
- RESUMED, because fragments are independent of their host
- CREATED, because fragments always lag one state behind
- STARTED, because a fragment can't advance past its host
- DESTROYED, because the host is tearing down right now
Answer: STARTED, because a fragment can't advance past its host
A fragment's state is capped by its host: a child can never be more advanced than its parent, so a STARTED activity bounds its fragments at STARTED.
Which sequence is the correct upward callback order the first time a fragment is added and becomes visible?
- onAttach, onCreateView, onCreate, onViewCreated, onStart, onResume
- onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume
- onCreate, onAttach, onCreateView, onViewCreated, onResume, onStart
- onAttach, onCreate, onStart, onCreateView, onViewCreated, onResume
Answer: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume
The fragment is attached and created first (onAttach, onCreate), then its view is built (onCreateView, onViewCreated), and only then does it climb to STARTED and RESUMED (onStart, onResume).
Fragment B is placed on top of fragment A in the same container using add() (not replace()) with addToBackStack. What happens to fragment A's view?
- A's fragment instance is fully destroyed via onDestroy and onDetach
- A goes through onDestroyView immediately, exactly as with replace()
- A is detached, triggering onDetach while keeping the instance
- A's view stays attached in the container and is not destroyed
Answer: A's view stays attached in the container and is not destroyed
add() layers B over A without removing A, so A's view remains in the container; only replace() detaches the old fragment's view and triggers its onDestroyView.
Using the Fragment Result API (setFragmentResultListener), when is a stored result delivered to the receiving fragment?
- Synchronously the instant setFragmentResult is called, regardless of state
- Once the listener's lifecycle reaches at least the STARTED state
- Only during the fragment's onCreate callback
- Never directly; it requires a manually shared ViewModel
Answer: Once the listener's lifecycle reaches at least the STARTED state
FragmentManager holds the result and delivers it only when the registered listener's lifecycle is at least STARTED, queuing it if the fragment is currently stopped.
setRetainInstance(true) is deprecated. What is the recommended modern way to retain data across a configuration change?
- A ViewModel scoped to the fragment
- A large Bundle saved in onSaveInstanceState
- A static field or singleton holding the data
- Calling setMaxLifecycle(RESUMED) on the transaction
Answer: A ViewModel scoped to the fragment
A ViewModel survives configuration changes and cleanly replaces retained fragments, which were leak-prone and muddled the fragment lifecycle, hence the deprecation.
To host a nested (child) fragment inside another fragment, which FragmentManager should the transaction use?
- requireActivity().supportFragmentManager
- parentFragmentManager
- childFragmentManager
- A single application-wide FragmentManager
Answer: childFragmentManager
childFragmentManager scopes the nested fragment to the parent fragment's view lifecycle and its own back stack; parentFragmentManager is the manager that hosts the current fragment itself.
In which fragment callback is the saved view hierarchy state (such as an EditText's typed text) reapplied to the freshly created view?
- onCreate, since it initializes the fragment before any view state exists
- onCreateView, because it inflates the layout and sets up the fragment's view
- onViewStateRestored, where the saved view state is restored to the new view
- onResume, because it brings the fragment back to the foreground
Answer: onViewStateRestored, where the saved view state is restored to the new view
onViewStateRestored runs after onViewCreated and is the point where the previously persisted view hierarchy state is restored onto the newly inflated view.
How does FragmentTransaction.commit() differ from commitNow()?
- commit() runs synchronously on the caller thread before it returns
- commit() posts the transaction to run later on the main looper
- commit() cannot advance a fragment beyond the CREATED state
- commit() skips FragmentManager and updates the view tree directly
Answer: commit() posts the transaction to run later on the main looper
commit() posts the transaction to be executed later on the main looper (run immediately via executePendingTransactions), whereas commitNow() executes synchronously and is incompatible with addToBackStack.