• slidebg1

Modelo Vista Presentador (MVP) en Android


En este articulo vamos a hablar sobre patrones de arquitectura y más concretamente sobre el MVP aplicado a aplicaciones Android. Los patrones de arquitectura, nos permiten mantener un proyecto limpio, escalable,  fácil de mantener y de testear.  El MVP (Model View Presenter) es un patrón derivado del MVC (Model View Controller), que nos permite separar de forma muy clara nuestras vistas de la lógica de nuestras aplicaciones.

Prefacio

The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Diferencias entre MVC y MVP

Antes de entrar a analizar que nos ofrece el MVP, entendamos de dónde viene y que ventajas nos puede aportar frente a un MVC.

Wikipedia:

El modelo–vista–controlador (MVC) es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

Wikipedia:

Modelo–Vista–Presentador (MVP) es una derivación del patrón arquitectónico modelo–vista–controlador (MVC), y es utilizado mayoritariamente para construir interfaces de usuarioEn MVP el presentador asume la funcionalidad del "medio-hombre". En MVP, toda lógica de presentación es colocada al presentador.

Esquema MVC y MVP

Como podemos ver ambos modelos parecen bastante similares pero ofrecen importantes diferencias:

  1. En el MVC,  el modelo notifica a la vista cualquier cambio que sufra el estado del modelo. La información puede pasarse en la propia notificación, o después de la notificación, la vista puede consultar el modelo directamente para obtener los datos actualizados. Por el contrario, en el MVP, la vista no sabe nada sobre el modelo y la función del presentador es la de mediar entre ambos, enlazando los datos con la vista.
  2. En el modelo MVC, la vista tiende a tener más lógica porque es responsable de manejar las notificaciones del modelo y de procesar los datos. En el modelo MVP, esa lógica se encuentra en el presentador, haciendo a la vista "estúpida".  Su única función es representar la información que el presentador le ha proporcionado.
  3. En MVC, el modelo tiene lógica extra para interactuar con la vista. En el MVP, esta lógica se encontraría en el presentador.

 

Capas del patrón MVP

  • Modelo: Esta capa gestiona los datos. Son las clases que denominaríamos de lógica de negocio.
  • Vista:  Se encarga de mostrar los datos. Aquí se encontrarían nuestros Fragmentos y Vistas.
  • Presentador: Se sitúa entre el modelo y la vista, permitiendo conectar la interfaz gráfica con los datos.

 

MVP en Android

Android no nos ofrece de forma nativa la posibilidad de desarrollar nuestras aplicaciones bajo el patrón MVP, de hecho viola mucho de sus principios básicos. Aun así podemos llevar a cabo alguna aproximación para este fin. Vamos a ver un posible ejemplo de implementación en el que el usuario dispone de un formulario dónde puede introducir contactos.

  • El usuario introduce un contacto y pulsa el botón "añadir contacto".
  • El Presentador crea el objeto Contacto con los datos introducidos por el usuario y se lo pasa al Modelo para que lo introduzca en la base de datos.
  • El Modelo inserta el contacto en la base de datos.
  • Si todo ha ido bien, el Presentador  limpia el formulario y refresca la lista de contactos para que aparezca el que acaba de añadir. En caso de que se haya producido algún error, muestra una alerta con un mensaje de error.

La comunicación entre las capas se va a llevar a cabo mediante el uso de interfaces. Para este ejemplo necesitaremos cuatro interfaces.

  • ProvidedPresenterOps: Operaciones a las cuales tiene acceso la Vista y son implementadas por el Presentador. Permiten que la Vista se comunique con el Presentador.
  • ProvidedModelOps: Operaciones a las cuales tiene acceso el Presentador y son implementadas por el Modelo. Permiten que el Presentador se comunique con el Modelo.
  • RequiredViewOps: Operaciones a las cuales tiene acceso el Presentador y son implementadas por la Vista. Permiten que el Presentador se comunique con la Vista.
  • RequiredPresenterOps: Operaciones a las cuales tiene acceso el Modelo y son implementadas por el Presentador. Permiten que el Modelo se comunique con el Presentador.

Una vez tenemos definidas las capas de nuestro MVP, necesitamos instanciarlas e insertar las referencias necesarias, además de un mecanismo responsable de mantener el estado del Presentador y del Modelo durante el ciclo de vida de nuestro Fragmento o Actividad.

Conclusiones

El SDK de Android no nos ofrece de forma nativa un patrón MVP.  Aún así podemos llevar a cabo alguna aproximación que nos permita desarrollar aplicaciones robustas, que sean más fáciles de mantener, escalar y testear.

Herramientas para el patrón MVP

  • Dagger
  • RxJava//Otto

Referencias

http://code.tutsplus.com/tutorials/how-to-adopt-model-view-presenter-on-android--cms-26206

https://github.com/konmik/konmik.github.io/wiki/Introduction-to-Model-View-Presenter-on-Android

Públicado el 20/07/2016

Comparte este post:

CATEGORÍAS: Accesibilidad Desarrollo