The whole idea of having async-only API for app preferences seems very strange to me. Async APIs are great for getting info from network or large datasets from DB, but not for this use case. Most of the time we need to check preference value at a specific point of code execution, not to subscribe to any future changes. And synchronous access is crucial in many cases: to prevent race conditions in business logic, to set app theme in Activity.onCreate(), etc. Instead of providing out-of-the box user-friendly API like StateFlow (which supports synchronous reads), you explicitly discourage `dataStore.data.stateIn()`, on a pretext that it "would invalidate DataStore's guarantee of data consistency". What does that mean really? If `data` itself is consistent, and resulting StateFlow is a single source of truth for the app, where does inconsistency come from? Another major pain point: DataStore requires A LOT of boilerplate. 120+ lines of code in UserPreferencesRepository for two preferences is just ridiculous. Adding new preference would require changing code in at least four different places, not to mention launching more coroutines for reads and writes at call sites. There are alternative approaches, which in my opinion are easier to use and better-scaling: 1. Good old Shared Preferences plus Kotlin delegates (write your own or use ready-made ones, e.g. github.com/NaluLabs/prefs-delegates). The result is type-safe and concise: each property declaration with default value takes 1 line, reading or writing at call site takes 1 line. Great for most cases, thread-safe, but does not provide transactional guarantees (like atomic increments) or support complex/custom data types without additional work. 2. StateFlow holding a data class, plus a coroutine that observes it in background and saves to disk as JSON, plus an initializer which reads this JSON at app startup. Needs JSON serializer (or a specialized library like github.com/erdo/persista), but many apps have it anyway. Type-safe and scalable: each property declaration with default value takes 1 line, reading at call site takes 1 line, writing typically takes 1 line. Supports complex/custom data types & subscribing to updates out-of-the-box. With new MutableStateFlow.update() it is completely (transactionally) thread-safe. Second approach looks similar to "DataStore with Kotlin serialization", but the latter brings additional library, complexity and ceremony without any visible benefits.
Does anyone saw Google publishing internal spec of implementation? Basically, is DataStore uses in-memory key-value map (as Shared preferences) for quick access or performs IO on every value request.
Maybe your use case just doesn't bring it up, or you're at risk of these problems and just haven't noticed. I have experienced these issues, and datastore would be nice support to these issues. SP is also limited, especially when it comes to complex data types
@@rmdanali Exactly the point. If you want this functionality, you'll have to use a DB (which is over kill) or get a third party dependency that's built on top of SP to support Document type storage.
Perfect timing, I'm just at the point where I need to implement shared preferences in my app. Time to use data store instead!
Nice vid. It was really clear and concise. Time to start using proto datastore! Looking forward to the other videos in the playlist
will migrate to DS only if it will have SecuredSharedPreferences like implementation out of the box.
Okay. Great to learn here. I will watch again twice more since I'm new. Thanks for sharing your knowledge.
What is still missing in DataStore is Encryption and support for multi process. Do we plan on add them, in the future version?
And you can't just easily read value from prefs. This is the biggest issue for me. Encryption would be also nice.
@@ZoranSmilevski there's also Proto DataStore, if you don't find Prefs straightforward. This will be covered in the following episodes :)
@@anomissim Looking forward to :)
It's here for anyone else looking: ruclips.net/video/S10ci36lBJ4/видео.html
Time to share this - super useful, palatable yet content rich.
The whole idea of having async-only API for app preferences seems very strange to me. Async APIs are great for getting info from network or large datasets from DB, but not for this use case. Most of the time we need to check preference value at a specific point of code execution, not to subscribe to any future changes. And synchronous access is crucial in many cases: to prevent race conditions in business logic, to set app theme in Activity.onCreate(), etc.
Instead of providing out-of-the box user-friendly API like StateFlow (which supports synchronous reads), you explicitly discourage `dataStore.data.stateIn()`, on a pretext that it "would invalidate DataStore's guarantee of data consistency". What does that mean really? If `data` itself is consistent, and resulting StateFlow is a single source of truth for the app, where does inconsistency come from?
Another major pain point: DataStore requires A LOT of boilerplate. 120+ lines of code in UserPreferencesRepository for two preferences is just ridiculous. Adding new preference would require changing code in at least four different places, not to mention launching more coroutines for reads and writes at call sites.
There are alternative approaches, which in my opinion are easier to use and better-scaling:
1. Good old Shared Preferences plus Kotlin delegates (write your own or use ready-made ones, e.g. github.com/NaluLabs/prefs-delegates). The result is type-safe and concise: each property declaration with default value takes 1 line, reading or writing at call site takes 1 line. Great for most cases, thread-safe, but does not provide transactional guarantees (like atomic increments) or support complex/custom data types without additional work.
2. StateFlow holding a data class, plus a coroutine that observes it in background and saves to disk as JSON, plus an initializer which reads this JSON at app startup. Needs JSON serializer (or a specialized library like github.com/erdo/persista), but many apps have it anyway. Type-safe and scalable: each property declaration with default value takes 1 line, reading at call site takes 1 line, writing typically takes 1 line. Supports complex/custom data types & subscribing to updates out-of-the-box. With new MutableStateFlow.update() it is completely (transactionally) thread-safe.
Second approach looks similar to "DataStore with Kotlin serialization", but the latter brings additional library, complexity and ceremony without any visible benefits.
Nice explanation. 👌
Glad you enjoyed the video, Dhanshyam!
Don't forget to check out even more MAD Skills episodes here:
goo.gle/madskills
😎
Does datastore works together with Jetpack security lib? (Encrypted shared pref)
Does anyone saw Google publishing internal spec of implementation?
Basically, is DataStore uses in-memory key-value map (as Shared preferences) for quick access or performs IO on every value request.
How about for multiplatform?
They create problems that do not exist in the apis, because the truth is that none of those mentioned with shared preferences have happened to me
Exactly
Maybe your use case just doesn't bring it up, or you're at risk of these problems and just haven't noticed. I have experienced these issues, and datastore would be nice support to these issues.
SP is also limited, especially when it comes to complex data types
@@rmdanali true
@@theren8311 SP by design and documentation should never be used in complex data types.
@@rmdanali Exactly the point. If you want this functionality, you'll have to use a DB (which is over kill) or get a third party dependency that's built on top of SP to support Document type storage.
သာယာချမ်းမြေ့ပါစေ။
Bete tester od roku 2016 oceňujem
a Ďakujem, Prajem požehnane dni Boh žehnaj,,
Where's encrypted DataStore?
Is Datastore a good option for storing the JWT token or is it better to use the AccountManager class?
Accountmanager is probably better
Super cool 👍
What is this nonsense? Why not fix the things with Android that are actually broken, instead of reinventing stuff that has no need to change.
Is there a storage limit like for sharedprefs?
🇨🇴🧔🏻👍🏼🤝🏼 Saludos desde Colombia.
New version android studio?
Ok it's greatest idea.
Oh dear why do I click on your video like you are a click bait.
Здравствуйте красивая девушка пожалуйста перевод по русскому.с уважением бахтиёр...ёма...
Okay
用mmkv吧...