Arquitectura VIPER para proyectos móviles nativos en Bancolombia
En esta etapa natural de progreso de la tecnología en la que nos encontramos, es muy importante cuidar el tipo de arquitectura vamos a utilizar para esos proyectos o satélites que deben ser desarrollados en tecnologías nativas (iOS, Android), y que suelen ser desarrollados en los patrones sugeridos por los creadores de cada lenguaje o en patrones conocidos por cada desarrollador.
V.I.P.E.R, es una adaptación de la Clean Architecture propuesta por el “gurú” de la ingeniería del software Robert C. Martin, conocido familiarmente como “Uncle Bob”, y aparece por primera vez en este artículo de 2014. Inicialmente fue propuesto para apps iOS, pero ahora también es extensible para otras tecnologías como Android y Xamarin, donde muchos desarrolladores han hecho innumerables implementaciones.
En este caso, queremos presentar una alternativa funcional alineada con las arquitecturas limpias en las que estamos trabajando actualmente, y que ha mostrado ser de gran ayuda en otros lenguajes y plataformas en la organización: V.I.P.E.R.
¿Qué es V.I.P.E.R.?
V.I.P.E.R. es un acrónimo en ingles para View, Interactor, Presenter, Entity y Router. Es básicamente una aproximación a la implementación del principio de responsabilidad única o SRP para llegar a crear una estructura limpia y modular para nuestros proyectos. Su arquitectura se refleja de la siguiente forma:
Cada bloque representa un objeto con una tarea especifica y contiene una entrada y salida que será utilizada por el objeto siguiente, en el marco de una aplicación, de acuerdo con el esquema:
La vista corresponde a un UIView, actividad o fragmento desligado de cualquier lógica. Estas deben ser lo mas básicas posible y solo deben encargarse de mostrar la interfaz de usuario.
El presentador actúa como coordinador entre las partes, ordena la consulta de información al interactor y este, a su vez, responde al presentador con la información necesaria para mostrar o ejecutar alguna acción en una vista; además, se encarga de la navegación a través del enrutador.
El interactor ejecuta acciones solo cuando el presentador lo indica. A través de él, se realizan las conexiones a los modelos de datos.
La entidad representa los datos de la aplicación. Actúa como el modelo en el patrón de arquitectura MVP.
El enrutador maneja la navegación a otras pantallas durante el ciclo de vida de la aplicación.
Ventajas
- Simplifica los proyectos complejos. Funciona muy bien para equipos de gran tamaño.
- Lo hace escalable. Habilita a los desarrolladores a trabajar simultáneamente sin problemas.
- Desacopla el código para volverlo testeable y re-utilizable.
- Divide los componentes de la aplicación y facilita separar las responsabilidades claramente.
- Permite que añadir nuevas características sea más fácil.
- Brinda mayor facilidad para llevar la cuenta de los problemas vía crash reports debido a los principios de responsabilidad única.
- Hace el código de fuente más claro, compacto y reusable.
Desventajas
Como inconveniente principal está la sobrecarga, pues supone crear un mínimo de 5 componentes por cada módulo. Es una arquitectura que para aplicaciones pequeñas o implementadas por un solo desarrollador, quizás presente una complicación excesiva y en estos casos se recomienda el uso de MVVM.
Todo esto lo explicaremos con más detalle, ya que es importante entender cada una de las partes, su responsabilidad y la forma de implementación.
View
Corresponde a la interfaz de usuario. Su única responsabilidad es mostrar aquello que el presentador le indique y manejar las interacciones del usuario en la pantalla. Si estas acciones disparan un evento que requiera procesamiento, la vista delega la función al presentador y espera la respuesta del presentador, quien le indicará qué debe hacer.
La vista corresponde a un UIView, actividad o fragmento. Puede ser implementada por programación o usando los constructores de interfaces (IB) para Android y iOS.
Android
iOS
Presenter
El presentador corresponde al conector entre los módulos de VIPER. Actúa como un orquestador entre las partes, recibe solicitudes de información desde la vista y las envía al interactor. Una vez este responde, reacciona para dar respuesta a la solicitud, aplica la lógica que la vista requiera, prepara la información recibida desde el interactor y, finalmente, le indica a la vista o al enrutador la acción siguiente.
Android
iOS
Interactor
El interactor es el módulo donde se realiza toda la lógica de negocio relacionada conlas entidades y debe ser totalmente independiente de la interfaz de usuario. Este módulo es el encargado de hacer las peticiones de información a los servicios, manejar las respuestas y convertirlas a las entidades correspondientes. Una vez hecho esto, el interactor debe notificar al presentador los resultados para que este continúe el flujo. Es importante que toda la lógica de negocio sea implementada en este módulo y no sea trasladada al presentador (aquí debe llegar la información lista para usar).
Android
iOS
Entity
La entidad es la capa que define los modelos de datos. Es el modulo más simple de la estructura V.I.P.E.R y es la carga útil que se utiliza en los demás módulos.
Android
iOS
Router
El enrutador es el responsable de la lógica de navegación entre módulos y de definir cómo se debe realizar la transición entre dos pantallas. Recibe del presentador las indicaciones para saber a qué pantalla debe dirigirse; además, se encarga de pasar datos de una pantalla a otra.
iOS
Adicionalmente, se comparte los repositorios en Git: Android e iOS.
A continuación, te compartamos la documentación en la que nos hemos basado basado para escribir este artículo:
- Clean architecture: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
- VIPER: https://www.objc.io/issues/13-architecture/viper/
- Android VIPER: https://www.raywenderlich.com/5192-android-viper-tutorial
- iOS Project Architecture: Using VIPER: https://medium.com/build-and-run/clean-architecture-en-ios-viper-893c8c3a75a4
Richard Javier Bedoya, Alejandro Gil Tobón
