¿Es una buena idea que un Fragmento delegue todo el control de navegación en Actividad?
Inspirado en la guía para desarrolladores de Android , estoy tratando de escribir código en el que todos los fragmentos son autónomos (en términos de red / lógica) y cualquier acción que realicen (clic / toque) que debería resultar en el lanzamiento de una nueva actividad / fragmento sería delegado a la actividad (mediante devolución de llamada).
Para empezar, parecía correcto. Pero ahora, cuando tengo fragmentos que tienen más de 1 widgets de este tipo (que necesitan el fragmento para navegar a una nueva pantalla), parece un desastre. Tampoco necesito escribir varias devoluciones de llamada o hacer alguna lógica de conmutación en Actividad para diferentes acciones hechas en un fragmento.
- Integración de youtube para fragmentar
- Android FragmentManager BackStackRecord.run lanzando NullPointerException
- Android onBackStackChanged () no se llama
- Android - Estrategia de grupo de subprocesos y Loader se puede utilizar para implementarlo?
- Android: Solución para support.v4.app.Fragment -> Fragment classcastexception?
Si este diseño suena mal, ¿cuáles son los escenarios donde la implementación de callbacks (como se sugiere en la guía) sería una buena idea?
- ¿Cómo evitar múltiples instancias de fragmentos en la actividad después de que la aplicación se destruye y se reanuda?
- Android ¿por qué Fragmentos no deben comunicarse directamente entre sí?
- Mostrar opciones de menú en la barra de herramientas de Actividad contiene pestañas como fragmento
- Accesibilidad de Android talkback para decir el título del fragmento
- Android cómo saber si el menú deslizante está visible
- Fragmento onCreateView y onActivityCreated no se llama en rotación
- Android FragmentTransaction.addToBackStack confusión
- Lollipop transitions - Fragmento de la actividad
No sé cómo está implementando estas devoluciones de llamada.
Una aproximación a este problema es usar el patrón de contrato:
-
El fragmento define una interfaz de
Contract, que cualquier actividad de alojamiento debe implementar -
Cuando el fragmento desea pasar el control a la actividad, llama a un método en esa interfaz
Jake Wharton tiene la implementación canónica de esto en un GitHub . La única pieza que no se muestra es que la actividad que hospeda su MyCoolFragment necesita implementar la interfaz MyCoolFragment.Contract .
Esto supone que cada fragmento tiene eventos distintos para elevar a la actividad y por lo tanto necesita su propia interfaz. Si tiene varios fragmentos con características comunes, puede normalizar en una única interfaz, en lugar de duplicar el Contract todas partes.
Hay otros enfoques (por ejemplo, el comentario sobre la idea que sugiere usar un bus de mensajes), pero para el simple fragmento-> comunicación de actividad, el patrón de contrato debe tener la menor sobrecarga, tanto en términos de codificación como de ejecución.
Su enfoque general, sin embargo, de delegar el trabajo a la actividad donde ese trabajo puede resultar en cambios a otro fragmento, es definitivamente bueno. Hace que sea mucho más fácil manejar los casos en los que los fragmentos no están en la pantalla al mismo tiempo, tal vez alojados en diferentes actividades, ya que maneja diferentes configuraciones de pantalla (teléfono vs. tableta, pantalla única vs. TV, etc.).