¿Necesito restaurar todas las variables onResume?

Tuve mala experiencia con variables de clase estática ya que sus valores se pierden cuando la clase descarga.

Las clases no "descargan". Su proceso se terminará en algún momento después de que no tenga nada en primer plano, cuando Android necesita recuperar la memoria.

¿Puedo confiar en que las variables mantienen sus valores al 100%? O puedo asegurar algún tipo de restauración válida para todas las variables de actividad?

Las actividades se notifican cuando se trasladan del primer plano mediante una llamada a onPause() . Desde el punto de vista de esa actividad, en cualquier momento después de onPause() hasta (posiblemente) un onResume() correspondiente, el proceso puede ser terminado y la actividad se pierde.

Usted necesita sentarse y pensar en su modelo de datos. Suponga que el usuario abandona su aplicación (por ejemplo, presiona HOME) y no regresa a su aplicación durante una hora, un día o un mes. Cualquier dato que el usuario razonablemente espera que permanezca durante ese período de tiempo necesita ser guardado en un almacén de datos persistente , como una base de datos o un archivo plano. Es su tarea determinar cuándo se guardan los datos: tal vez es cuando el usuario pulsa un botón Guardar, o tal vez está en onPause() de una actividad, o tal vez en algún otro momento.

Los datos que están vinculados al contenido actual de la pantalla, pero no necesitan ser guardados durante un mes de ausencia, pueden mantenerse a través de onSaveInstanceState() . Esperamos que ya esté utilizando esto para manejar rotaciones de pantalla. Si es así, y si el usuario deja su actividad, pero de una manera por la cual puede navegar de nuevo a ella a través del botón ATRÁS (por ejemplo, una llamada telefónica entra, entonces un mensaje de texto entra, luego hacen clic en un enlace en un Mensaje de texto y abrir el explorador Web, y luego BACK todo el camino de regreso a su aplicación, que se había terminado mientras tanto), el estado de la instancia guardada se restaurará.

Todo lo demás – los miembros de datos de instancia de una actividad, o miembros de datos estáticos, o lo que sea – se pueden perder si el usuario deja la aplicación, si Android elige terminar el proceso. Por lo tanto, los miembros de datos estáticos normalmente sólo se utilizan para cachés de corto plazo o para cosas que no importan si se pierden cuando el usuario presiona HOME o toma una llamada telefónica o lo que sea.

Si tiene datos en su actividad que deben guardarse, implemente onSaveInstanceState.

http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle )

En su onCreate, si el paquete pasó en no es nulo, puede asumir que había algún estado guardado en allí, y restaurar de eso.

Las variables normales persisten, pero el problema es que nunca se puede estar seguro cuando estás enResuming y cuando estás onCreating (ya que no tienes control sobre cuando Android sólo va y sacude cosas en la pila por la ventana … nada no Que se utiliza actualmente es apto para la destrucción).

Así que … lo mejor es guardar las cosas de cualquier forma que tenga sentido si REALMENTE las necesita entre lugares en los que alguien podría poner el dispositivo de forma lógica para dormir, o rotarlo, o recibir una llamada telefónica o cualquier otra cosa que interrumpa su TOP (Ness).

Realmente no me gusta la forma en que funciona el paquete, por lo que he estado almacenando mis cosas en un JSONobject que convertir a cadena y sólo guardar como una cadena de SharedPreference plana (tenga en cuenta que SP persiste para siempre, mientras que su Bundle va a Ser lanzado junto con todo lo demás una vez que su aplicación es GCed). De esa manera puedo agarrarlo cuando quiera, en lugar de tener que jugar con mil millones de elementos de Bundle diferentes, pero eso es obviamente una cuestión de gusto. Hay un poco más de trabajo por adelantado y, por supuesto, un poco más de gastos generales en la serialización / deserialización, pero como sólo ocurre en la rara ocasión en que se destruyen mis variables, realmente no es de lo que preocuparse (a menos que tenga cantidades masivas De datos, en cuyo caso debe estar utilizando una base de datos, de todos modos).