savedinstancestate practices developers best activity android android-activity restore android-lifecycle

android - practices - public void oncreate bundle savedinstancestate



¿Cuándo se llaman exactamente onSaveInstanceState() y onRestoreInstanceState()? (5)

La siguiente figura (del documento oficial ) describe el conocido ciclo de vida de una actividad de Android:

Por otro lado, cuando el sistema destruye la actividad (por ejemplo, porque la memoria necesita ser recuperada), el estado de la actividad a veces se guarda y restaura automáticamente mediante los métodos en onSaveInstanceState() y onRestoreInstanceState() , como se ilustra por la siguiente figura (también del documento oficial ):

Soy consciente de que onSaveInstanceState() no siempre se onSaveInstanceState() cuando una actividad está a punto de destruirse. Por ejemplo, si se destruye porque el usuario ha presionado el botón "Atrás", el estado de la actividad no se conserva. Pero en los casos en que se guarda y se restaura el estado, y se onSaveInstanceState() / onRestoreInstanceState() , ¿ cuándo se llaman exactamente ?

Por ejemplo, de acuerdo con las figuras anteriores, onRestoreInstanceState() podría llamarse before onStart() , o después de onStart() pero antes onResume() , o después de onResume() . Del mismo modo, existen varias posibilidades para onSaveInstanceState() . Entonces, ¿cuándo se llaman exactamente?

Idealmente, lo que me gustaría es ver un diagrama combinado que muestre los estados del ciclo de vida de la actividad y los métodos de guardar / restaurar , si eso existe.


Además de las respuestas ya publicadas, hay un cambio sutil introducido en Android P, que es:

void onSaveInstanceState (Bundle outState)

Si se llama, este método se producirá DESPUÉS de onStop() para las plataformas de orientación de aplicaciones que comienzan con P. Para las aplicaciones que se dirigen a versiones de plataforma anteriores, este método se realizará antes de onStop() y no existen garantías sobre si ocurrirá antes o después de onPause() .

En cuanto a por qué se está introduciendo este cambio, esta es la respuesta:

... por lo que una aplicación puede realizar de manera segura transacciones de fragmentos en onStop() y podrá guardar el estado persistente más tarde.

Fuente: docs


Esta es una información adicional para onSaveInstanceState (Bundle)

docs

No confunda este método con las devoluciones de llamada del ciclo de vida de la actividad, como onPause (), que siempre se invoca cuando una actividad se coloca en segundo plano o en camino a la destrucción, o onStop () que se llama antes de la destrucción. Un ejemplo de cuando se llama a OnPause () y onStop () y no a este método cuando un usuario navega desde la actividad B a la actividad A: no hay necesidad de invocar aSaveInstanceState (Bundle) en B porque esa instancia particular nunca se restaurará , por lo que el sistema evita llamarlo. Un ejemplo cuando se llama onPause () y no onSaveInstanceState (Bundle) es cuando se inicia la actividad B frente a la actividad A: el sistema puede evitar llamar aSaveInstanceState (Bundle) en la actividad A si no se elimina durante la vida de B desde el estado de la interfaz de usuario de A permanecerá intacto.

Por lo tanto, es una implementación predeterminada para ...

La implementación predeterminada se ocupa de la mayor parte del estado de UI por instancia llamando a onSaveInstanceState () en cada vista en la jerarquía que tiene un id, y guardando el id de la vista actualmente enfocada (todo lo cual es restaurado por el implementación predeterminada de onRestoreInstanceState (Bundle)). Si anula este método para guardar información adicional no capturada por cada vista individual, es probable que desee llamar a la implementación predeterminada, de lo contrario, esté preparado para guardar todo el estado de cada vista usted mismo.


Por la documentation :

void onRestoreInstanceState (Bundle savedInstanceState)

Este método se llama entre onStart() y onPostCreate(Bundle) .

void onSaveInstanceState (Bundle outState)

Si se llama, este método ocurrirá antes de onStop() . No hay garantías sobre si ocurrirá antes o después de onPause() .

No se define cuándo se puede onSaveInstanceState() , la única garantía que tenemos es ese rango.


Según doc1 y doc2

onSaveInstanceState

Antes de Honeycomb, las actividades no se consideraban cancelables hasta después de que se habían pausado, lo que significa que onSaveInstanceState () se llamó inmediatamente antes de OnPause (). Empezando con Honeycomb, sin embargo, se considera que las actividades se pueden cancelar solo después de que se hayan detenido, lo que significa que onSaveInstanceState () se llamará ahora antes que OnStop () en lugar de inmediatamente antes de onPause ().

onRestoreInstanceState

Este método se llama entre onStart () y onPostCreate (Bundle) cuando la actividad se reinicializa desde un estado previamente guardado


String activityState; @Override public void onCreate(Bundle savedInstanceState) { // call the super class onCreate to complete the creation of activity like // the view hierarchy super.onCreate(savedInstanceState); // recovering the instance state if (savedInstanceState != null) { activityState = savedInstanceState.getString(STATE_KEY); } setContentView(R.layout.main_activity); mTextView = (TextView) findViewById(R.id.text_view); }

// Esta devolución de llamada se invoca solo cuando hay una instancia guardada previamente guardada usando // onSaveInstanceState (). Restauramos algún estado en onCreate () mientras que opcionalmente podemos restaurar // otro estado aquí, posiblemente utilizable después de que se haya completado onStart (). // El paquete SavedInstanceState es igual que el usado en onCreate ().

@Override public void onRestoreInstanceState(Bundle savedInstanceState) { mTextView.setText(savedInstanceState.getString(STATE_KEY)); } // invoked when the activity may be temporarily destroyed, save the instance //state here //this method will be called before onstop @Override public void onSaveInstanceState(Bundle outState) { outState.putString(STATE_KEY, activityState); // call superclass to save any view hierarchy super.onSaveInstanceState(outState); }