The Activity Lifecycle
Sprout's detail screen shows a live countdown to the next watering. If the user switches to another app, that countdown should stop wasting battery, and when they return it should pick up again. To do that you need to know exactly when the system tells your activity it is visible, in front, or gone.
The rule
Up: create, start, resume. Down: pause, stop, destroy.
Each callback marks a change of state:
| Callback | What just happened |
|---|---|
onCreate |
The activity exists. Set up the UI once. |
onStart |
It is visible. |
onResume |
It is in the foreground and receives input. |
onPause |
It is losing the foreground (maybe partly covered). |
onStop |
It is no longer visible. |
onDestroy |
It is being removed. |
When a stopped activity comes back, the system calls onRestart, then onStart and onResume again. onCreate does not repeat.
Pair your work with mirror callbacks: what you start in onStart, stop in onStop; what you start in onResume, stop in onPause.
override fun onStart() { super.onStart(); countdown.start() }
override fun onStop() { countdown.stop(); super.onStop() }The shortcut
Picture a staircase: create → start → resume on the way up, pause → stop → destroy on the way down. Any user action just walks some steps.
Open the detail screen
onCreate→onStart→onResume. The countdown starts inonStart.
The common trap: doing heavy work in onPause. It must finish quickly, because the next screen waits for it. Save lightweight state there and keep slower cleanup for onStop.
Drills
Answer fast — trust the rule.
In what order are callbacks called when an activity first appears?
After which callback is the activity no longer visible?
The user presses Home, then reopens Sprout. Which callback is NOT called on the way back?
You start a location listener in onResume. Where should you stop it?
Remember
- Up: create, start, resume. Down: pause, stop, destroy.
- Returning from stopped:
onRestart→onStart→onResume, neveronCreate. - Start and stop work in mirror pairs; keep
onPausefast.