AAttendrix Docsv1.0
Architecture
ExplanationImplemented

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:

Mobile Application Startup Sequence
Sequence / Flow
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
    end

Tiered Cache Hierarchy & TTL Matrix

To minimize unnecessary network calls on cellular data, sync_app_data.dart enforces strict Time-To-Live (TTL) intervals:

Data EntityCache KeyTTL DurationInvalidation Trigger
Dashboard Classes_dashboardTtl3 MinutesDay change, manual pull-to-refresh, class cancellation report.
Calendar Schedule_calendarTtl10 MinutesDate selector change, manual sync.
Missed Classes / Absences_missedTtl15 MinutesMarking or unmarking an absence (markAbsent).
Student Profile & Enrollments_profileTtl30 MinutesElective course changes, profile edit.
User Preferences_userPrefsTtl30 MinutesPreference screen save (updateUserPreferences).
Dining Mess Menu_messTtl14 DaysSemester change, manual reload.
Bus Transit Schedules_busTtl14 DaysRoute revision, manual reload.
Campus Routing Matrix_routingTtlVersion-LockedIncremented 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:

  1. Immediate Local Mutation: The client decrements local attendance count and flips is_absent = true in FFAppState. The UI reflects the change in 0ms.
  2. Background RPC Dispatch: The client issues the mark_absent RPC call to PostgREST.
  3. Rollback on Error: If the network times out or the server rejects the request (e.g. CLASS_CANCELLED), the client reverts FFAppState to its pre-mutation snapshot and presents an explanatory alert toast.

Was this page helpful?

Your feedback directly guides the engineering documentation roadmap.

On this page