Quelle est la différence entre commit () et apply () dans SharedPreferences

J'utilise SharedPreferencesdans mon application Android. J'utilise les deux commit()et la apply()méthode de préférence partagée. Lorsque j'utilise AVD 2.3, il ne montre aucune erreur, mais lorsque j'exécute le code dans AVD 2.1, la apply()méthode affiche une erreur.

Alors, quelle est la différence entre ces deux? Et en utilisant uniquement, commit()puis-je stocker la valeur de préférence sans aucun problème?

apply()a été ajouté en 2.3, il valide sans retourner un booléen indiquant un succès ou un échec.

commit()renvoie vrai si la sauvegarde fonctionne, faux sinon.

apply() a été ajouté car l'équipe de développement Android a remarqué que presque personne n'avait remarqué la valeur de retour, donc appliquer est plus rapide car il est asynchrone.

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

tl; dr:

• commit()écrit les données de façon synchrone (bloquant le thread appelé). Il vous informe ensuite du succès de l'opération.
• apply()planifie l'écriture asynchrone des données . Il ne vous informe pas du succès de l'opération.
• Si vous enregistrez avec apply()et lisez immédiatement via n'importe quelle méthode getX, la nouvelle valeur sera retournée!
• Si vous avez appelé apply()à un moment donné et qu'il est toujours en cours d'exécution, tous les appels à commit()seront bloqués jusqu'à ce que tous les appels d'application passés et l'appel de validation en cours soient terminés.

Informations plus détaillées dans la documentation SharedPreferences.Editor :

Contrairement à commit (), qui écrit ses préférences sur le stockage persistant de manière synchrone , apply () valide immédiatement ses modifications dans les SharedPreferences en mémoire, mais démarre une validation asynchrone sur le disque et vous ne serez pas informé des échecs . Si un autre éditeur de ce SharedPreferences effectue un commit () normal alors qu'un apply () est toujours en attente, le commit () se bloquera jusqu'à ce que tous les commit asynchrones soient terminés ainsi que le commit lui-même.

Comme les instances SharedPreferences sont des singletons dans un processus, il est prudent de remplacer toute instance de commit () par apply () si vous ignoriez déjà la valeur de retour.

L'interface SharedPreferences.Editor ne devrait pas être implémentée directement. Cependant, si vous l'avez déjà implémenté et que vous obtenez maintenant des erreurs concernant le manquant apply (), vous pouvez simplement appeler commit () depuis apply ().

Je rencontre des problèmes avec apply () à la place commit (). Comme indiqué précédemment dans d'autres réponses, la méthode apply () est asynchrone. J'obtiens le problème que les modifications apportées à une préférence "jeu de chaînes" ne sont jamais écrites dans la mémoire persistante.

Cela se produit si vous "forcez la détention" du programme ou, dans la ROM que j'ai installée sur mon appareil avec Android 4.1, lorsque le processus est tué par le système en raison de besoins en mémoire.

Je recommande d'utiliser "commit ()" à la place de "apply ()" si vous voulez que vos préférences soient vivantes.

Utilisez Appliquer ().

Il écrit les modifications dans la RAM immédiatement et attend et les écrit dans la mémoire interne (le fichier de préférence réel) après. Commit écrit les modifications de manière synchrone et directe dans le fichier.

• commit()est synchrone, apply()est asynchrone

• apply() est une fonction nulle.

• commit() renvoie true si les nouvelles valeurs ont été correctement écrites sur le stockage persistant.

• apply() garanties complètes avant de changer d'état, vous n'avez pas à vous soucier des cycles de vie des composants Android

Si vous n'utilisez pas la valeur renvoyée par commit()et que vous utilisez à commit()partir du thread principal, utilisez apply()au lieu de commit()

Les documents donnent une assez bonne explication de la différence entre apply()et commit():

Contrairement à commit(), qui écrit ses préférences sur le stockage persistant de manière synchrone, apply()valide SharedPreferencesimmédiatement ses modifications dans la mémoire mais démarre une validation asynchrone sur le disque et vous ne serez pas informé des échecs. Si un autre éditeur à ce sujet SharedPreferenceseffectue une opération régulière commit()alors que a apply()est toujours en attente, le commit()bloc se bloquera jusqu'à ce que toutes les validations asynchrones soient terminées ainsi que la validation elle-même. Comme les SharedPreferencesinstances sont des singletons dans un processus, il est sûr de remplacer n'importe quelle instance de commit()avec apply()si vous ignoriez déjà la valeur de retour.

De javadoc:

Contrairement à commit (), qui écrit ses préférences sur le stockage persistant de manière synchrone, apply () valide immédiatement ses modifications dans les SharedPreferences en mémoire, mais démarre une validation asynchrone sur le disque et vous ne serez pas informé des échecs. Si un autre éditeur de ce SharedPreferences effectue un commit () normal alors qu'un> apply () est toujours en attente, le commit () se bloquera jusqu'à ce que tous les commit asynchrones soient terminés ainsi que le commit lui-même

La différence entre commit () et apply ()

Nous pouvons être confondus par ces deux termes, lorsque nous utilisons SharedPreference. Fondamentalement, ils sont probablement les mêmes, alors clarifions les différences de commit () et apply ().

1. valeur de retour:

apply()valide sans renvoyer un booléen indiquant un succès ou un échec. commit() retourne vrai si la sauvegarde fonctionne, faux sinon.

2. La vitesse:

apply()est plus rapide. commit()est plus lent.

3. Asynchrone vs synchrone:

apply(): Asynchrone commit(): synchrone

4. Atomique:

apply(): atomique commit(): atomique

5. Notification d'erreur:

apply(): Non commit(): oui