El patrón MVP (Model View Presenter) es un derivado del conocido MVC (Model View Controller), que está ganando popularidad e importancia en el desarrollo de aplicaciones Android. Nos proponemos determinar las principales razones por las que podemos y debemos utilizar este patrón arquitectónico.
En primer lugar, debemos definir la diferencia con el patrón MVC, y podemos mostrarla de forma esquemática:
Las principales diferencias del MVP con respecto al MVC son
- La vista está separada del modelo, el presentador es un intermediario entre la vista y el modelo;
- es más fácil crear pruebas unitarias;
- normalmente, podemos utilizar varios Presentadores para Vistas complejas.
Veamos cada elemento en detalle, y destaquemos sus principales ventajas:
Siguiendo uno de los principales conceptos de la Arquitectura Limpia, “Divide y vencerás”, el patrón MVP permite separar la capa de presentación de la lógica. En este caso las funciones principales de cada elemento son:
- La Vista. La actividad o el fragmento se privará del procesamiento de datos y se limitará a la visualización. Por ejemplo, aquí un fragmento implementa una determinada interfaz con funciones
public interfece ListInterface { void showError(); void showItems(List someItems); } - El present ador se encarga por completo de la lógica de negocio. Las
solicitudes para obtener datos de un servidor o de una base de datos (comunicación con el
modelo) se implementan aquí. Tras recibir los datos, todo el procesamiento de los mismos
recae también en el presentador. Tras el procesamiento, la información se pasa a la vista a
través de la misma interfaz://If the result is a mistake getView.showError(); //If the result is successful - we pass the data getView.showItems(someitems); - Cobertura de las pruebas unitarias. La principal ventaja es la posibilidad de probar cada parte por separado. También podemos seleccionar la tecnología y el enfoque de las pruebas unitarias.
- Para la vista es conveniente utilizar Mockito, Robolectric con anotaciones @Before, @Test, @After. Ejemplo:
@Before public void setUp() { TestHelper.getTestClassInjector() .inject(this); Assert.assertTrue(TestHelper.getBaseComponent().getLocalDataCache() instanceof MockLocalDataCache); Assert.assertTrue(TestHelper.getBaseComponent().getRetrofit() instanceof MockRetrofit); Assert.assertTrue(TestHelper.getBaseComponent().getOkHTTP() instanceof MockOkHTTP); } @Testpublic void testWebPage() { viewModel.loadWebPage(SOME_URL) .toBlocking(). forEach(s -> { Assert.assertTrue(s.contains(MockRetrofit.MOCKED_STRING)& & s.contains(SOME_URL)); }); } - Probaremos el presentador de la misma manera que probamos el modelo, con una simple prueba JUnit. Sin embargo, esta vez, proporcionaremos una vista modificada para asegurarnos de que el presentador está correctamente vinculado a la vista. Nuestro presentador obtendrá la vista y recibirá los datos del modelo para mostrarlos en la vista.
@Before public void setUp() throws Exception { MockitoAnnotations.initMocks(this); when(interactor.getUserProfile()).thenReturn(Observable.just(newUserProfile())); presenter = new ProfilePresenter(interactor);presenter.attachView(view); } @Test public void testDisplayCalled() { verify(interactor).getUserProfile(); verify(view).display(any()); } public void fetchAndDisplay() { interactor.getUserProfile().subscribe(userProfile -> view.display(userProfile)); } - Independencia del ciclo de vida de la aplicación. Un ejemplo es cuando hacemos una consulta y un usuario pliega una aplicación, o cambia la orientación de la pantalla. Nuestra consulta no está relacionada con la actividad y no falla, los datos pueden ser obtenidos, y mostrados cuando la vista cambia el estado a inResume() de nuevo. Es necesario comprobar que la actividad es nula:
if (getActivity != null) { // working with ui… getView.showResult(result); } -
Posibilidad de utilizar un presentador por varias vistas. Cuando utilizamos la misma lógica para varias pantallas, por ejemplo, recibir y actualizar una lista de mensajes, podemos utilizar un solo presentador que contenga toda la lógica para estas dos vistas.Por ejemplo, hay un presentador y 2 fragmentos de recepción de mensajes: - MessageUpdatePresenter;
- SentMessagesFragment implementa MessageUpdatePresenter;
- DraftsMessagesFragment implementa MessageUpdatePresenter;
En cada fragmento implementamos la interfaz MessageUpdatePresenter, sea el método showMessages(List <Message> messages).
Durante el desarrollo de una aplicación Android para una importante empresa de marketing alemana, se nos planteó el reto de crear la arquitectura de una aplicación compleja multifuncional. Después de discutirlo con el equipo, nos decidimos por el uso de MVP, y nos permitió:
- separar la lógica de negocio de la presentación, estructurarlo todo y dividir la
carga; - aumentar considerablemente la calidad del producto con la ayuda de una cómoda
cobertura de pruebas, que es mucho más fácil y rápida de escribir; - disminuir el número de repeticiones en el código, ya que el presentador puede
reutilizarse.
Este proceso se muestra en el siguiente esquema:
Durante el desarrollo de una aplicación Android para una importante empresa de marketing alemana, se nos planteó el reto de crear la arquitectura de una aplicación compleja multifuncional. Después de discutirlo con el equipo, nos decidimos por el uso de MVP, y nos permitió:
Acerca de RedwerkRedwerk
lleva en el negocio del desarrollo de aplicaciones móviles desde 2005.
Durante los últimos trece años, hemos desarrollado con éxito muchas aplicaciones para iOS y Android que han
reunido a cientos de miles de usuarios en todo el mundo. Proporcionamos un ciclo completo de desarrollo de
aplicaciones móviles desde la idea hasta el lanzamiento y garantizamos soluciones de alta calidad para
nuestros clientes.
