"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 :).