What's the difference between commit() and apply() in SharedPreferences_问答_开发者

I am using SharedPreferences in my android app. I am using both commit() and apply() method from shared preference. When I use AVD 2.3 it shows no error, but when I run the code in AVD 2.1, apply()开发者_StackOverflow method shows error.

So what's the difference between these two? And by using only commit() can I store the preference value without any problem?

apply() was added in 2.3, it commits without returning a boolean indicating success or failure.

commit() returns true if the save works, false otherwise.

apply() was added as the Android dev team noticed that almost no one took notice of the return value, so apply is faster as it is asynchronous.

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

tl;dr:

commit() writes the data synchronously (blocking the thread its called from). It then informs you about the success of the operation.
apply() schedules the data to be written asynchronously. It does not inform you about the success of the operation.
If you save with apply() and immediately read via any getX-method, the new value will be returned!
If you called apply() at some point and it's still executing, any calls to commit() will block until all past apply-calls and the current commit-call are finished.

More in-depth information from the SharedPreferences.Editor 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.

The SharedPreferences.Editor interface isn't expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call commit() from apply().

I'm experiencing some problems using apply() instead commit(). As stated before in other responses, the apply() is asynchronous. I'm getting the problem that the changes formed to a "string set" preference are never written to the persistent memory.

It happens if you "force detention" of the program or, in the ROM that I have installed on my device with Android 4.1, when the process is killed by the system due to memory necessities.

I recommend to use "commit()" instead "apply()" if you want your preferences alive.

Use apply().

It writes the changes to the RAM immediately and waits and writes it to the internal storage(the actual preference file) after. Commit writes the changes synchronously and directly to the file.

commit() is synchronously, apply() is asynchronous
apply() is void function.
commit() returns true if the new values were successfully written to persistent storage.
apply() guarantees complete before switching states , you don't need to worry about Android component lifecycles

If you dont use value returned from commit() and you're using commit() from main thread, use apply() instead of commit()

The docs give a pretty good explanation of the difference between apply() and commit():

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.

The difference between commit() and apply()

We might be confused by those two terms, when we are using SharedPreference. Basically they are probably the same, so let’s clarify the differences of commit() and apply().

1.Return value:

apply() commits without returning a boolean indicating success or failure. commit() returns true if the save works, false otherwise.

Speed:

apply() is faster. commit() is slower.

Asynchronous v.s. Synchronous:

apply(): Asynchronous commit(): Synchronous

Atomic:

apply(): atomic commit(): atomic

Error notification:

apply(): No commit(): Yes

From javadoc:

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

While working with a web API I noticed the main shortcomings for apply() when using shared preferences before logging out.

Behold the following scenario: User logs in and token (for automatic relogging) was passed with the POST.

SharedPreferences preferences = App.getContext().getSharedPreferences("UserCredentials", Context.MODE_PRIVATE);

SharedPreferences.Editor editor = preferences.edit();

editor.putString("TOKEN",token);

editor.apply();

Token is available throughout all sessions, no problem and automatic relogging is done without any further problems throughout the states.

While writing the logout function I cleared the shared preferences as follows

SharedPreferences preferences = App.getContext().getSharedPreferences("UserCredentials", Context.MODE_PRIVATE);

SharedPreferences.Editor editor = preferences.edit();

editor.clear();

editor.apply()

In short you could simply write as:

preferences.edit().clear().apply()

To make sure I cleared the cache I would Log before logging out, and preferences.getString("TOKEN"); showed as null.

After restarting the main activity (as it started with a login fragment) - I would check the token again, using:

SharedPreferences preferences = App.getContext().getSharedPreferences("UserCredentials", MODE_PRIVATE);
        
String retrievedToken = preferences.getString("TOKEN",null); // Second param = default value

Log.d(TAG, "RETRIEVING TOKEN: " + retrievedToken);

The token actually re-appeared, even though the token was most certainly cleared before logging out.

(Causing a logout -> 'login-using-token loop)

Only after adding editor.commit(); to both setting and clearing the token would actually be permanently gone.

Do note, I used an emulator.

This behavior actually makes sence, as the in-memory storage is updated but the async call never made it before the app was restarted.

Therefor commit(); would FORCE the app to wait (synchronously) with actual subsequent commands like system.exit() etcetera, while apply() could very well fail if other commands would force a certain state change in the app.

To make sure you hit all the right spots, you can always use apply() & commit() both subsequently.