Colton Idle

01/30/2023, 12:22 AM
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


01/30/2023, 1:18 AM
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

01/30/2023, 8:29 AM
Hmm so that’d be saving everything inside a
as a String right? Could even do it with the proto Datastore I guess?


01/30/2023, 8:48 AM
Or bytes really. That's all the PreferencesDataStore does, it provides a Serializer that internally uses a proto definition. No files observable to users.
But a clear contract for users
* 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