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
      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:
      3. Este proceso se muestra en el siguiente esquema:

      4. 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:
        • 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.
      5. 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:
      6. 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.