Summary Cache Repository
Component Detail
Description
Stores periodic summary records locally on the device using the app's offline persistence layer, allowing the summary card and team view to render without a network connection. Invalidates cache when a new summary is received via push notification.
summary-cache-repository
Summaries
The Summary Cache Repository ensures that peer mentors and coordinators can access their performance summaries and team views even in low-connectivity or offline environments, which is a critical differentiator for programmes operating in schools, community centres, or regions with unreliable mobile data. By eliminating dependency on a live network connection for core reporting features, the product delivers a consistent, professional user experience that increases daily engagement and reduces user frustration. Automatic cache invalidation triggered by push notifications ensures users always see fresh data when connectivity is restored, maintaining trust in the accuracy of the information presented and reducing support queries about stale content.
The Summary Cache Repository is a low-complexity mobile component with delivery effort primarily in integrating with the app's existing offline persistence layer — likely SQLite, AsyncStorage, or a typed ORM such as WatermelonDB depending on the stack. The main scheduling dependency is on the push notification pipeline being functional before end-to-end cache invalidation can be tested. QA must cover offline scenarios: launching the app with no connectivity, receiving a push notification while offline and then going online, and clearing stale summaries across period boundaries. Edge cases include handling cache misses gracefully in the UI and ensuring `clearStaleSummaries` does not purge data that is still within the current period due to timezone differences.
Risk is low overall but offline testing requires physical devices or robust emulator configuration.
The Summary Cache Repository is a mobile-only data component wrapping the app's local persistence layer to store and retrieve `periodic-summary` records. Its four interfaces — `cacheSummary`, `getCachedSummary`, `invalidateCache`, and `clearStaleSummaries` — map to standard cache lifecycle operations. Storage keys should be namespaced by `(userId, periodType)` to support multiple users on shared devices. `invalidateCache` should be called from the push notification handler immediately on receipt, followed by a refetch from the API.
`clearStaleSummaries` accepts a `currentPeriod` object and should delete records where the stored period key does not match the current period, using careful boundary logic to avoid off-by-one errors at period transitions. Serialisation of the summary object must handle all optional fields gracefully. Consider a TTL-based fallback for cases where push notifications are not delivered.
Responsibilities
- Persist summary data locally for offline access
- Retrieve cached summary for display when offline
- Invalidate and refresh cache on push notification receipt
- Clear stale summaries beyond the current period
Interfaces
cacheSummary(summary)
getCachedSummary(userId, periodType)
invalidateCache(userId, periodType)
clearStaleSummaries(currentPeriod)
Relationships
Related Data Entities (1)
Data entities managed by this component