Offline Support & Data Sync

Peer mentors frequently operate in environments with unreliable connectivity — home visits, rural areas, and community centers. If the app requires a live connection to register activities, it fails at its core purpose for a significant portion of use cases. Offline support ensures that the most critical user action — activity registration — always works regardless of network conditions. This directly reduces underreporting, which is the primary problem all three partner organizations identified. From a reliability perspective, offline-first architecture also makes the app resilient to backend outages and deployment downtime.

The local database is implemented using drift (formerly moor) for type-safe SQLite access in Flutter, with a schema that mirrors the subset of server tables needed for offline operation (activities, contacts, peer_mentors, activity_types, settings). The offline queue stores pending mutations as serialized JSON with operation type, endpoint, and payload. The sync service runs on app foreground and connectivity-restored events, processing the queue in FIFO order with exponential backoff on failure. Conflict resolution uses server-wins strategy with local audit trail. Bloc/Riverpod state management is used to propagate sync status to UI components.