Muy buenas, les saluda Luis y para hoy les traigo un nuevo tutorial.
Índice
Cuando importa la comunicación entre Fragmento y Actividad
Los Fragmentos y las Actividades son los puntos con los que nuestros usuarios interactúan directamente.
Como la navegación entre actividades es muy cara y causa problemas de rendimiento, el uso de una sola actividad y muchos fragmentos en ella para un flujo de trabajo / flujo de usuario se ha convertido en una forma muy popular de desarrollar aplicaciones de Android hoy en día.
Por lo tanto, la comunicación de Fragmento con otros Fragmentos y Actividad es uno de los temas importantes que debemos tomar en serio para desarrollar una aplicación de Android mantenible.
Comunicar fragmento con actividad
En primer lugar, echemos un vistazo a lo que recomienda Google para la comunicación entre Fragmento y Actividad:
Para permitir que un Fragmento se comunique con su Actividad, puede definir una interfaz en la clase Fragmento e implementarla dentro de la Actividad.
El Fragmento captura la implementación de la interfaz durante su método
onAttach()
de ciclo de vida y luego puede llamar a los métodos de la Interfaz para comunicarse con la Actividad.
Básicamente definimos la interfaz (que es el contrato del Fragmento) en el Fragmento e implementamos esta interfaz en la Actividad. Los pegamos usando onAttachFragment of Activity
o el método onAttach
de Fragment
. Eso es.
Google no recomienda esto directamente, pero podemos hacer un uso excesivo del ViewModel
compartido entre Fragment
y Activity
para pegarlos.
Básicamente creamos un ViewModel
adicional con sus variables LiveData
para que el Fragmento comparta su estado con la Actividad.
TLDR
; como su observador es Activity
, no olvide utilizar el ciclo de vida de la actividad cuando cree ViewModel
en el Fragmento. Es por eso que se usa la función de constructor activityViewModels ()
en este ejemplo.
- El oyente tiene menos código que el modelo de vista compartida.
- El oyente fuerza su contrato con la actividad, por lo que la actividad no puede saltarse ningún punto, de lo contrario vemos métodos no implementados.
- Fragmento no puede vivir sin su Oyente (si es forzado).
- El modelo de vista compartido se puede probar. Podemos escribir fácilmente pruebas unitarias para ellos.
- Shared ViewModel puede tener filtrado de la lógica de notificación en él.
- La actividad no necesita observar todos los eventos del Fragmento.
Ambos tienen pros y contras, debemos decidir uno de ellos de acuerdo con los requisitos de nuestro sistema. Ninguno de los dos tiene ventajas importantes entre sí en la perspectiva de la comunicación Fragmento / Actividad .
Por ejemplo: si muchos fragmentos utilizan este modelo de vista con fines de navegación. Ambos pueden usar el mismo interface
Oyente o Shared ViewModel
.
Comunicar fragmento con fragmento
Nuevamente, primero echemos un vistazo a lo que recomienda Google:
La forma recomendada de comunicarse entre fragmentos es crear un
ViewModel
. Ambos fragmentos pueden acceder alViewModel
a través de su actividad contenedora.Los Fragmentos pueden actualizar datos dentro de
ViewModel
y si los datos se exponen usandoLiveData
, el nuevo estado será empujado al otro fragmento siempre que esté observando elLiveData
desde elViewModel
.Para ver cómo implementar este tipo de comunicación, lea la sección ‘Compartir datos entre fragmentos’ en el Ver guía del modelo.
Los fragmentos comparten los datos o el estado entre ellos ViewModel
que viven bajo el ciclo de vida de Activity
.
Me gustaría mencionar otras formas de comunicación Fragmento / Fragmento como EventBus
, etc.
Sin embargo, encuentro que estas otras formas en que el evento no puede ayudar como sharedViewModel
, pero también puede causar muchos problemas de placa de caldera / ciclo de vida y complejidades de código.
Gracias por leer este post. Feliz codificación.
Añadir comentario