datastore was such a pain to get setup correctly in another side project i had (i guess because of t...

# squarelibraries

[Colton Idle]

datastore was such a pain to get setup correctly in another side project i had (i guess because of the protobuf compile time stuff?) but datastore with moshi is interesting... hmmm. i didn't know that was an option.

I'll likely go with moshi +okio + AtomicFile as a nice quick solution

[yschimke]

Datastores serialised is just T <=> Input/OutputStream. It will nicely solve all the atomicity issues, well defined guarantees. And can be literally any serialise code.

[Stylianos Gakis]

Hmm so that’d be saving everything inside a Datastore<Preferences> as a String right? Could even do it with the proto Datastore I guess?

[yschimke]

Or bytes really. That's all the PreferencesDataStore does, it provides a Serializer that internally uses a proto definition. No files observable to users.

[yschimke]

But a clear contract for users

[yschimke]

* DataStore provides a safe and durable way to store small amounts of data, such as preferences
 * and application state. It does not support partial updates: if any field is modified, the whole
 * object will be serialized and persisted to disk. If you want partial updates, consider the Room
 * API (SQLite).
 *
 * DataStore provides ACID guarantees. It is thread-safe, and non-blocking. In particular, it
 * addresses these design shortcomings of the SharedPreferences API:
 *
 * 1. Synchronous API encourages StrictMode violations
 * 2. apply() and commit() have no mechanism of signalling errors
 * 3. apply() will block the UI thread on fsync()
 * 4. Not durable – it can returns state that is not yet persisted
 * 5. No consistency or transactional semantics
 * 6. Throws runtime exception on parsing errors
 * 7. Exposes mutable references to its internal state