El marco de Android no recomienda ninguna forma específica de diseñar su aplicación. Eso, de alguna manera, nos hace más poderosos y vulnerables al mismo tiempo.
El patrón de diseño MVP es un conjunto de pautas que, si se siguen, desacoplan el código de reutilización y capacidad de prueba. Divide los componentes de la aplicación en función de su función, denominada separación de preocupaciones.
MVP divide la aplicación en tres componentes básicos:
- ¿Cuál es la mejor aplicación de Android para el software de gestión OPD?
- ¿Gran aplicación de Android en Android Marketplace?
- ¿Cuáles son los mejores juegos de Android sin conexión de ciencia ficción?
- ¿Debo usar SQLite o Firebase para una aplicación social que quiero crear para estudiantes universitarios?
- ¿Cómo sé la fuente de tráfico a mi página de aplicación de Android en Google Play Store?
- Modelo : es responsable de manejar la parte de datos de la aplicación.
- Vista : es responsable de diseñar las vistas con datos específicos en la pantalla.
- Presentador : es un puente que conecta un modelo y una vista. También actúa como instructor de la vista.
MVP establece pocas reglas básicas para los componentes mencionados anteriormente, como se enumeran a continuación
- La única responsabilidad de una Vista es dibujar la IU según las instrucciones del Presentador. Es una parte tonta de la aplicación.
- Ver delega todas las interacciones del usuario a su presentador.
- La Vista nunca se comunica con el Modelo directamente.
- El presentador es responsable de delegar los requisitos de View a Model e instruir a View con acciones para eventos específicos.
- El modelo es responsable de obtener los datos del servidor, la base de datos y el sistema de archivos.
MVP parece ser muy simple cuando se explica con un ejemplo simple de Actividad, pero nos hace sentir perdidos cuando intentamos unir todos los componentes de una aplicación.
Esbocemos primero el plano de la arquitectura.
Comprendamos cada parte de la arquitectura esbozada.
- Vista : es la parte de la aplicación que representa la interfaz de usuario y recibe interacciones del usuario. Actividad, Fragmento y CustomView constituyen esta parte.
- MvpView : es una interfaz implementada por la Vista. Contiene métodos que están expuestos a su presentador para la comunicación.
- Presentador : es el equivalente en la toma de decisiones de View y es una clase pura de Java, sin acceso a las API de Android. Recibe las interacciones del usuario transmitidas desde su Vista y luego toma la decisión basada en la lógica de negocios, finalmente instruye a la Vista para que realice acciones específicas. También se comunica con el DataManager para cualquier dato que necesite para realizar la lógica empresarial.
- MvpPresenter : es una interfaz implementada por el presentador. Contiene métodos que están expuestos a su Vista para la comunicación.
- AppDbHelper : la gestión de la base de datos y todo el manejo de datos relacionados con una base de datos se realiza en esta parte de la aplicación.
- DbHelper : es una interfaz implementada por AppDbHelper y contiene métodos expuestos a los componentes de la aplicación. Esta capa desacopla cualquier implementación específica de DbHelper y, por lo tanto, hace que AppDbHelper sea una unidad plug and play.
- AppPreferenceHelper : es como AppDbHelper, pero tiene el trabajo de leer y escribir los datos de las preferencias compartidas de Android.
- PreferenceHelper : interfaz como DbHelper pero implementada por AppPreferenceHelper.
- AppApiHelper : gestiona las llamadas API de la red y el manejo de datos API.
- ApiHelper : es una interfaz como DbHelper pero implementada por AppApiHelper.
- DataManager : es una interfaz implementada por AppDataManager. Contiene métodos, expuestos para todas las operaciones de manejo de datos. Idealmente, delega los servicios proporcionados por todas las clases de ayuda. Para esta interfaz DataManager, se extienden las interfaces DbHelper, PreferenceHelper y ApiHelper.
- AppDataManager : es el único punto de contacto para cualquier operación relacionada con datos en la aplicación. DbHelper, PreferenceHelper y ApiHelper solo funcionan para DataManager. Delega todas las operaciones específicas de cualquier ayudante.
Ahora, estamos familiarizados con todos los componentes y sus roles en la aplicación. Ahora formularemos el patrón de comunicación dentro de varios componentes.
- La clase de aplicación crea instancias de AppDbHelper (en la variable DbHelper), AppPreferenceHelper (en la variable PreferenceHelper), AppApiHelper (en la variable ApiHelper) y finalmente AppDataManager (en la variable DataManager) al pasarle la referencia DbHelper, PreferenceHelper y ApiHelper.
- Los componentes de Vista crean una instancia de su Presentador a través de la referencia MvpPresenter.
- El presentador lo recibe Ver componente y se refiere a él a través de MvpView. El presentador también recibe el DataManager.
- DataManager existe como una instancia singleton.
Estas son las pautas básicas para que una aplicación implemente MVP.
