Comprender el setRetainInstance de Fragment (boolean)

Comenzando con la documentación:

public void setRetainInstance (retención booleana)

Controle si una instancia de fragmento se retiene a través de la recreación de la actividad (como un cambio de configuración). Esto solo se puede usar con fragmentos que no están en la pila posterior. Si se establece, el ciclo de vida del fragmento será ligeramente diferente cuando se recrea una actividad:

• onDestroy () no se llamará (pero onDetach () aún lo será, porque el fragmento se está separando de su actividad actual).
• onCreate (Bundle) no se llamará ya que el fragmento no se está volviendo a crear.
• onAttach (Activity) y onActivityCreated (Bundle) se seguirán llamando.

Tengo algunas preguntas:

• ¿El fragmento también conserva su vista, o esto se volverá a crear en el cambio de configuración? ¿Qué significa exactamente "retenido"?

• ¿Se destruirá el fragmento cuando el usuario abandone la actividad?

• ¿Por qué no funciona con fragmentos en la pila posterior?

• ¿Cuáles son los casos de uso en los que tiene sentido usar este método?

En primer lugar, mira mi publicación sobre Fragmentos retenidos. Podría ayudar.

Ahora para responder a sus preguntas:

¿El fragmento también conserva su estado de vista , o se volverá a crear en el cambio de configuración? ¿Qué es exactamente "retenido"?

Sí, el Fragmentestado de 's se retendrá durante el cambio de configuración. Específicamente, "retenido" significa que el fragmento no se destruirá en los cambios de configuración. Es decir, Fragmentse conservará incluso si el cambio de configuración hace Activityque se destruya el subyacente .

¿Se destruirá el fragmento cuando el usuario abandone la actividad?

Al igual que Activitys, Fragments puede ser destruido por el sistema cuando los recursos de memoria son bajos. El hecho de que sus fragmentos conserven su estado de instancia en los cambios de configuración no tendrá ningún efecto sobre si el sistema destruirá o no los Fragments una vez que abandone el Activity. Si abandonas el Activity(es decir, presionando el botón de inicio), el Fragments puede o no destruirse. Si sale Activitypresionando el botón Atrás (por lo tanto, llamando finish()y destruyendo efectivamente Activity), todos los Activitymensajes adjuntos Fragmenttambién se destruirán.

¿Por qué no funciona con fragmentos en la pila posterior?

Probablemente hay varias razones por las que no es compatible, pero la razón más obvia para mí es que Activitytiene una referencia a la FragmentManager, y FragmentManagergestiona la pila. Es decir, no importa si elige retener su correo electrónico Fragmento no, el Activity(y, por lo tanto, el FragmentManagerbackstack) se destruirá en un cambio de configuración. Otra razón por la que podría no funcionar es porque las cosas pueden complicarse si se permite que existan fragmentos retenidos y no retenidos en la misma pila.

¿Cuáles son los casos de uso en los que tiene sentido usar este método?

Los fragmentos retenidos pueden ser bastante útiles para propagar información de estado, especialmente la gestión de subprocesos, a través de instancias de actividad. Por ejemplo, un fragmento puede servir como host para una instancia de Threado AsyncTask, administrando su operación. Consulte mi publicación de blog sobre este tema para obtener más información.

En general, lo trataría de manera similar al uso onConfigurationChangedcon un Activity... no lo use como una venda solo porque es demasiado vago para implementar / manejar un cambio de orientación correctamente. Úselo solo cuando lo necesite.

setRetaininstancesolo es útil cuando activityse destruye y se vuelve a crear debido a un cambio de configuración porque las instancias se guardan durante una llamada a onRetainNonConfigurationInstance. Es decir, si gira el dispositivo, los fragmentos retenidos permanecerán allí (no se destruyen ni se recrean), pero cuando el tiempo de ejecución mata la actividad para recuperar recursos, no queda nada. Cuando presionas el botón Atrás y sales de la actividad, todo se destruye.

Por lo general, uso esta función para guardar el tiempo de cambio de orientación. Di que he descargado un montón de mapas de bits del servidor y cada uno es de 1 MB, cuando el usuario gira accidentalmente su dispositivo, ciertamente no quiero volver a hacer todo el trabajo de descarga. Creo que tengo Fragmentmis mapas de bits y los agrego al administrador y llamo setRetainInstance, todos los mapas de bits siguen ahí, incluso si cambia la orientación de la pantalla.

SetRetainInstance (true) permite que el fragmento sobreviva. Sus miembros serán retenidos durante el cambio de configuración como la rotación. Pero aún puede ser eliminado cuando la actividad se elimina en segundo plano. Si el sistema elimina la actividad que contiene en segundo plano, el sistema que manejó en SaveInstanceState debe guardar su instancia de StateState correctamente. En otras palabras, siempre se llamará a onSaveInstanceState. Aunque onCreateView no se invocará si SetRetainInstance es verdadero y el fragmento / actividad aún no se elimina, aún se invocará si se eliminó y se intenta recuperarlo.

Aquí hay un análisis de la actividad / fragmento de Android espero que ayude. http://ideaventure.blogspot.com.au/2014/01/android-activityfragment-life-cycle.html

setRetainInstance () - Desaprobado

As Fragments Version 1.3.0-alpha01

El método setRetainInstance () en Fragments ha quedado en desuso. Con la introducción de ViewModels, los desarrolladores tienen una API específica para retener el estado que se puede asociar con gráficos de Actividades, Fragmentos y Navegación. Esto permite a los desarrolladores usar un Fragmento normal no retenido y mantener el estado específico que desean retener por separado, evitando una fuente común de fugas y manteniendo las propiedades útiles de una sola creación y destrucción del estado retenido (es decir, el constructor del ViewModel y la devolución de llamada onCleared () que recibe).

setRetainInstance (boolean) es útil cuando desea tener algún componente que no esté vinculado al ciclo de vida de la actividad. Por ejemplo, rxloader utiliza esta técnica para "manejar el ciclo de vida de la actividad de Android para el Observable de rxjava" (que he encontrado aquí ).