SharedPreference.Editor commit() vs apply()

I know its quiet old now but there is still some doubts about the apply() function of the SharedPreference.Editor. Many of the people still don’t understand the difference between the two and why was there a need to create another method while there was already commit().

Editor’s apply() was introduced in API Level 9 while commit() was from the starting i.e API Level 1. Actually its quiet simple the difference is that apply() is asynchronous while commit is synchronous. So what is Asynchronous and Synchronous?

When you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes. So that it doesn’t block the code execution, hence fast.So how is commit() synchronous and apply() not?

Basically commit() writes the changed SharedPreference value out to persistent storage immediately, on the other hand, apply() write the changes to the in-memory SharedPreference immediately and starts an asynchronous commit to disk. That is why in case of apply() you will not get notified of the failure or success of your changes like in commit() which returns you the status of your changes. But I guess many of us never really bothered what its returning , but if you do so for you commit() is still there and hence not deprecated. Even if you call a commit() after apply(), its safe because all the commit calls will be blocked until the apply()’s commit and the commit()’s commit (you called after apply()) is done.

So the conclusion is that apply() is completely safe. You can use it without worry as you will get updated value of preferences. But if you want a success or failure response do go for commit(). The use differs from person to person and for different requirements.