Android MVP – puedo tener múltiples presentadores para vistas personalizadas y fragmentos

Así que tengo un presentador que ya está vinculado a una actividad. El libro dice que un presentador debe estar atado a una vista. Pero ahora estoy agregando algunos fragmentos y un montón de vistas personalizadas. Estoy considerando un fragmento para ser una visión también. Las vistas personalizadas contendrán un poco de lógica en ellas. Tanto los fragmentos como las vistas personalizadas están contenidos en mi actividad, por supuesto.

Mi pregunta es, ¿debo volver a usar el mismo presentador en el fragmento y las vistas personalizadas o cada vista obtener su propio presentador? Me doy cuenta de que es todo basado en la opinión, pero quiero que el mejor enfoque para la prueba y el mantenimiento de código limpio.

Si tengo un presentador para todos estos fews a continuación, a continuación, la interfaz de los usuarios presentador tendrá muchos métodos de devolución de llamada en ella. Mientras tanto, si hice lo contrario y creó un presentador para cada vista que podría ser más fácil de leer, pero ¿cómo lo probaría?

2 Solutions collect form web for “Android MVP – puedo tener múltiples presentadores para vistas personalizadas y fragmentos”

View (Activity) puede tener varios Presenters . En caso de tener varias CustomViews para la Activity , puede tener un Presenter o Presenter gigante por cada CustomView . Depende de esto:

  1. Si todas las CustomViews comparten las mismas necesidades, un Presenter para todas las CustomViews es suficiente. Todavía hay dos opciones para Presenter's ámbito Presenter's :

    • Presenter tiene ActivityScope . Activity utiliza Presenter y se llama desde Presenter . Luego envía comandos, datos a CustomViews
    • Presenter tiene ViewScope . Cada CustomView crea y destruye el mismo Presenter

    En caso de que CustomViews no compartan las mismas necesidades, teniendo un Presenter y ViewInterface , contendrán métodos de todas CustomViews necesidades de CustomViews , por lo que cada CustomView tiene que implementar todos los métodos declarados en ViewInterface , deje algunos vacíos.

  2. Si las CustomViews tienen diferentes necesidades y llamadas de método a Presenter , deberían tener su propio Presenter .

  3. Si las CustomViews tienen diferentes necesidades y también algunas necesidades comunes, comparten la misma necesidad en un Presenter , las necesidades específicas de sus propios Presenters . Ejemplo para esto: ActivityOne tiene CustomViewOne y CustomViewTwo . Common Presenter para ambos CustomViews puede ser FeedPresenter (teniendo en cuenta que ambos CustomViews tienen Feed List). Entonces CustomViewOne tendrá CustomPresenter1 y CustomViewTwo tendrá CustomPresenter2 para sus necesidades específicas.

La mejor práctica es crear un presentador de base, luego crear presentador para cada implementador de implementación de vista

  • Estructura del paquete de patrones de Android MVP
  • ¿El presentador que tiene conocimiento de la Actividad / Contexto es una mala idea en el patrón MVP?
  • Implementación de MVP en la aplicación de Android
  • Estrategia de MVP de Android
  • Daga con Android: ¿Cómo inyectar el contexto cuando se utiliza MVP?
  • Prueba de la unidad MVP de Android: ¿debo burlar el bus de eventos?
  • RxJava con presentador y fragmento retenido para cambios de configuración
  • Transiciones de elementos compartidos entre vistas (no actividades o fragmentos)
  • MVP de Android: cómo comunicarse entre el presentador de la actividad y el presentador de fragmentos
  • ¿Cómo inicio un servicio desde mi Interactor usando el patrón MVP en android?
  • Norma de arquitectura de Android MVP para cargar interfaz de usuario con clase Model que tiene recurso android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.