search

patrickfav / armadillo

A shared preference implementation for confidential data in Android. Per default uses AES-GCM, BCrypt and HKDF as cryptographic primitives. Uses the concept of device fingerprinting combined with optional user provided passwords and strong password hashes.
https://favr.dev/opensource/armadillo
Apache License 2.0
280 stars 52 forks source link

Update README.md #38

Closed erlangparasu closed 5 years ago

patrickfav commented 6 years ago

Hi erlangp,

Thanks for the PR. Could you please explain the rational why you think using apply() in the code example is less applicable than commit()?

erlangparasu commented 6 years ago

because apply is async, sir.. the sp may not saved yet to get the saved string..

MarkVillacampa commented 5 years ago

I think it's safe to use apply() instead of commit() if you are ignoring the return value, as per the documentation:

Unlike commit(), which writes its preferences out to persistent storage synchronously, apply() commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.

As SharedPreferences instances are singletons within a process, it's safe to replace any instance of commit() with apply() if you were already ignoring the return value.

You don't need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.

https://developer.android.com/reference/android/content/SharedPreferences.Editor#apply()