Cómo implementar su propio marco MVP de Android

Como versión evolucionada de MVC, MVP está atrayendo cada vez más atención en el desarrollo de Android. Sin embargo, elegir dicho patrón de diseño de software en el desarrollo de proyectos requiere precaución. Una vez que decidas utilizar MVP como modelo de desarrollo para tu aplicación, será mejor que lo sigas haciendo. Si encuentra problemas durante el proceso de desarrollo utilizando el modelo MVP y los obstáculos son cada vez más grandes, entonces si desea rediseñar utilizando MVC, es básicamente equivalente a empezar de nuevo. Debe saber que no existe un estándar o marco unificado para MVP en Android, a diferencia de SSH, que son tres mosqueteros maduros, estables y poderosos que admiten el desarrollo de Java EE. Por lo tanto, cuando utilice MVP, debe comprenderlo bien e intentar predecir las necesidades de cada módulo de su aplicación (el cliente dijo que cambiaremos:-() para poder hacer el trabajo de diseño con anticipación. Por supuesto, dado que MVP puede Aparece, debe haber sus ventajas. De lo contrario, ¿quién prestaría atención a esta ventana emergente?

Introducción a MVP

Creo que todos están familiarizados con MVC: M-Model-model. V-View-view, C-Controller-controller Como versión evolucionada de MVC, MVP también es un método de implementación de la interfaz de usuario (capa de usuario), por lo que el significado correspondiente de MVP es: M-Model-model, V-View. -view, P-Presenter-presenter Desde la perspectiva de la combinación de MVC y MVP, el controlador/Presentador desempeña el papel de procesamiento de control lógico en MVC/MVP, y la mayor diferencia entre MVP y MVC es M. No hay ninguna diferencia directa. relación con V, y no existe una relación directa entre el modelo y la vista. Hay una capa de presentador entre ellos, que es responsable de regular la interacción indirecta entre la vista y el modelo. El diagrama de estructura de MVP es el siguiente. No es necesario limitar la comprensión de este diagrama. Después de todo, existen algunas diferencias en diferentes escenarios. Un punto muy importante en Android es que las operaciones de la interfaz de usuario básicamente deben completarse de forma asincrónica, es decir, la interfaz de usuario se puede operar. MainThread, por lo que es razonable separar la vista del modelo. Al utilizar interfaces para definir interacciones, las interacciones entre presentadores, vistas y modelos se pueden acoplar aún más libremente, lo que facilita las pruebas unitarias a través de interfaces. Diagrama de estructura de MVP

Modelo MVP

El modelo es una abstracción de los datos que la interfaz de usuario necesita mostrar. También puede entenderse como una abstracción de los datos comerciales (resultados). la interfaz de usuario (reglas comerciales, acceso a datos, clases de modelo). En este artículo, la demostración coloca directamente el negocio en el modelo correspondiente para un procesamiento simple.

Vista MVP

Esta capa. La vista es muy delgada y solo es responsable de mostrar datos y proporcionar una interfaz amigable para la interacción del usuario. Las actividades y fragmentos en MVP se reflejan en esta capa. La actividad generalmente realiza algunos trabajos, como cargar vistas de la interfaz de usuario, configurar el monitoreo y entregarlas. a Presenter, por lo que debe contener una referencia al Presenter correspondiente. Por ejemplo, al desplazarse por la lista de actividades, la barra de acciones (barra de herramientas) también debe estar oculta al realizar algunos juicios. los datos ingresados ​​​​en la Vista, por ejemplo, si los datos de entrada de EditText son un juicio simple no nulo, se pueden usar como la lógica de la capa de Vista y cuando es necesario hacer algunos juicios sobre EditText. el procesamiento de datos es más complejo, como obtener datos locales de la base de datos para juzgarlos, obviamente deben devolverse a través de la capa Modelo, por lo que usted mismo debe sopesar estos detalles.

Host MVP

La capa actual maneja la distribución de varias lógicas del programa. Después de recibir instrucciones como comandos de retroalimentación, comandos de sincronización y comandos del sistema, la interfaz de usuario de la capa de vista entrega la lógica de procesamiento de distribución a la capa empresarial para operaciones comerciales específicas y luego muestra el modelo resultante en la vista.

Demostración

¿Por qué no empezar a escribir código? La demostración es muy simple y la imagen de arriba es más intuitiva.

Ingrese el código de la ciudad, haga clic en el botón para obtener la información meteorológica de esa ciudad y luego muéstrela. La operación de la red utiliza Volley Framework, el análisis utiliza Gson y el resto está escrito a mano. El diseño del packaging de todo el proyecto es el siguiente:

? Estructura del paquete de datos

Vista previa del efecto del proyecto

Hay tres capas obvias en el diagrama del paquete: paquete de modelo, paquete de Presenter y paquete de UI. Los tres implementan sus propias estructuras y el modelo. es WeatherModel, el presentador es WeatherPresenter, la vista es Weather, por lo que la clase de implementación específica está en el paquete impl y la capa de vista es Actividad. Además, los paquetes de aplicaciones y utilidades no tienen nada que hacer y pueden ignorarse. Se puede ver que después de adoptar el diseño MVP, obviamente hay muchas cosas en el proyecto, lo cual es inevitable. Usar el método original puede hacer que el proyecto sea más fácil de abrir, pero habrá mantenimiento, pruebas y agregar funciones en el futuro. . .

Los atributos de entidad en entidad corresponden básicamente a los de json, por lo que el código no se publicará.

Interfaz en vista:

Vista meteorológica de interfaz pública {

void show loading();

void hide loading(); /p>

void show error();

void setWeatherInfo(clima);

}

Interfaz WeatherPresenter:

Interfaz pública WeatherPresenter {

/**

*Comprender la lógica del clima

*/

void getWeather(String city ​​no);

}

Interfaz WeatherModel:

Interfaz pública WeatherModel {

void loadWeather(string cityNO, onweathelistener oyente) ;

}

También hay un OnWeatherListener en el presentador, que se implementa en la capa Presentador. Vuelve a llamar la capa del modelo y cambia el estado de la capa de vista para garantizar que el modelo. La capa no opera directamente la capa de vista. Si esta interfaz no está implementada en Weatherpresentempl, y Weatherpresentempl solo tiene referencias a Ver y Modelo, entonces ¿cómo le dice el Modelo a Ver el resultado? Por supuesto, esta es sólo una solución. En proyectos reales, se pueden combinar marcos de terceros como Dagger, EventBus y Otto para lograr un diseño menos acoplado.

WeatherListener {

/**

*Devolución de llamada en caso de éxito

*

* @param Weather

*/

void onSuccess(weather);

/**

*Devolución de llamada en caso de error, procesamiento simple, nada que hacer

*/

void on error();

}

Entonces demostración: el flujo de código de actividad realiza alguna inicialización de la interfaz de usuario, es necesario crear una instancia la referencia correspondiente de WeatherPresenter e implementar la interfaz de WeatherView, y monitorear las acciones de la interfaz. Después de presionar el botón Ir, se recibirá el evento de consulta meteorológica. Cuando se reciba en onClick, se entregará a WeatherPresenter para su procesamiento a través de la referencia de WeatherPresenter.

Cuando WeatherPresenter recibe la lógica de la consulta meteorológica, sabe que necesita consultar el tiempo y luego entrega la implementación comercial específica de la consulta meteorológica al WeatherModel, y al mismo tiempo pasa el WeatherListener al WeatherModel. Después de que WeatherModel consulta el servicio meteorológico, notifica a WeatherPresenter los resultados a través de la devolución de llamada de WeatherListener, y WeatherPresenter devuelve los resultados a la actividad en la capa de vista y, finalmente, la actividad muestra los resultados. Eso es todo. Por favor, toca los ladrillos.

Fin

¿Qué patrón de diseño de software se debe utilizar para lograr los siguientes objetivos? Es mejor encontrar el adecuado para usar:

Fácil de mantener

Fácil de probar

Acoplamiento flojo

Alta reutilización

Potente y estable

-

Arriba Consulte Internet. Espero que los conocimientos anteriores le resulten útiles.