MVP de Android con Dagger 2 – Actividad con múltiples fragmentos
He estado buscando en los ejemplos de Google Android Architecture para MVP con Dagger 2:
Https://github.com/googlesamples/android-architecture/blob/todo-mvp-dagger/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/tasks/TasksActivity.java
- Datos de paso de Android entre Fragmentos
- En el patrón MVP, ¿deben los adaptadores sujetar modelos o el presentador debe mantener los modelos y hacer que el adaptador lo haga referencia?
- Dagger 2 e implementaciones de interfaz
- Implementación de GoogleApiClient en Android mvp con daga?
- ¿Cuál es la mejor manera de comprobar los permisos en tiempo de ejecución mediante la arquitectura MVP?
Pero el ejemplo es algo trivial: cada actividad tiene sólo un fragmento y el componente de la daga se construye en la actividad y se utiliza para inyectar la actividad con el presentador del fragmento.
He intentado construir en ese ejemplo, para agregar múltiples fragmentos a una actividad y navegar entre ellos. Puesto que cada fragmento tiene su propio presentador, he movido el edificio de la pieza de la daga en el fragmento. Así que ahora tengo:
- FragmentCallback (una interfaz que proporciona métodos para cargar fragmento1 y fragmento2)
- Actividad (implementa FragmentCallback)
- Fragmento1 (implementa la interfaz de vista)
- Fragment1Contract (define interfaces de vista y presentador)
- Fragment1Presenter (implementa la interfaz del presentador)
- Fragmento1Componente (inyecta Fragmento1)
- Fragment1Module (proporciona la vista y el presentador)
- Fragmento2
- Fragment2Contract (define interfaces de vista y presentador)
- Fragment2Presenter (implementa la interfaz del presentador)
- Fragment2Component (inyecta Fragment2)
- Fragment2Module (proporciona la vista y el presentador)
La actividad hace muy poco, solo carga el primer fragmento e implementa FragmentCallback que la vista puede usar para cambiar a otro fragmento.
El primer fragmento tiene un botón que carga el segundo fragmento usando el FragmentCallback – que los fragmentos obtienen mediante el lanzamiento de la Actividad vía
public void onAttach(Context context) { super.onAttach(context); callback = (FragmentCallback) context; }
¿Estoy en una pista sensible aquí? Mientras que el código parece limpio con MVP estoy perdiendo algo wrt los componentes de la daga y los módulos?
Gracias.
Actualizar
He mejorado un poco la situación al crear un componente y un módulo para la actividad. Cada Fragmento todavía construye el contexto de la Daga, pero ya no estoy inyectando la vista (fragmento) en el constructor del presentador – cuando el fragmento construye el contexto, se inyecta a sí mismo (por lo que tiene el presentador) entonces llama presenter.init(this)
De modo que el presentador tiene ahora la vista.
Esto reduce muy bien el número de clases, y el siguiente paso sería probar sólo la construcción del componente en la actividad, y tener el fragmento usar esto para inyectarse (sin tener que construir un nuevo componente).
- ¿Es IntentService una implementación del patrón de comandos?
- ¿Cómo debo pasar los datos (por ejemplo, qué elemento se hizo clic) entre Actividades en MVP?
- ¿El presentador que tiene conocimiento de la Actividad / Contexto es una mala idea en el patrón MVP?
- Implementación de MVP con Dagger en un FragmentPagerAdapter
- ¿El desarrollo de la interfaz de usuario de Android se presta bien a un patrón de diseño participativo?
- Problemas al definir el patrón MVP para las aplicaciones de Android
- Android Model-View-Presenter (MVP) Cómo devolver AsyncTask de ejecución larga
- ¿Cómo puedo seguir la arquitectura MVP con SDK de terceros?
Definitivamente estás en el buen camino.
Sugiero que no utilice un solo componente en la Activity
, pero instanciar un componente por separado Fragment
(incluso si los componentes son los mismos). Este enfoque tiene dos ventajas:
- Los fragmentos no están acoplados a la
Activity
ya otrosFragments
por el propio componente (y los objetos que el componente podría almacenar en caché si utiliza los ámbitos) - Permite un empleo más graneado de los ámbitos (si es necesario)
Fuera de contexto:
Escribí una entrada en el blog sobre por qué las actividades en Android no son elementos de la interfaz de usuario . Echa un vistazo, y si sientes que tiene sentido, entonces hay un enlace a la implementación alternativa de MVP 🙂
- Google AdMob "intentaremos no mostrar nuevamente ese anuncio"
- FragmentManager.getFragmens (). Size () no disminuyen después de FragmentTransaction.remove (Fragment)