Runtime Architecture
Mobile application startup hydration, tiered cache TTLs, and optimistic UI synchronization.
Runtime Architecture
The Attendrix mobile client balances fast perceived performance with database consistency through a multi-tiered cache hierarchy and optimistic user interface updates.
Application Startup Hydration Flow
When the student launches Attendrix, the runtime executes a structured bootstrap sequence defined in syncAppData.dart and loadAppBootstrapStatus.dart:
sequenceDiagram
autonumber
participant App as Flutter Mobile App
participant Cache as Local Storage (FFAppState)
participant Auth as Supabase Auth (GoTrue)
participant PostgREST as Supabase PostgREST
participant OneSignal as OneSignal Flutter SDK
App->>Cache: Read cached UserProfileStruct & EnrolledCourses
alt Cache Valid
App->>App: Render Dashboard UI instantly (0ms)
else Cache Expired / Empty
App->>App: Render Skeleton Loader
end
App->>Auth: Verify JWT Session
alt Session Valid
App->>OneSignal: Initialize SDK & acquire Subscription ID
OneSignal-->>App: Return Subscription ID
App->>PostgREST: Call register_device(subscription_id)
App->>PostgREST: Call syncAppData(force: false)
PostgREST-->>App: Return updated classes, attendance, preferences
App->>Cache: Update FFAppState & reset TTL timestamps
App->>App: Re-render UI with latest server state
else Session Expired
App->>Auth: Attempt refresh_token exchange
alt Refresh Failed
App->>App: Navigate to /login
end
endTiered Cache Hierarchy & TTL Matrix
To minimize unnecessary network calls on cellular data, sync_app_data.dart enforces strict Time-To-Live (TTL) intervals:
| Data Entity | Cache Key | TTL Duration | Invalidation Trigger |
|---|---|---|---|
| Dashboard Classes | _dashboardTtl | 3 Minutes | Day change, manual pull-to-refresh, class cancellation report. |
| Calendar Schedule | _calendarTtl | 10 Minutes | Date selector change, manual sync. |
| Missed Classes / Absences | _missedTtl | 15 Minutes | Marking or unmarking an absence (markAbsent). |
| Student Profile & Enrollments | _profileTtl | 30 Minutes | Elective course changes, profile edit. |
| User Preferences | _userPrefsTtl | 30 Minutes | Preference screen save (updateUserPreferences). |
| Dining Mess Menu | _messTtl | 14 Days | Semester change, manual reload. |
| Bus Transit Schedules | _busTtl | 14 Days | Route revision, manual reload. |
| Campus Routing Matrix | _routingTtl | Version-Locked | Incremented routing_dataset_versions.version. |
Optimistic UI Updates & Rollback Lifecycle
When a student toggles their attendance status (e.g. marking an absence via markAbsent), waiting for server confirmation introduces noticeable latency. Attendrix uses optimistic UI updates:
- Immediate Local Mutation: The client decrements local attendance count and flips
is_absent = trueinFFAppState. The UI reflects the change in 0ms. - Background RPC Dispatch: The client issues the
mark_absentRPC call to PostgREST. - Rollback on Error: If the network times out or the server rejects the request (e.g.
CLASS_CANCELLED), the client revertsFFAppStateto its pre-mutation snapshot and presents an explanatory alert toast.
Was this page helpful?
Your feedback directly guides the engineering documentation roadmap.