"estado persistente" vs. "estado actual"

Question

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

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

Todavía estoy teniendo dificultades para decidir qué en mi solicitud constituye "estado persistente" frente a "estado actual". Por ejemplo, si bien las preferencias del usuario son claramente persistentes, ¿debo guardarlas en onPause() cuando el marco de la interfaz de usuario de Android siempre las guarda automáticamente cuando el usuario las cambia?

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

Estoy confundido.

¿Puede traer ejemplos del mundo real de lo que debe guardarse en onPause() y lo que debe guardarse en onSaveInstanceState()? Except para cambios en la configuración del dispositivo, es decir.

-

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

• de Bundle onSaveInstanceState es not written to anything, y no es de ninguna manera persistente.
• onSaveInstanceState Bundle datos solo serán held in memory hasta que se cierre la aplicación.

Answer 1

No necesita almacenar las preferencias del usuario en onPause porque, como usted dice, el marco hace eso 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 guardemos esos datos en un archivo, pero sería bueno guardar esos datos para cuando vuelvan. Se trata de datos persistentes y desea almacenarlos en onPause().

datos de estado

Del mismo modo, supongamos que tiene 2 pestañas y una variable que rastrea la ficha que se encuentra actualmente seleccionado. Esto es información de estado que almacenarías en SaveInstanceState().

materia gris

Finalmente imagina que tienes una clase en el editor que realiza un seguimiento del número de caracteres y el número de líneas en el editor. Esto es información de estado, puede almacenarlo en SaveInstanceState() o puede tirarlo y simplemente recalcularlo cuando vuelva a arrancar. Si lo descarta puede depender de cuánto tiempo lleva calcular, por ejemplo, si puede evitar una solicitud de red almacenando datos, hágalo.

pensamientos adicionales

jugando con su aplicación debería ser obvio si hay un área donde usted no pudo ardilla los datos de inmediato. Asegúrate de hacer cosas como presionar el botón de inicio y luego cerrar la aplicación desde el administrador del dispositivo. Esto le permitirá acceder a los casos de esquina donde se cierra su aplicación en lugar de detenerse.

Si su estado de IU es constante en todos los eventos del ciclo de vida y sus datos de usuario permanecen, buen trabajo.

Editar comentario basado en

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

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

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

En general, si lo que desea es devolver al usuario al mismo lugar donde lo dejó, entonces debe pensar en los datos de estado necesarios para volver a ese punto. Imagínese una versión prístina cargado de su aplicación

• qué datos tiene que cambiar a su vez que en el último estado del usuario sierra?
• ¿qué datos necesita almacenar para volver aquí?

Así es como funciona Android, tu actividad se destruye y vuelve a crear y es tu trabajo volver a poner las piezas en movimiento (si decides hacerlo).

Answer 2

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

1) Aplicación de subclases (no es una buena idea). 2) SharedPreferences (bueno para datos simples, rápidos y confiables) 3) Base de datos SQLite (Más compleja, también confiable).

Ahora para responder a su 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 que lo haga. Entonces, si hay datos que es vital para guardar, la respuesta es guárdelo tan pronto como lo obtenga. Generalmente no hay mucha ventaja de guardar algo más tarde, si sabes que vas a necesitar algo, sálvalo de inmediato.

onSaveInstanceState() es solo para guardar variables temporales relacionadas con el diseño o los cambios de orientación.

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

Answer 3

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

Como esto puede tomar un tiempo, no me parece bueno intentar y guardar en , sino en onStop.

De acuerdo con las pruebas que he hecho, onStop parece ser capaz de ejecutar en segundo plano mientras bloques, al menos ese es el caso cuando se presiona el hogar (probado con un sencillo para 1 a 10m bucle en y onStop) . ¿Alguien puede confirmar esta teoría de bloqueo?

onStop NECESIDADES Honeycomb arriba (api11+), porque antes de que la versión que pueden matar antes onClose se llama.

Consulte here y busque killable en la tabla - Si la realidad coincide con la documentación, es otra pregunta :).