PreferencesService
Component Detail
Description
Orchestrates reading and writing of user preferences, coordinating between the local repository and the remote backend so that preferences are consistent across reinstalls and device migrations. It handles optimistic local writes followed by background sync, and exposes a simple key-value API to the UI layer. Conflict resolution favours the most recently updated value.
preferences-service
Sources & reasoning
The source explicitly lists Settings as a named screen type and specifies hamburger menu access as the entry point. The design token system requirement at line 305 confirms the settings surface must honour accessibility constraints. Blueprint marks this MVP and all workshop organizations expect standard app configurability from launch. Fase 1 core mobile scope implies MVP delivery with no later phase evidence.
-
docs/source/likeperson.md · line 292Settings accessible from hamburger menu
-
docs/source/likeperson.md · line 300Settings and preferences
-
docs/source/likeperson.md · line 305Design token system (colors, typography, spacing, radii, sizing) - WCAG 2.2 AA compliant
Responsibilities
- Read preferences from PreferencesRepository and expose them to callers
- Write preference changes locally and trigger background sync to backend
- Handle sync conflicts by applying last-write-wins resolution
- Restore preferences from backend after reinstall or device migration
- Validate preference values against allowed types and ranges before persisting
Interfaces
getPreferences(): Promise<UserPreferences>
updatePreference(key: string, value: unknown): Promise<void>
syncToBackend(): Promise<void>
restoreFromBackend(): Promise<UserPreferences>