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

  • Implementación de MVP con Dagger en un FragmentPagerAdapter
  • Utilizar la programación con RxAndroid
  • ¿Es IntentService una implementación del patrón de comandos?
  • Android MVP - ¿Debería evitar el uso de referencias R.string en el presentador?
  • MVP de Android: qué modelo presentar para ver
  • Daga con Android: ¿Cómo inyectar el contexto cuando se utiliza MVP?
  • MVP para Android: uso seguro Contexto en Presenter
  • Google Analytics con el patrón de diseño MVP
  • La clase Dagger no podía estar atada con la clave
  • Android Dagger 2 y MVP se inyectan dentro de un objeto inyectado
  • Desventaja de MVP sobre patrón de diseño MVVM en android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.