MA1: How mobile is different: devices, networks and the app lifecycle
The app lifecycle
🎯You'll be able to
Explain how an app moves between foreground, background and closed, and keep the user's work safe through each change.
🏠The everyday picture
A shopkeeper who steps out to take a delivery leaves a note on the counter: what the last customer wanted and how far the bill got. If someone else has to take over, they can carry on from the note.
📘What it really is
- States: an app is in the foreground (visible), in the background (not visible, may run briefly), or not running at all.
-
The system decides: a phone call, the camera or a low-memory moment can push your app to the background, and the system may close it there without warning.
-
Save early: write important data (such as a form the user is filling) as it changes or when the app goes to the background, not only when they press Save.
-
Start well: when the app opens again, load the saved data quickly and put the user back where they were if you can.
- In React Native,
AppStatereportsactive,backgroundand (on iOS)inactive, so the app can save or pause work.
📝A worked example
Input: an adviser is halfway through a visit form when a call comes in. After the call, the app opens on an empty form.
Steps:
- Reproduce: fill half the form, send the app to the background, and close it from the app switcher.
- Save the draft to storage when the app goes to the background (and as fields change).
- On start, load the draft and show "Draft restored".
Expected output: the adviser returns to their half-filled form after the interruption.
🌍Where it's used
- Messaging apps keep a half-written message after you switch away.
- Payment apps check a payment's status when they come back to the foreground.
- Maps pause heavy work in the background to save battery.
📝Case scenario
A survey app for health workers lost long forms when the phone ran low on memory during a photo. Workers started writing answers on paper first. Saving each answer as it was entered, and restoring the draft on start, brought them back to the app.
🖱️Try it
In the KhetNote starter, read src/storage/store.js. Write down what happens to a saved visit if the app is closed by the system.
Success: you can say which line keeps the data and why it's lost.
⚠️Common mistakes
- Saving only on a button press. Sign: lost drafts after calls. Fix: save as the user works, or when going to the background.
- Assuming the app stays open. Sign: work lost when the system closes it. Fix: store important state, not just keep it in memory.
- Slow start-up. Sign: a blank screen for seconds. Fix: show saved data first, then refresh.
🛠️For your project
Project 1's test 1 checks that a saved visit is still there after the app is closed and opened again.
✅Quick check
What can happen to an app in the background without warning?
Show the answer
The system can close it, for example when memory is short.
When should a long form be saved?
Show the answer
As the user fills it in, or when the app goes to the background, not only on Save.