Register an Activity While Offline
The registration flow must function fully without network access. Submitted registrations are stored in the local SQLite store and the local storage adapter flags them as pending sync. When the device regains connectivity, the sync service pushes pending records to Supabase. Conflicts (e.g. another device submitted the same record) are resolved server-side with last-write-wins for non-financial fields. The peer mentor sees a subtle 'Pending sync' badge on registrations awaiting upload. The sync process runs automatically in the background and clears the badge on success.
User Story
Audience Summaries
Offline-first activity registration is a non-negotiable prerequisite for data completeness across the peer mentor network. Peer mentors operate in community centres, care facilities, and rural areas where connectivity is unreliable — without this capability, mentors revert to paper logs or skip recording entirely, creating gaps in the data that Bufdir reporting depends on. Every unrecorded activity represents a missed data point that undermines the organisation's ability to demonstrate programme impact, justify continued funding, and meet regulatory obligations. This high-priority story directly protects revenue streams tied to outcome-based reporting and strengthens Bufdir compliance posture.
By removing the network dependency from the registration workflow, the platform becomes viable in the real-world environments where peer mentors actually work, increasing adoption rates, improving data quality, and reducing administrative reconciliation overhead. The automatic background sync with conflict resolution ensures data integrity without requiring mentor intervention, reducing support burden and improving the overall reliability of the platform as a reporting instrument.
This is a high-priority, high-complexity story with broad cross-functional impact. The implementation spans the local SQLite store, a local storage adapter, a background sync service, Supabase integration, and the registration UI — requiring close coordination between mobile, backend, and QA teams. Dependencies on the quick-activity-registration story (story-quick-activity-registration-peer-mentor-001) must be resolved before development begins. Effort estimation should account for the full offline state machine: local persistence, pending-sync badge UI, automatic sync trigger on connectivity change, exponential backoff retry logic (up to 3 attempts), conflict resolution (last-write-wins for non-financial fields), and app-restart persistence.
Acceptance criteria provide clear UAT scenarios covering offline confirmation messaging, batch sync within 60 seconds, retry on server error, state persistence across restarts, and clean online-only behaviour. Rollout risk is moderate — sync failures must surface gracefully without data loss. A staged rollout with verbose sync logging in initial releases is recommended to catch edge cases before full deployment.
This story requires implementing a full offline-first data layer for the activity registration flow. Key changes: (1) SQLite local store must persist completed registration records with a 'pending_sync' status flag managed by the local storage adapter; (2) a background sync service must listen for connectivity change events and process the pending queue, implementing exponential backoff (recommended: 1s, 2s, 4s) with a max of 3 retries before surfacing an error; (3) the Supabase write path must handle conflict resolution server-side using last-write-wins semantics for non-financial fields — ensure financial fields are excluded from this policy explicitly; (4) the registration confirmation view requires conditional messaging based on network state at submission time; (5) the pending-sync badge component must be driven by the local store's pending count and cleared reactively on successful sync. State must survive app restarts — verify SQLite persistence is not wiped on cold start. Edge cases: concurrent submissions from multiple devices, partial batch sync failures, and network toggling mid-sync.
Unit tests should mock connectivity events; integration tests should cover the full pending → synced lifecycle against a local Supabase instance.
Acceptance Criteria
- Given my device is offline (airplane mode), when I complete the full registration flow and tap Confirm, then the activity is saved locally and a confirmation view is shown with a 'Saved offline — will sync when connected' message
- Given I have 3 pending offline registrations, when connectivity is restored, then all 3 are synced to Supabase within 60 seconds and the pending badges are removed
- Given a sync fails due to a server error, when the sync is retried, then it retries up to 3 times with exponential backoff before surfacing an error to the peer mentor
- Given I restart the app while offline records are pending, when the app launches, then the pending records are preserved and sync resumes once connectivity is available
- Given I am online and submit a registration, when the submission is complete, then no offline badge is shown and the record is immediately visible in my activity history
Business Value
Peer mentors often work in environments with unreliable connectivity — community centres, care facilities, rural areas. If the app requires a live connection for registration, peer mentors will revert to paper or forget to log activities entirely. Offline-first registration is a prerequisite for achieving the data completeness that Bufdir reporting depends on.
Components
- Activity Registration Cubit service
- Activity Registration Service service
- Activity Repository data
- Supabase Activity Client infrastructure
- Local Storage Adapter infrastructure
- Local Storage Adapter infrastructure