¿Por qué se deben confirmar / leer los datos de Android en onPause () – onResume () en lugar de en onStop () – onStart ()?

La documentación sugiere que los datos deben ser comprometidos / leídos en onPause() / onResume() .

Sin embargo, cuando la aplicación ya no está en primer plano, sus estructuras de datos permanecen intactas, lo que sugiere que se podría retrasar la comisión / lectura de datos hasta que la aplicación ya no sea visible, es decir, en onStop() / onStart() . Particularmente desde onStop() se garantiza que se llamará antes onDestroy() .

¿Es acaso el caso de que uno u otro enfoque es adecuado? ¿Es la documentación que da aquí sólo una pauta?

Actualización Suponga que su aplicación es necesaria para guardar datos relativamente importantes, por ejemplo, ediciones en una imagen grande. Uno, entonces, seguramente no escribir / leer en onPause() / onResume() , no sea que la experiencia del usuario se vuelven lentos. En ese caso, en ese caso, elegiría escribir / leer en onStop() / onStart() . ¿Es eso cierto?

El problema con el uso de onStop es que usted no tiene garantías sobre cuándo se llamará ya que lo único seguro es que se llamará antes onDestroy . Si espera hasta onStop para confirmar sus datos, puede que tarde para que otra actividad muestre / utilice cualquiera de esos cambios. Lo mismo se aplica a onStart , es posible que su actividad no tenga que ser reiniciada si sólo estaba en segundo plano, por lo que tendrá datos obsoletos. El uso de onResume y onPause garantiza que sus datos siempre estarán actualizados, los commit se hacen tan pronto como la actividad pasa al fondo y los nuevos datos se cargan tan pronto como se hace visible.

Sí, es sólo una pauta (y generalmente una buena). Depende de usted exactamente cuando desea realizar cambios. Personalmente, como para crear objetos de tienda que permiten una simplificación de bases de datos o SharedPreferences, y cuando se realiza un cambio, comprometo los cambios inmediatamente. Para el almacenamiento de datos simple, esto será rápido e invisible para el usuario. Para grandes conjuntos de datos, esto puede tomar más tiempo, y es posible que desee hacer esas escrituras en un intervalo de tiempo, así como en onPause.

En cuanto a cuándo leer – se puede leer siempre, pero una vez más lee a menudo afectará a la experiencia del usuario, a menos que haya tomado el cuidado de él en otro hilo, como con un AsyncTask.

Para responder más a su actualización: Depende del desarrollador, sin embargo escribiría en onPause() y si es necesario, leer en un hilo separado, probablemente inicializado con onResume() . También puedo escribir los datos en un intervalo programado usando un hilo de Timer , dependiendo de cómo afectaría la experiencia del usuario para la sesión actual, y si sería catastrófico para el teléfono para apagar y perder todos los datos antes de onPause() es llamado.

La verdadera respuesta a esto es, onPause es el único método que se garantiza que se llame antes de que Android pueda destruir su proceso. Si un usuario deja su aplicación para realizar una llamada telefónica, y Android decide cerrar su proceso, es completamente legal para que sólo reciba una llamada onPause. Si no había guardado su estado allí, cuando el usuario pulsa el botón Atrás, terminará recreando su actividad en un estado diferente del que el usuario lo dejó.

  • Cómo establecer el contenido de setSingleChoiceItems en onPrepareDialog?
  • Android: Restaurar la actividad activa mientras se reanuda la aplicación
  • Android: ¿Cómo evito iniciar una actividad que ya está en la pila?
  • Android ActivityManager vs WindowManager
  • Cómo configurar la orientación ContentPage en Xamarin.Forms
  • ¿Cómo conservar el estado del diálogo de fecha y hora en el cambio de orientación?
  • Obtener actividad después de startActivity (Intención i)
  • Método de actividad de llamada desde dentro de un fragmento
  • ¿Cómo funcionan los ciclos de vida de la actividad de Android en relación con la aplicación completa?
  • ¿Es una Actividad = un Contexto?
  • El botón de retroceso de Android no vuelve a la actividad anterior
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.