The Problem
A sales app built on Ionic and Angular had a four-step flow: create ticket, fetch GPS coordinates, update ticket with location, register prospect. Standard RxJS switchMap worked fine until someone lost signal mid-flow. The app would orphan data or duplicate records on retry because switchMap dies with its subscription when network calls fail.
The Fix
The developer implemented what enterprise mobile teams have used for years: a SQLite queue with checkpoint persistence. Instead of chaining observables end-to-end, each step writes its state to local storage. An orchestrator service reads the queue, checks the last completed checkpoint, and resumes from there when connectivity returns.
No complex RxJS operators. No race conditions. The data lives on disk, not in memory.
Why This Matters
Mobile workflows that assume constant connectivity fail in the field. Sales reps work in basements. Field techs operate in remote sites. Government inspectors lose signal between buildings.
The trade-offs are clear:
switchMap/mergeMap approach:
- Clean reactive code
- Fails hard on network loss
- No built-in recovery
- Memory-only state
SQLite queue approach:
- More code upfront
- Survives app restarts
- Automatic retry from checkpoints
- Disk-persisted state
AngularFire offers middle ground with enablePersistence() for Firestore, but it requires initial online load and won't help with multi-step orchestration across different APIs.
Implementation Notes
The pattern uses Capacitor's Network plugin to detect connectivity changes. When status returns to "connected", the orchestrator wakes up and processes the queue. Each record tracks its state (pending, step1_complete, step2_complete, failed). The service doesn't loop through all pending items because observables are async. It processes one at a time, recursive-style.
Google Maps plugins won't help here. They cache only viewed areas per ToS. True offline mapping requires Mapbox or Leaflet with pre-loaded tiles.
Service workers handle static assets well but don't solve dynamic request chains. You still need application-level state management.
The Real Question
How many of your mobile flows assume connectivity? If the answer is "most of them," you're carrying technical debt that shows up as support tickets, not build failures.
Offline-first architecture costs more upfront. It saves money later. The math works when your users are in the field, not at desks.