Arquitectura MVP de Android: 4 razones para usarla

La flexibilidad de Android le permite diseñar la aplicación de la forma en que se sienta cómodo. Ofrece
a los desarrolladores tanto un poder significativo para crear grandes aplicaciones como problemas con la
diferencia de enfoque. Por lo tanto, la necesidad de utilizar algún patrón de arquitectura es obvia.

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:

1. 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<Object> someItems); }

   1 2 3 4 5 6

   public interfece ListInterface {     void showError();     void showItems(List<Object> someItems);     }

2. 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);

   1 2 3 4 5 6

   //If the result is a mistake getView.showError(); //If the result is successful - we pass the data getView.showItems(someitems);

Este proceso se muestra en el siguiente esquema:

3. 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)); }); } 

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  @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)); }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  @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)); }

4. 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); }

   1 2 3 4 5 6

   if (getActivity != null) { // working with ui… getView.showResult(result); }

5. 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.

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.