Model-View-Presenter y diseño de aplicaciones para Android

El problema: clases de actividad realmente grandes y enrevesadas. Difícil de leer / entender y modificar. Difícil de probar.

La solución posible: Model-View-Presenter (quizás con inyección de dependencia). Y objetos de prueba simulada!

Estoy planeando implementar Model-View-Presenter en mi aplicación de Android. Esto es básicamente una variante del Modelo-Ver-Controlador. En esencia, hacer de la Actividad un gestor de diseño glorificado y diferir cualquier lógica de negocio al Presentador. Otra forma de mirar al presentador es que es como una clase de ayuda instanciada dentro de una actividad para hacer el trabajo pesado con la actividad de proporcionar una interfaz / devolución de llamada que el presentador puede utilizar.

Me gustaría tener algunos pensamientos de la comunidad sobre esto. Por ejemplo: ¿Qué interfaces están implicadas por esto?
¿Qué responsabilidades tendría el Modelo y la Vista frente al Presentador.

Para Presenter supongo que la Actividad implementaría las interfaces necesarias para el presentador.
¿Qué tipo de cosas debe ir en el presentador frente a la actividad?

¿Podría un presentador ser uno-a-uno con una actividad? ¿Qué pasa con una actividad con múltiples fragmentos que muestran diferentes widgets cada uno con su propio adaptador? ¿Necesitamos ahora múltiples presentadores o aún solo uno?

¿Qué pasa con Presenter vs Adapter?

¿Cómo debe relacionarse un presentador para decir una actividad con un ListView y un ListViewAdapter? ¿Qué pasa con el presentador frente al adaptador?
¿Debería el presentador escoger el adaptador para usar? ¿O debería la Actividad tomar esta decisión? ¿Debería el presentador procesar los datos del modelo o el adaptador? ¿Hay un conflicto entre los adaptadores y los presentadores? ¿Son los adaptadores presentadores? O algo menos / más. Por lo general, los adaptadores son sólo para widgets como ListViews dentro de una actividad. No hacen las llamadas que obtienen los datos en sí creo.

Así que en el modelo-vista-presentador lo más importante es realmente decidir qué va en el presentador frente a otras clases y cuál debe ser la comunicación entre el presentador y las actividades, adaptadores y vistas / incluyendo fragmentos.

¿Es Model-View-Presenter una mala idea para Android? ¿O encaja bien con el Android Framework?

Tenga en cuenta que hay numerosos ejemplos fuera de Android de SDK muy maduro que todavía necesitaba una micro-arquitectura como MVP. De hecho, abundan los ejemplos: por ejemplo. Flex era un SDK muy maduro para Flash y aún así necesitaba marcos MVP y MVC para casi cualquier aplicación importante.

EJB necesitaba a Spring para simplificarlo y organizarlo. MFC / Struts etc y la lista sigue y sigue. ¿Por qué Android debería ser diferente? ¿Por qué debemos suponer que el SDK tiene todo lo necesario en el caso de Android sin un patrón de diseño como MVP?

Es bueno saberlo antes de pasar cientos de horas en esto, por favor no dude en comentar / responder en cualquier parte de esta pregunta.

Android castiga el mal diseño de MV (P | C) más que cualquier otra plataforma que he encontrado. Olvídese de los métodos torpes que proporciona para pasar el estado hacia arriba y hacia abajo de la pila de actividades. Obtener tanto estado y la lógica de sus actividades como sea posible. Moverlo a Servicios, Proveedores de contenido y Propuestas compartidas según corresponda. Trate de hacer que sus actividades sean puras. IMO, los servicios nunca han recibido suficiente atención en los tutoriales de Android. ¡Incluso el programa de programación de Android de O'Reilly sólo les da un cuarto de página!

Tenga cuidado de extender la Aplicación. Si alguna vez inicia un servicio en su propio proceso (por ejemplo, para permitir que se cierre con gracia cuando una actividad se bloquea), el servicio tendrá su propia copia de su aplicación.

Sólo para proporcionar una referencia para otros que puedan estar interesados. Yo pensaba lo mismo algunos años antes. Cuando aplicamos MVC / MVVM / Presentation Model a la aplicación android, lo que realmente queremos es tener un proyecto estructurado claro y, lo que es más importante, más fácil para las pruebas unitarias. Por el momento, sin un marco de terceros, por lo general tienen un montón de código (como addXXListener (), findViewById () …), que no agrega ningún valor de negocio. Lo que es más, tienes que ejecutar pruebas de unidad de android en lugar de pruebas de JUnit normales, que tardan años en ejecutarse y hacer pruebas de unidad algo impráctico. Por estas razones, hace algunos años, iniciamos un proyecto de código abierto RoboBinding – un marco de Presentación de Datos para la plataforma Android. RoboBinding le ayuda a escribir código de interfaz de usuario que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de código innecesario como addXXListener o así , y cambia la lógica de UI a Presentation Model, que es un pojo y puede ser probado a través de pruebas normales de JUnit . RoboBinding viene con más de 300 pruebas de JUnit para asegurar su calidad. Otras alternativas: Android-Binding, Bindroid y MvvmCross.

  • Model View Presenter - misma vista, diferentes presentadores
  • MVP para Android: uso seguro Contexto en Presenter
  • Editar entrada de texto con patrón android
  • Cómo implementar el patrón Decorator para las vistas de Android
  • Modelo de autenticación para la aplicación de Android
  • ¿Cuál es el principio del patrón de diseño en el desarrollo de Android?
  • Ejemplo androide del presentador de la versión / ejemplos del regulador
  • Patrones de diseño de acceso a datos de Android: Proveedor de contenido vs repositorio
  • UITextView en Android (¿Qué es EditText?)
  • Mejores prácticas / patrones de diseño de codificación para Android
  • Práctica recomendada: Ampliación o anulación de una clase de proyecto de biblioteca de Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.