DataStore-backed UserPreferences #4

New Issue

Closed

opened 2026-08-18 02:14:37 -05:00 by null · 0 comments

null commented

2026-08-18 02:14:37 -05:00

Owner

Build core/datastore with a typed UserPreferences over DataStore Preferences, exposed as a Flow.

Two constraints that matter more than they look:

Preferences do not go in the cycle database. Different lifetime, different sensitivity, different deletion semantics — Delete My Data must be able to remove the health history without resetting the user's notification privacy choice to the default.
Notification privacy defaults to Discreet (§28). A default of Direct would leak on a lock screen before the user has been asked anything, which is the most likely real breach in this product.

Verify: ./gradlew :core:datastore:test passes, a changed preference survives a force-stop and relaunch, and a fresh install reads NotificationPrivacy.DISCREET without any value having been written.

Settings have nowhere to live. Notification privacy mode, reminder time, the per-type reminder toggles, biometric lock, theme and the ads-removed entitlement are all named in PRODUCT_PLAN.md §10 and none of them are stored. Build `core/datastore` with a typed `UserPreferences` over DataStore Preferences, exposed as a `Flow`. Two constraints that matter more than they look: - **Preferences do not go in the cycle database.** Different lifetime, different sensitivity, different deletion semantics — Delete My Data must be able to remove the health history without resetting the user's notification privacy choice to the default. - **Notification privacy defaults to Discreet** (§28). A default of Direct would leak on a lock screen before the user has been asked anything, which is the most likely real breach in this product. Verify: `./gradlew :core:datastore:test` passes, a changed preference survives a force-stop and relaunch, and a fresh install reads `NotificationPrivacy.DISCREET` without any value having been written.