The signal dropped. Mid-trip. With your car.

#reactnative #typescript #android #showdev

You've handed your car keys to a stranger. That's what a valet is. They drive off to park it, and the only thing between you and mild panic is a dot on a map, moving.

Then the valet drives into a basement. Or under a flyover. Or into one of the many parts of Bangalore where 4G just... isn't.

The dot stops.

Yesterday I asked what happens next. Here's the answer, and it's the most careful forty lines in the whole app.

Why the obvious version loses data

The valet app reports a location fix every few seconds, from a background task. The obvious code is: on each fix, send it to the server.

That works right up until the send fails. The background task runs in a headless context where the connection may not even be up. A fire-and-forget send from there doesn't throw anywhere you can see. The fix is just gone, and the route on the driver's map has a hole in it exactly where they were most worried.

Saved first, sent second

So nothing is ever sent before it's stored. Every fix goes into a small on-phone queue, and then the queue tries to drain:

async enqueue(fix) {
  const queued = ordered([...(await read()), fix]).slice(-maxFixes);
  await write(queued);

It still sends immediately. My first version enqueued and waited, which meant nothing reached the server between going online and going offline, and the valet's "last seen" went stale within a minute. The queue is for when a send fails, not a substitute for trying.

The queue has a ceiling, because a phone in a long tunnel shouldn't fill its storage with coordinates:

/** Roughly 15 minutes at the configured interval. */
export const MAX_QUEUED_FIXES = 200;

Past that, the oldest fixes go and the newest always stay. Where the car is now matters more than where it was a quarter of an hour ago.

Offline waits. Refused is dropped.

Here's the subtle part. A send can fail for two very different reasons:

Offline. Worth trying again. Stop here, keep everything, in order.
Rejected. The server said no: say, a fix for a job this valet isn't assigned to. That will be a no forever. Retrying it would block every good fix queued behind it.

if (result.ok) continue;
// A refused fix is consumed; an unsendable one halts the drain so the
// rest keep their order for the next attempt.
if (result.reason === 'rejected') continue;
break;
}

await write(queued.slice(index));

And when the signal comes back, the backlog replays oldest first, so the driver's map redraws the route in the order it was actually driven:

/** Oldest first, so a drain replays the route in the order it was travelled. */
function ordered(fixes: readonly LocationFix[]): LocationFix[] {
  return [...fixes].sort((a, b) => a.recordedAt - b.recordedAt);

Two more things the queue survives: two drains racing each other (only one runs at a time, or the same backlog gets sent twice), and a corrupted stored value (the queue starts empty instead of crashing a background task nobody is watching).

Ten tests

Every one of those decisions has a test: send on capture, hold on failure, oldest first, the bound, refused-versus-offline, stop at the first unsendable fix, a corrupt store, a single malformed entry. Ten tests, all passing, and none of them need a phone.

What I'd tell myself before starting

"Offline" isn't an error to handle. It's a state the app spends real time in. Design for it first, and the happy path falls out for free.

Tomorrow: you've seen what happens in the tunnel. Tomorrow, the valet's side of the screen: taking a job, every step one tap, and the photo of the parked car that has to exist before the job can be confirmed. Follow the series.

ParkEase is a peer-to-peer parking marketplace for India, built solo and launching soon on Android.
Code: https://github.com/Deonkar/parkease · Music: ende.app (CC BY 4.0)

DEV Community