¿Cuál es la diferencia entre commit () y apply () en SharedPreferences

Estoy usando SharedPreferencesen mi aplicación de Android. Estoy usando ambos commit()y el apply()método de preferencia compartida. Cuando uso AVD 2.3 no muestra ningún error, pero cuando ejecuto el código en AVD 2.1, el apply()método muestra un error.

Entonces, ¿cuál es la diferencia entre estos dos? ¿Y usando solo commit()puedo almacenar el valor de preferencia sin ningún problema?

apply()se agregó en 2.3, se compromete sin devolver un valor booleano que indica éxito o falla.

commit()devuelve verdadero si el guardado funciona, falso de lo contrario.

apply() se agregó cuando el equipo de desarrollo de Android notó que casi nadie se dio cuenta del valor de retorno, por lo que aplicar es más rápido ya que es asíncrono.

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

tl; dr:

• commit()escribe los datos sincrónicamente (bloqueando el hilo desde el que se llama). Luego le informa sobre el éxito de la operación.
• apply()programa los datos para que se escriban de forma asincrónica . No le informa sobre el éxito de la operación.
• Si guarda con apply()e inmediatamente lee a través de cualquier método getX, ¡se devolverá el nuevo valor!
• Si llamó apply()en algún momento y todavía se está ejecutando, cualquier llamada a commit()se bloqueará hasta que todas las llamadas aplicadas pasadas y la llamada de confirmación actual hayan finalizado.

Más información detallada de SharedPreferences. Documentación del editor :

A diferencia de commit (), que escribe sus preferencias en el almacenamiento persistente de forma síncrona , apply () confirma sus cambios en SharedPreferences en la memoria de forma inmediata, pero inicia una confirmación asíncrona en el disco y no se le notificará ninguna falla . Si otro editor en este SharedPreferences realiza un commit regular () mientras un apply () aún está pendiente, el commit () se bloqueará hasta que se completen todos los commits asíncronos, así como el commit en sí.

Como las instancias SharedPreferences son singletons dentro de un proceso, es seguro reemplazar cualquier instancia de commit () con apply () si ya estaba ignorando el valor de retorno.

No se espera que la interfaz SharedPreferences.Editor se implemente directamente. Sin embargo, si anteriormente lo implementó y ahora está recibiendo errores sobre la falta de apply (), simplemente puede llamar a commit () desde apply ().

Estoy experimentando algunos problemas al usar apply () en lugar de commit (). Como se indicó anteriormente en otras respuestas, el apply () es asíncrono. Tengo el problema de que los cambios formados en una preferencia de "conjunto de cadenas" nunca se escriben en la memoria persistente.

Ocurre si "fuerza la detención" del programa o, en la ROM que he instalado en mi dispositivo con Android 4.1, cuando el sistema elimina el proceso debido a necesidades de memoria.

Recomiendo usar "commit ()" en lugar de "apply ()" si quieres que tus preferencias estén activas.

Utilice apply ().

Escribe los cambios en la RAM de inmediato y espera y lo escribe en el almacenamiento interno (el archivo de preferencias real) después. Commit escribe los cambios sincrónicamente y directamente en el archivo.

• commit()es sincrónico, apply()es asincrónico

• apply() Es una función nula.

• commit() devuelve verdadero si los nuevos valores se escribieron correctamente en el almacenamiento persistente.

• apply() garantías completas antes de cambiar de estado, no necesita preocuparse por los ciclos de vida de los componentes de Android

Si no usa el valor devuelto por commit()y está usando el commit()hilo principal, use en apply()lugar de commit()

Los documentos dan una muy buena explicación de la diferencia entre apply()y commit():

A diferencia commit(), que escribe sus preferencias en el almacenamiento persistente de forma síncrona, apply()confirma sus cambios en la memoria de SharedPreferencesinmediato, pero inicia una confirmación asíncrona en el disco y no se le notificará ninguna falla. Si otro editor en esto SharedPreferenceshace un regular commit()mientras apply()todavía está pendiente, commit()se bloqueará hasta que se completen todas las confirmaciones asíncronas, así como la confirmación misma. Como SharedPreferenceslos casos son únicos dentro de un proceso, que es seguro para reemplazar cualquier instancia de commit()con apply()si ya no tenían en cuenta el valor de retorno.

De javadoc:

A diferencia de commit (), que escribe sus preferencias en el almacenamiento persistente de forma síncrona, apply () confirma sus cambios en SharedPreferences en la memoria de forma inmediata, pero inicia una confirmación asíncrona en el disco y no se le notificará ninguna falla. Si otro editor en este SharedPreferences realiza un commit regular () mientras que> apply () aún está pendiente, el commit () se bloqueará hasta que se completen todos los commits asíncronos, así como el commit en sí

La diferencia entre commit () y apply ()

Podríamos estar confundidos por esos dos términos, cuando estamos usando SharedPreference. Básicamente son probablemente los mismos, así que aclaremos las diferencias de commit () y apply ().

1. Valor de retorno:

apply()se compromete sin devolver un valor booleano que indica éxito o fracaso. commit() devuelve verdadero si el guardado funciona, falso de lo contrario.

2. Velocidad:

apply()es más rápido. commit()es mas lento

3. Asíncrono vs Sincrónico:

apply(): Asíncrono commit(): Sincrónico

4. Atómico:

apply(): atómico commit(): atómico

5. Notificación de error:

apply(): No commit(): Sí