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:
- 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
123456public interfece ListInterface {void showError();void showItems(List<Object> 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:
123456//If the result is a mistakegetView.showError();//If the result is successful - we pass the datagetView.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:12345678910111213141516@Beforepublic 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.1234567891011121314151617@Beforepublic void setUp() throws Exception {MockitoAnnotations.initMocks(this);when(interactor.getUserProfile()).thenReturn(Observable.just(newUserProfile()));presenter = new ProfilePresenter(interactor);presenter.attachView(view);}@Testpublic 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:123456if (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:
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.
