android - onattach - Uso de `onRetainCustomNonConfigurationInstance` para retener datos a través de cambios de configuración

llamar fragment desde fragment

Question

He estado programando para Android por algún tiempo y todavía estoy buscando soluciones para conservar los datos sobre los cambios de configuración. Además de guardar Parcelable s en el Bundle de actividad en onSaveInstanceState documentos sugieren utilizar Fragment con el indicador setRetainInstance establecido en verdadero.

Pero acabo de encontrar un código que usa onRetainCustomNonConfigurationInstance para contener objetos arbitrarios (de manera elegante, pero esencialmente objetos grandes sin referencias a la Activity etc.). Nunca he visto este método usado, así que tengo algunas dudas:

• ¿Es seguro llamar a este método para almacenar objetos arbitrarios (en el sentido de que puedo estar bastante seguro de que se llamará, y de que no será desaprobado / eliminado en el corto plazo)?
• ¿En qué se diferencia este método de onRetainNonConfigurationInstance() , que también debería devolver Object y, en esencia, debería funcionar de manera similar?
• ¿Es aún mejor usar el fragmento retenido, por alguna razón?

Como beneficio adicional, agradecería cualquier otra sugerencia o solución para guardar el estado de objetos como AsyncTask , Observable , presentadores de la vista y continuar

Answer 1

¿Es seguro llamar a este método para almacenar objetos arbitrarios (en el sentido de que puedo estar bastante seguro de que se llamará, y de que no será desaprobado / eliminado en el corto plazo)?

onRetainCustomNonConfigurationInstance() es un método relativamente nuevo y no está en desuso. Realmente asumo que no desaparecerá pronto, porque no hay razón para introducir algo nuevo solo para eliminarlo. Puedes usarlo con seguridad.

¿En qué se diferencia este método de onRetainNonConfigurationInstance (), que también debería devolver Object y, en esencia, debería funcionar de manera similar?

onRetainNonConfigurationInstance() siempre devuelve una instancia de la clase interna NonConfigurationInstances con fragmentos retenidos, estados de cargadores, etc. No puede (y no debe) cambiar este comportamiento del sistema. Es por eso que el método es final y no se puede anular.

Si desea conservar su instancia personalizada, debe anular onRetainCustomNonConfigurationInstance() y devolverla desde allí.

De hecho, onRetainNonConfigurationInstance() invoca onRetainCustomNonConfigurationInstance() y retiene la instancia onRetainCustomNonConfigurationInstance() con los otros estados, como los fragmentos retenidos y los cargadores.

¿Es aún mejor usar el fragmento retenido, por alguna razón?

Es más bien una cuestión de su caso de uso y preferencias. La lógica podría ser así. Si su actividad solo controla los fragmentos y no tiene otra lógica especial, entonces es más fácil usar los fragmentos retenidos. Si su actividad tiene algo que retener, entonces puede usar de manera segura el método onRetainCustomNonConfigurationInstance() . En cuanto a ahora, en ambos casos, el estado sigue siendo retenido por el método onRetainNonConfigurationInstance() antiguo y obsoleto.

ps. Con respecto a la pregunta de bonificación sobre el almacenamiento de un estado, me gustaría sugerirle que busque el método onSaveInstanceState() . Estaba destinado a almacenar estados.

Actualización: la versión de AndroidX del 5 de noviembre de 2018 dejó de usar el método con la siguiente nota: onRetainCustomNonConfigurationInstance ha quedado en desuso. Use un ViewModel para almacenar objetos que necesitan sobrevivir a los cambios de configuración.