Model-View-Presenter y Android Application Design

Question

El problema: clases de actividad realmente grandes y complicadas. 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 simulacros de objetos de prueba!

Planeo implementar Model-View-Presenter en mi aplicación de Android. Esto es básicamente una variante del Modelo-Vista-Controlador. Básicamente, haga que la Actividad sea un gestor de distribución glorificado y difiera cualquier lógica comercial al Presentador. Otra forma de ver el Presentador es que es como una clase de Ayudante instanciada dentro de una Actividad para hacer el trabajo pesado con la actividad que proporciona una interfaz/devolución de llamada que el Presentador puede usar.

Me gustaría tener algunas ideas de la comunidad sobre esto. Por ejemplo: ¿Qué interfaces están implícitas en esto?
¿Qué responsabilidades tendrían el modelo y la vista frente al presentador?

Para el presentador Supongo que la actividad implementaría las interfaces que necesita el presentador.
¿Qué tipos de cosas deberían incluirse en el presentador frente a la actividad?

¿Sería un presentador 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? ¿Ahora necesitamos múltiples presentadores o solo uno solo?

¿Qué hay de Presenter vs. Adapter?

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

Por lo tanto, en modelo-vista-presentador la clave es realmente decidir qué entra 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 Android Framework?

Tenga en cuenta que existen numerosos ejemplos fuera de Android de SDK muy maduros que aún necesitaban una micro-arquitectura como MVP. De hecho abundan los ejemplos: ej. Flex era un SDK muy maduro para Flash y aún necesitaba frameworks MVP y MVC para casi cualquier aplicación importante.

EJB necesitaba Spring para simplificarlo y organizarlo. MFC/Struts etc. y la lista sigue y sigue. ¿Por qué Android debería ser diferente? ¿Por qué deberíamos asumir 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 dedicar cientos de horas a esto, por favor no dude en comentar/responder en cualquier parte de esta pregunta.

Answer 1

Android castiga el diseño pobre de MV (P | C) más que cualquier plataforma que he encontrado. Olvídese de los métodos torpes que proporciona para pasar el estado arriba y abajo de la pila de actividades.Obtenga todo el estado y la lógica de sus actividades como sea posible. Moverlo a Servicios, ContentProviders y SharedPreferences, según corresponda. Intenta hacer que tus actividades sean vistas por completo. OMI, nunca se ha prestado suficiente atención a los servicios en los tutoriales de Android. ¡Incluso el libro O'Reilly Programación Android solo les da un cuarto de página!

Tenga cuidado de no extender la aplicación. Si alguna vez inicia un Servicio en su propio proceso (por ejemplo, para permitir que se cierre correctamente cuando una Actividad falla), entonces el Servicio tendrá su propia copia de su Aplicación.

Answer 2

Solo para proporcionar una referencia para otros que puedan estar interesados. Estaba pensando lo mismo algunos años antes. Cuando aplicamos MVC/MVVM/Presentation Model a la aplicación de 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 trabajo de terceros, generalmente tiene muchos códigos (como addXXListener(), findViewById() ...), que no agrega ningún valor comercial. Además, debe ejecutar pruebas de la unidad de androides en lugar de las pruebas JUnit normales, que tardan años en ejecutarse y hacen que las pruebas unitarias sean algo poco prácticas. Por estas razones, hace algunos años comenzamos un proyecto de código abierto RoboBinding - Un marco de modelo de presentación vinculante para la plataforma Android. RoboBinding te ayuda a escribir código de UI que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de código innecesario como addXXListener o menos, y cambia la lógica de UI a Presentation Model, que es un pojo y se puede probar a través de JUnit pruebas normales. RoboBinding viene con más de 300 pruebas JUnit para garantizar su calidad. Otras alternativas: Android-Binding, Bindroid y MvvmCross.