Hey, I notice update to preferences take around 0-1ms, how is this possible with disc io? If it only updates some memcache, which is only later synchronized to disc async-ly; does it mean its not as durable as a sqlite would?

It is only that fast when calling

apply

. When using

commit

it probably will be slower. When calling

apply

, it applies it first to memory only and then immediately kicks of a background task to properly commit it to local persistent storage.

does it mean its not as durable as a sqlite would

It’s definitely not as durable as sqlite

damn so my state might not be there after process kill?

The chance of your preference data not being committed is very very very small.

but it is there, unlike sqlite, also .. no transactions

Shared Preferences is for user preferences and such, a simple key-value store. It should not be used as a proper db. 🙂

so, youd just rather have one table of one row where the value is json?

Is it for HTTP caching?

not really, think onboarding flow where each screen produces some data and flow collects them

Ah… You could just put it all in memory. But if you want to be able to continue properly after a process kill and restart, then shared preference is good enough. In the very very small chance that the commit didn’t take place, the user would start a step earlier than where they left off.

yes it needs persisting

Ah.. A user-object being created/configured while the user is onboarding. This user-object is then used by the rest of the app after onboarding?

lets say yes, i just made it up, that the model looks mostly like user has settings object, usage stats object, profile details object, etc, 10 of these

You have multiple users supported by your app?

no just one, data is not deep but very wide

multi platform app (Android, iOS ,etc?)

just android apps, lets say app2 doesnt include userProfile

It seems you don’t need relations between the objects… they are just flat objects (documents) pertaining to the app globally to the currently logged in user. With your <prefs> snippet, it looks like that. I’d just store them as string in SharedPreferences, each with a unique key-name. Don’t overthink the non-atomicity of SharedPreferences. When you do

sharedPrefs.edit()
    .putString(USER, user.toJsonString())
    .putString(PROFILE, userProfile.toJsonString())
    ...
    .apply()

Then either the entire change between

edit()

and

apply()

will get committed or not (veeeeeery small chance it’d fail)

oh so if I use the same editor object it will act as a atomic transaction?

Yup. It is not db-grade guarantee (no rollback if something goes truly wrong, some odd exception, veeeery small chance), but good enough.

so would you do that in a multi module world, since my daos basically look like this

SettingsDao.saveSettings(settings: Settings) {
   prefs.edit().putString("settings", settings.toJson()
}
ProfileDao.saveProfile(profile: Profile) {
   prefs.edit().putString("profile", profile.toJson()
}


-....
fun sync() {
    settingsDao.saveSettings(settings)
    profileDao.saveProfile(profile)
}

Why would it crash/throw? If it crashes because there is no storage left on the device to save the prefs…. I’ve never seen that happen.

Idk, some..reason, if it doesn do that, I dont need transactions, dont it?

In other words, don’t start coding for something that is veeeeery unlikely to happen. In theory, a

putString

or an

apply

call to the SharedPreference’s Editor can happen… but it is not worth fretting over.

btw does the size of prefs matter? I do have the odd type that is a large list of products, it never changes, just syncs from time to time

I would create a different SharedPreferences with a different name. SharedPreferences are stored in XML files. They have no real size limit… still…. I’d use different SharedPreference files…

right, but I presume I cannot use the same editor instance to transaction-save all the stuff at once

No, you are correct. They’d use a different

Editor

object.

dammit

If you inject your SharedPreferences instances (or SQLite instances) into your modules, then it would work in multi-module projects. But you can’t (easily) share SharedPReferences nor SQLite dbs across multiple apps.

but each module basically defines a table, as I said Settings object/table lives in :settings module, and it'd need a reference to :user as to reference the user table for fk

Ah… I thought there is only at most one user, not more than one.

there is one user at one time, usual login

Have your modules each implement an interface that has a method that takes an

Editor

and have them make modifications to that editor. Then your app calls those methods for each module with an

Editor

and after all these calls are done, call

apply

on it.

yea that could work, but those products in another prefs would not -.-

And these methods could be to create, change or clear their particular key(s) from the

Editor

that is passed.

well, I dont know -.-, is that fear irrational? 😄

Not irrational, but an app does not maintain a critical db of user-data that is shared between thousands of users 🙂 If the calls to

apply

for some reason throws an exception, your app is in bigger trouble already.

yea true, I dont catch exceptions when reading or write from database, app would just crash, but its also comforting the whole user data would not be there, so user would just re-login