Similarities and differences between the apply and commit methods of Sharedpreference.editor

From http://blog.csdn.net/jake9602/article/details/18414841

In the Android storage data often with sharedpreference, and in the submission of data has been used in the editor of the Commit method, today no intention to see the system with apply, read the introduction of the method, the original method is also able to submit data.

The Apply method is described in the official SDK as follows:

Commit your preferences changes back from this Editor to the Sharedpreferences object it is editing. This atomically performs the requested modifications, replacing whatever are currently in the sharedpreferences.

Note that when both editors is modifying preferences at the same time, the last one to call apply wins.

Unlike commit, which writes its preferences off to persistent storage synchronously, apply commits it changes to the IN-M Emory Sharedpreferences immediately but starts a asynchronous commit to disk and you won ' t is notified of any failures. If another editor on this sharedpreferences does a regular commit while a apply is still outstanding, the commit would bloc K until all async commits is completed as well as the commit itself.

As Sharedpreferences instances is singletons within a process, it's safe to replace any instance of commits 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.

The Sharedpreferences.editor interface isn ' t expected to be implemented directly. However, if you previously did implement it and is now getting errors about missing apply (), you can simply call commit F Rom apply ().

The difference between the two methods is:
1. Apply does not return a value and a commit returns a Boolean indicating whether the change was committed successfully
2. Apply is to commit the modified data atoms to memory, and then asynchronously commit to the hardware disk, and commit is synchronous commit to the hardware disk, so, in multiple concurrent commit commit, they will wait for the commit to be processed after saving to disk in the operation, thereby reducing the efficiency. While apply is only the atomic commit to the content, the subsequent call to apply the function will directly overwrite the previous memory data, which to a certain extent, improve a lot of efficiency.
3. The Apply method does not prompt for any failed prompts.
Because in a process, sharedpreference is a single instance, there is no concurrency conflict, if you do not care about the results submitted, it is recommended to use apply, of course, you need to ensure that the submission is successful and follow-up, or need to use a commit.

Similarities and differences between the apply and commit methods of Sharedpreference.editor