Sign in Get started

Mobile API Best Practices · Capstone

Capstone: Offline Field-Service App

Design the API and sync model for technicians working without connectivity.

Scenario

A utilities company has 8,000 technicians using iOS and Android tablets to complete work orders in basements and rural areas with no signal for hours. They view assigned jobs, update checklists, capture photos (10–40 per job), collect customer signatures and record parts used (which decrements van inventory). Dispatchers reassign jobs during the day. Old app versions stay in use for ~9 months.

Requirements

  • Full offline operation for a day's work
  • No lost edits, photos or signatures
  • Dispatcher reassignment reaches devices quickly when online
  • Accurate inventory despite offline usage

Constraints

  • Cellular data is metered
  • App releases every 2 weeks; 9-month tail of old versions
  • Existing REST backend and Postgres

Deliverables

  1. Design the sync protocol (endpoints, tokens, deletions, resync).
  2. Choose conflict strategies per data type.
  3. Plan media upload and evolution/upgrade strategy.

Hints

  • Think of permission changes as data changes.
  • Inventory decrements are operations, not overwrites.
  • Assume the response to any mutation can be lost.

Draft each deliverable below before revealing the model answer and rubric.

Further reading: Android: Offline-first apps

Deliverables

Design the sync protocol (endpoints, tokens, deletions, resync).

Model answer

Local DB per device; GET /v1/sync?since=<token> returns jobs/checklists/parts changes from a per-technician change log (monotonic seq) with tombstones and permission-scope changes (reassigned job → delete op). 410 resync-required when tokens fall out of retention (30 days). Mutations go through POST /v1/mutations batches with client-generated ULIDs, idempotency keys and base_version. Silent push "sync hint" on reassignment; sync on foreground and via WorkManager/BGTask when connected.

Rubric

Strong answers include a monotonic change log, tombstones, permission revocation as changes, idempotent batched mutations and a resync path. Common misses: client-clock timestamps; forgetting reassigned jobs must disappear.

Choose conflict strategies per data type.

Model answer

Checklist items: field-level merge (rarely conflict). Job status: server-authoritative state machine; transitions validated (a job reassigned away rejects completion → user is told). Notes: append-only entries (no conflict). Parts used: recorded as commutative inventory operations (decrement events), not absolute counts; negative stock flagged for reconciliation. Signatures/photos: immutable, keyed by client ID.

Rubric

Look for different strategies per type and modeling inventory as operations rather than LWW counts.

Plan media upload and evolution/upgrade strategy.

Model answer

Photos queued locally, compressed on device, uploaded via resumable/multipart pre-signed URLs only on Wi-Fi unless the job is flagged urgent; server validates and attaches to the job via event. Versioning: additive-only sync payloads, tolerant enum decoding, app version on every request, min/recommended version config shipped in v1, feature flags for new checklist types, server-side compat for old versions during the 9-month tail.

Rubric

Strong answers address metered data, resumability and how old app versions keep working. Missing a forced-upgrade path is a red flag.

Open in the app to mark lessons complete, take notes and track your progress.