Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


"Estado persistente" vs. "estado actual"

Intentando decidir (para mi aplicación) qué guardar en onPause () y qué guardar en onSaveInstanceState () , peiné todo el SO para obtener sugerencias y directrices claras.

Si entiendo correctamente, onSaveInstanceState () es el mejor para guardar "cambios de tiempo de ejecución" o "estado actual" (lo que eso significa), mientras que onPause () es mejor para guardar "estado persistente".

Todavía tengo dificultad para decidir qué es lo que en mi solicitud constituye "estado persistente" vs. "estado actual". Por ejemplo, aunque las preferencias de los usuarios son claramente persistentes, ¿necesito guardarlas en onPause() cuando son guardadas automáticamente por el framework de la interfaz de usuario de Android cuando el usuario las cambia?

¿Los miembros de datos de clase deben guardarse en onSaveInstanceState () ? ¿Necesito hacer eso para cada clase en mi aplicación?

Estoy confundido.

¿Puedes traer ejemplos del mundo real de lo que se debe guardar en onPause() y qué se debe guardar en onSaveInstanceState() ? Excepto para los cambios de configuración del dispositivo, es decir.

Algunas nuevas ideas, después de mi pregunta ha sido contestada:

  • El Bundle de onSaveInstanceState no está escrito en nada , y no es persistente de ninguna manera.
  • Los datos del Bundle de onSaveInstanceState sólo se conservarán en la memoria hasta que se cierre la aplicación.

  • ¿Están las opiniones "GONE" infladas?
  • El explorador de archivos DDMS no puede acceder a data \ data (HTC Desire HD)
  • ¿Dónde puedo encontrar el código fuente para las aplicaciones de gmail, facebook y twitter para Android? ¿Son incluso de código abierto?
  • Retrofit 2.0 cómo eliminar?
  • Manifiesto de Android Restringir a las tabletas
  • IDTech Unimag Card Swiper en Android
  • 3 Solutions collect form web for “"Estado persistente" vs. "estado actual"”

    No es necesario almacenar las preferencias del usuario en onPause porque, como usted dice, el framework lo hace por usted.

    Para distinguir entre datos persistentes vs información de estado, piense en una aplicación de editor de texto.

    Datos persistentes

    Digamos que el usuario ha escrito un par de palabras y luego sale de la aplicación. El usuario no nos dijo explícitamente que guardáramos esos datos en un archivo, pero seguro que sería bueno guardar esos datos para cuando regresen. Se trata de datos persistentes y se desea guardarlo en onPause ().

    Datos del estado

    Del mismo modo, digamos que tiene 2 pestañas y una variable que rastrea qué pestaña está seleccionada actualmente. Se trata de datos de estado que se almacenan en onSaveInstanceState ().

    Materia gris

    Finalmente imagina que tienes una clase en el editor que registra el número de caracteres y el número de líneas en el editor. Se trata de datos de estado, se podría almacenar en onSaveInstanceState () o se puede tirar y simplemente recalcularlo cuando se inicia de nuevo. Si lo desechas puede depender del tiempo que tarde en calcular, por ejemplo, si pudieras evitar una solicitud de red almacenando datos, hazlo.

    Pensamientos adicionales

    Al jugar con su aplicación, debería ser obvio si hay un área donde no pudo ardilla los datos correctos de distancia. Asegúrese de hacer cosas como pulsar el botón de inicio y luego cerrar la aplicación desde el administrador de dispositivos. Esto le permitirá golpear los casos de la esquina donde se apaga su aplicación en lugar de simplemente pausado.

    Si su estado de interfaz de usuario es coherente a través de eventos de ciclo de vida y sus datos de usuario permanece, buen trabajo.

    Editar con base en el comentario

    Creo que hay 2 piezas de criterios aquí para determinar cuándo / qué ahorrar.

    La primera es bastante subjetiva – ¿Desea guardar datos en absoluto? Realmente no hay nada que te obligue a guardar el estado o los datos. ¿Guardar esta información contribuirá a una mejor experiencia de usuario? Si está escribiendo un correo electrónico y está intentando copiar / pegar texto de otra aplicación, perder su correo electrónico a medias cada vez que se cierre la aplicación sería frustrante.

    La segunda pieza, determinar qué guardar depende de si puede reconstruir su estado de la interfaz de usuario basándose en los datos que tiene. Por ejemplo, si ha guardado datos de texto, entonces debe significar que el usuario estaba editando texto. Así que ahora sabemos cambiar a la pestaña de edición de texto y rellenar el texto guardado.

    En general, si el deseo es que usted desea devolver al usuario al mismo lugar que dejó, entonces usted necesita pensar en los datos de estado necesarios para volver a ese punto. Imagina una versión cargada de tu aplicación

    • Qué datos necesita cambiar para convertirlo en el último estado que el usuario vio?
    • ¿Qué datos necesita almacenar para volver aquí?

    Esto es realmente cómo funciona android, su actividad es destruida y recreada y es su trabajo para poner las piezas en movimiento de nuevo (si usted elige hacerlo).

    Aquí está la respuesta. Puede guardar el estado de tres formas diferentes.

    1) Subclase de la aplicación (no es una buena idea). 2) SharedPreferences (bueno para los datos simples, rápidos y confiables) 3) Base de datos de SQLite (más complejo, también confiable).

    Ahora para responder a tu pregunta. Realmente no hay garantías con Android. En cualquier momento puede y puede destruir su aplicación sin llamar a ninguna función en particular antes de hacerlo. Así que si hay datos que son vitales para guardar, la respuesta es guardarlo tan pronto como lo obtenga . Por lo general no hay mucha ventaja para ahorrar algo más tarde, si usted sabe que va a necesitar algo guardarlo inmediatamente.

    OnSaveInstanceState () es sólo para guardar variables temporales relacionadas con cambios de diseño o orientación.

    En resumen persistente estado / datos (que deben sobrevivir a un accidente), debe guardarse lo antes posible , no espere a onPause() , porque no hay garantías. Esa es la realidad.

    El caso que tengo es un juego, donde quiero guardar datos persistentes en un servidor de juegos.

    Como esto puede tomar un rato, no encuentro una cosa buena intentar y ahorrar en onPause , sino en onStop .

    De acuerdo con las pruebas que he hecho, onStop parece ser capaz de ejecutar en segundo plano mientras onPause bloquea, atleast que es el caso cuando onPause casa (probado con un simple para 1 a 10m loop en onPause y onStop ). ¿Puede alguien confirmar esta teoría de bloqueo?

    onStop NECESITA Honeycomb up ( api11+ ), porque antes de esa versión se puede matar antes de que onClose se llame.

    Vea aquí y busque killable en la tabla – Si la realidad coincide con la documentación es otra pregunta :).

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.