android-datastore-preferenceslisted

# Android DataStore and Preferences ## Core Principles - Use DataStore for small local settings and preference-like state. - Do not use DataStore as a database or cache for large relational data. - Persist only data that should survive process death and app restarts. - Expose typed models to the rest of the app, not raw preference keys. - Keep storage details inside the data layer. --- ## When to Use DataStore Good fits: - theme mode - onboarding completed flag - sort/filter preferences - selected app language - lightweight session-adjacent non-sensitive flags Bad fits: - large lists of entities - search indexes - offline sync source of truth - highly relational or query-heavy data Use Room for structured app data. See the **android-room-database** skill. --- ## Preferences vs Proto DataStore | Need | Preferred option | |---|---| | Simple key/value settings | Preferences DataStore | | Strong schema and typed persistence | Proto DataStore | | Cross-team/shared contract that should evolve safely | Proto DataStore | Default to Preferences DataStore unless the settings model is large enough or important enough to benefit from a defined schema. --- ## Module Ownership Common placements: ```text :core:data -> shared DataStore factory and generic helpers :core:auth -> secure/session-adjacent non-token local state if needed :feature:<name>:data -> feature-specific preference repositories ``` If settings are shared app-wide, kee