Registration Preferences Store
Component Detail
Description
Local persistence layer for user-specific registration preferences, specifically the last-used activity type ID. Uses the shared local storage adapter to read and write lightweight key-value preferences that survive app restarts without requiring a network round-trip.
registration-preferences-store
Summaries
The Registration Preferences Store delivers a small but high-impact quality-of-life improvement: peer mentors who repeatedly log the same type of activity no longer need to re-select it every time they open the registration wizard. This reduces friction in the most frequent workflow in the application, saving seconds per interaction that compound into meaningful time savings across hundreds of daily logins. Fewer taps to complete a task means higher completion rates, lower abandonment, and a more professional product experience — all without any server cost, since preferences are stored entirely on-device. It also ensures the experience degrades gracefully with no network dependency.
Registration Preferences Store is a low-complexity component with a single dependency on the shared Local Storage Adapter. Development effort is minimal — the interface is three methods — but it must be coordinated with the activity registration wizard to ensure the preference is written on every successful submission and read during wizard initialisation. The main delivery risk is ensuring `clearPreferences()` is wired into the sign-out and account-switch flows; missing this connection could leak one user's preferences to another on shared devices, which is a data privacy concern worth capturing in the test plan. No backend dependencies means this can be developed and tested in isolation early in the sprint, making it a good candidate for parallelisation.
Registration Preferences Store is a thin key-value wrapper over the shared `local-storage-adapter`, scoped to user registration UX state. It exposes three async methods: `saveLastUsedActivityType()` writes a single string key after a confirmed activity insert; `getLastUsedActivityTypeId()` reads it during wizard boot to pre-populate the activity type picker; and `clearPreferences()` wipes the scoped key set on sign-out. All methods are async to match the `local-storage-adapter` contract, which may use Flutter's `SharedPreferences` or equivalent under the hood. Keep the key namespace prefixed (e.g.
`reg_prefs_`) to avoid collisions with other stores using the same adapter. No serialisation complexity — the stored value is a plain string ID. Ensure `clearPreferences()` is called from the auth sign-out event stream, not just the sign-out UI button, to handle programmatic session expiry.
Responsibilities
- Persist the last-used activity type ID to local storage after each successful registration
- Retrieve the last-used activity type ID on wizard initialisation
- Clear preferences on sign-out or account switch
Interfaces
saveLastUsedActivityType(String activityTypeId) -> Future<void>
getLastUsedActivityTypeId() -> Future<String?>
clearPreferences() -> Future<void>
Relationships
Dependents (2)
Components that depend on this component