Offline first
A rider hands over the groceries in a basement car park with no signal. The Rider app must still record proof of delivery, keep it safe if the phone kills the app, and send it exactly once when the signal comes back. This lesson shows you how: local storage on the phone, an outbox of queued actions, and a sync loop with clear retry rules.
By the end you can
- Decide which Rider app actions must work with no signal and which need the server
- Pick the right place on the phone for each kind of data: SQLite, key-value storage, secure storage or files
- Build an outbox that survives the app being killed and syncs with idempotency keys made on the phone
- Write retry rules: backoff with jitter, stop on validation errors, and let the server win conflicts
- Explain what NetInfo and background tasks can promise, and what they cannot
The everyday picture
You type a message in WhatsApp while you are in a lift. The message appears in the chat at once, with a small clock icon next to it. You can close the app and put the phone away. When the lift opens and the signal comes back, the clock turns into a tick, and the message arrives once, in the order you wrote it, even if your phone had to try three times.
That small clock promises four things. Your message was saved on your phone before anything was sent. The app shows clearly that it is waiting. Messages stay in order. And the other side never sees one twice. In this lesson you build that clock, and everything behind it, for proof of delivery.
What must work in a dead zone
Riders lose signal many times a shift: in basements, underground car parks, lifts and rural dead zones. Worse than no signal is a weak one, sometimes called lie-fi: the phone shows one bar, the request starts, and nothing comes back for 40 seconds. Most Rider app users have cheap Android phones with 2 to 3 GB of memory, so the operating system also kills apps in the background to free memory, often while the rider is using the camera.
An offline-first app treats the network as something that will come back later. Screens read from the phone's storage, actions are written there first, and a separate sync process talks to the server. The general design, including pulling server changes, is in Offline-first apps and data sync. This lesson is the phone side.
Go through the app feature by feature and ask one question: is it safe to accept this action without the server?
- Works offline: opening the job list and job details that were already downloaded (address, items, cash to collect), marking a job picked up, and capturing proof of delivery: photo, signature or one-time code, location and time. These are facts about what happened, and they stay true when they reach the server an hour later.
- Needs a connection: accepting a new job. The dispatcher may have offered it to two riders, and only the server knows who got it first. Offline, the button says "Needs signal" instead of pretending.
Every offline action follows one rule: save first, then show success. If "Saved" appears before the data is on the phone's storage, a crash a second later loses a delivery the rider believes is recorded.
Quick check
The rider has no signal. Which action should the Rider app refuse with "Needs signal"?
Accepting a job is a decision the server has to make, because another rider may have taken it already. Accepting it offline would let two riders drive to the same store. The photo, the cash record and the address are facts or reads, so they are safe to keep on the phone and sync later.