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.
¿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 lacapa 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éndecide qué botones deben pintarse en la Action Bar? Ahí es donde comienzan las decisiones difíciles.
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.
Conclusión
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 próximos artículos en donde hablaremos mas acerca de estos temas que hoy en día son de importancia e interés en el mundo de la tecnología.
