El MVP (Model View Presenter) es un patrón derivado del conocido MVC (Model View Controller), que de un tiempo a esta parte está cobrando gran importancia en el desarrollo de aplicaciones Android. Cada vez hay más gente hablando del tema, pero sin embargo muy poca información fiable y estructurada. Es por eso que quería aprovechar este blog para incitar el debate y que todos aportemos nuestros conocimientos para aplicarlo de la mejor manera posible a nuestros proyectos.
¿Qué es el MVP?
El patrón MVP permite separar la capa de presentación de la lógica de la misma, de tal forma que todo lo relacionado con cómo funciona la interfaz queda separado del cómo representarlo en pantalla. Idealmente el patrón MVP permitiría conseguir que una misma lógica pudiera tener vistas totalmente diferentes e intercambiables.
Lo primero a tener claro es que el MVP no es un patrón de arquitectura de aplicaciones, sólo se encarga de la capa de presentación. En cualquier caso siempre es mejor usarlo para la arquitectura que no usarlo en absoluto.
¿Por qué usar MVP?
En Android tenemos un problema derivado del hecho de que las actividades en Android están íntimamente acopladas tanto con la interfaz como con las mecánicas de acceso a datos. Hasta tal punto que existen clases como el CursorAdapter, que mezclan los adaptadores, que son parte de la vista, con los cursores, algo que debería estar relegado a lo más profundo de la capa de acceso a datos.
Para que una aplicación sea fácilmente extensible y mantenible necesita tener bien separadas sus capas. ¿Qué hacemos si mañana en vez de tirar de base de datos necesitamos hacerlo de un servicio en la red? Tendríamos que rehacer toda la vista.
El MVP independiza la vista de la forma de conseguir esos datos. Nos divide la aplicación en, al menos, tres capas distintas, pudiendo además testear cada una de ellas de forma independiente.
¿Cómo implementar MVP en Android?
Pues aquí es donde todo comienza a ser más difuso. Hay muchas variaciones de MVP y cada uno puede ajustar la idea del patrón a sus necesidades y a la forma en que se sienta más cómodo. El patrón varía sobre todo en función de la cantidad de responsabilidades que deleguemos en el presentador.
¿Es la vista la que tiene que activar o desactivar una barra de progreso, o se debe encargar el presentador? ¿Y quién decide qué botones deben pintarse en la Action Bar? Ahí es donde comienzan las decisiones difíciles. Yo os mostraré cómo suelo trabajar, pero quiero que este artículo sea más un foro para el debate que unas guías estrictas de cómo aplica el MVP, porque a día de hoy no existe una forma estandarizada de implementarlo.
El presentador
El presenter se encarga de actuar de intermediario entre la vista y el modelo. Recupera los datos del modelo y se los devuelve a la vista formateados. Pero a diferencia del MVC típico, también decide qué ocurre cuando se interactúa con la vista.
La vista
La vista, habitualmente implementada por una Activity (aunque puede ser un fragment, una View… según como se estructure la App), contendrá una referencia al presenter. Lo ideal sería inyectárselo a la actividad mediante Dagger, pero en el caso de no usarlo, será la vista la encargada de crear el objeto presentador. Lo único que hará la vista será llamar a un método del presenter cada vez que se realice una acción sobre la interfaz, normalmente el pulsado de un botón, un elemento de una lista, etc.
El modelo
En una aplicación con una buena arquitectura por capas, este modelo no sería más que la puerta de enlace a la capa de dominio o de lógica de negocio. Si estuviéramos utilizando la clean architecture de Uncle Bob, seguramente el modelo sería un interactor que implemente algún caso de uso. Pero este es otro tema que me gustaría tratar en futuros artículos. Por ahora es suficiente con verlo como el proveedor de los datos que queremos mostrar en la vista.
Entonces..
Independizar la interfaz de la lógica en Android no es tarea sencilla, pero con el patrón Model-View-Presenter se hace un poco más fácil evitar que nuestras actividades acaben siendo clases muy acopladas de cientos o incluso miles de líneas. En aplicaciones grandes se vuelve imprescindible organizar bien nuestro código si queremos que su mantenimiento y ampliación no se vuelva imposible.
Te esperamos en los siguientes artículos en donde hablaremos mas acerca de estos temas, los cuales hoy en día son de vital importancia en el mundo de la tecnología.
