Offline Data Support
Feature Detail
Description
Offline Data Support provides the Meander Mobile App with a fully functional local persistence layer using Drift (Flutter's SQLite ORM) encrypted with SQLCipher. All core entities - activities, contacts, notes, expenses, assignments - are stored locally so peer mentors and coordinators can read and write data without any network connection. Writes are captured in a mutation outbox and replayed against the server once connectivity is restored. Conflict resolution handles cases where the same record was mutated both offline and on the server, applying a last-write-wins or server-wins strategy depending on entity type. The local schema mirrors the server schema closely enough to support full CRUD operations but is denormalized where necessary for query performance on mobile. ID mapping handles the transition from client-generated temporary IDs (used while offline) to server-assigned permanent IDs after sync. Optimistic updates are applied immediately to the local store and rolled back automatically if the server rejects the mutation, keeping the UI responsive and consistent.
Analysis
Peer mentors frequently work in environments with poor or absent connectivity - care homes, rural areas, or during travel between visits. Without offline support the app becomes unusable in precisely the moments it is most needed, forcing a return to the paper-based workflows it is designed to replace. Reliable offline capability is therefore a direct prerequisite for adoption and a core differentiator from web-only reporting tools. From a business continuity perspective, offline-first architecture also reduces risk: data entered by a peer mentor is never lost due to a network dropout. For organizations submitting to Bufdir, this means no gaps in activity records caused by connectivity issues. The encrypted local database also satisfies GDPR and data-minimization requirements by ensuring sensitive contact and assignment data at rest on the device is protected with AES-256 encryption, directly supporting the platform's compliance posture.
Drift is used as the ORM layer with SQLCipher for at-rest encryption. The local database schema is defined as Dart table classes with typed companions for insert and update operations. A mutation outbox table records every pending write with its operation type, entity type, payload, and retry count. The sync queue service (background-sync) reads from this outbox and dispatches requests to the REST API, updating outbox status on success or incrementing the retry counter on failure. Temporary IDs for offline-created entities use UUID v4 and are stored in an ID mapping table; once the server confirms creation the permanent ID is back-patched across all local foreign key references. Conflict resolution is entity-scoped: activities and notes use server-wins on conflict (server data is authoritative for reporting); contact edits use last-write-wins with a timestamp comparison. Optimistic updates are applied via Drift transactions with a rollback hook registered in the Riverpod state layer - on server rejection the provider re-fetches the authoritative record and notifies the UI.
Components (45)
Shared Components
These components are reused across multiple features
User Interface (9)
Service Layer (15)
Data Layer (8)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.