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!
- MVP de Android con RxAndroid + Retrofit
- Forma correcta de dar formato a la fecha con cadenas como hoy, ayer, mañana, etc
- Diseño de un nuevo patrón BaseAdapter en Android
- Adaptador genérico para muchos tipos de fila de presentación de listview en android
- Activar o desactivar la pantalla PatternLock del código
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.
- Patrón de diseño de Android MVVM
- Posibles patrones en la matriz 3x3 de los números
- Mejores prácticas para "capa de datos" en las aplicaciones para clientes de Android
- ¿Por qué algunos métodos del SDK de Android aceptan una matriz como parámetro en lugar de devolver una matriz?
- Singletons vs. Contexto de la aplicación en Android?
- Vista de lista dinámica - Patrón de diseño
- Comparación de MVC de Java con patrón de diseño Android
- ¿Cómo guarda de forma segura una orden en la nube, si no puede verificar el pago desde la nube?
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.
- "Error al registrar el canal de entrada" – ¿qué causa esto y cómo solucionarlo?
- Android, cálculo del hash SHA-1 desde el archivo, el algoritmo más rápido