👍🏻 🎅 😧 HandsAppMVP: arquitectura iOS para la subcontratación de desarrollo de estudio 🙅🏾 🌠 🔎

Un buen código comienza con la arquitectura, y las aplicaciones de iOS no son una excepción. Existen muchos patrones estándar, pero el propósito de este artículo no es hablar sobre ellos, sino sobre la experiencia de adaptar uno de ellos y desarrollar el suyo propio. Llamamos a esta adaptación HandsAppMVP.

imagen

En el desarrollo de iOS, la arquitectura determina principalmente la organización de clases y dependencias para un ViewController específico. Sin embargo, el componente central puede ser no solo él, sino simplemente UIView. La elección depende de la tarea específica.

Comparación de arquitectura

Existen varias plantillas arquitectónicas estándar para iOS: MVC, MVP, MVVM, VIPER (los enlaces a la descripción de cada uno se pueden encontrar al final del artículo).

Al elegir una arquitectura para el desarrollo, identificamos los principales parámetros a los que debe corresponder: velocidad de desarrollo, flexibilidad y un umbral de entrada bajo. A continuación, comenzamos a comparar tres arquitecturas conocidas con estos parámetros en mente (la plantilla de la comunidad MVC iOS ha estado enterrada durante mucho tiempo debido al grave incumplimiento de la responsabilidad única).

Para un equipo de outsourcing, la velocidad de desarrollo es especialmente importante. VIPER es la arquitectura más compleja y "lenta", el desarrollo es más rápido utilizando MVP o MVVM puro, ya que tienen menos componentes.

Flexibilidad significa la adición o eliminación indolora de funcionalidad en la aplicación. Este parámetro se correlaciona fuertemente con la velocidad de desarrollo en todas las etapas de la vida de la aplicación, excepto la inicial. La flexibilidad también está estrechamente relacionada con la simplicidad de las pruebas: las pruebas automáticas le dan al desarrollador la confianza de que no romperá nada y ayudan a evitar errores. MVP clásico está mal cubierto por las pruebas, especialmente si no utiliza las interfaces de clase que se analizan a continuación. MVVM desde el punto de vista de las pruebas también tiene un bajo rendimiento, ya que la prueba del código reactivo lleva mucho más tiempo. VIPER es excelente para escribir exámenes porque respeta el principio de responsabilidad exclusiva en la mayor medida posible y las clases dependen de abstracciones.

Y el último parámetro que consideramos es el umbral de entrada. Muestra la rapidez con la que los nuevos desarrolladores (en primer lugar, los jones) penetran en la arquitectura. Aquí MVVM que usa bibliotecas reactivas de terceros (RxSwift, PromiseKit, etc.) ocupa un último lugar honorable por razones obvias. VIPER también es una arquitectura bastante compleja debido a la gran cantidad de componentes. MVP tiene el umbral de entrada más bajo.

Después de sopesar los pros y los contras, llegamos a la conclusión de que necesitamos algo tan simple como MVP y tan flexible como VIPER. Entonces, la idea nació para crear su propia arquitectura basada en ellos: HandsAppMVP.

Expandir MVP

Los componentes principales de nuestra arquitectura son Modelo, Vista, Presentador. Realizan las mismas funciones que en el MVP clásico de acuerdo con el esquema bien conocido:

imagen

[Esquema del MVP clásico]

Aquí y a continuación, cada componente de interacción (cuadrado azul) en los diagramas es una clase cuya vida coincide con la vida útil de la Vista. Una flecha sólida indica la propiedad de otro objeto, un enlace fuerte, y una flecha punteada indica un enlace débil. Con referencias débiles, evitamos dependencias circulares y pérdidas de memoria.

Interfaces

Primero, agregamos las interfaces ViewInput y ViewOutput a este esquema clásico. Tomamos en cuenta el quinto principio de SOLID: el principio de inversión de dependencia. Es más probable que no sea una adición, sino un refinamiento para MVP. La dependencia de las abstracciones ayuda a eliminar la estricta conexión de los componentes y le permite escribir pruebas normalmente. El esquema que tiene en cuenta las interfaces tiene este aspecto:

imagen

[Agregar interfaces ViewInput y ViewOutput] Un

pequeño rectángulo es una interfaz.

Un desarrollador atento preguntará, ¿dónde están las interfaces para Model? Ahora nos dirigimos a ellos.

Trabajar con datos

El modelo de datos en arquitecturas móviles es un concepto colectivo. Un ejemplo estándar: una aplicación llama a la red para interactuar con el servidor, luego guarda datos en CoreData para el trabajo fuera de línea, escribe información simple en UserDefaults y almacena el JWT en Keychain. Todos estos datos con los que se interactúa forman el Modelo.

La clase que es responsable de interactuar con el contenedor de datos de un tipo particular, llamamos al servicio de datos. Para cada contenedor (base de datos remota, base de datos local, UserDefaults, etc.), se agrega una clase de servicio a HandsAppMVP que interactúa con el presentador. Ahora también puede agregar interfaces de entrada / salida para cada servicio de datos:

imagen

[Agregar servicios para trabajar con datos]

No todas las clases de servicio deben conectarse al presentador mediante una interfaz, como, por ejemplo, cuando se utiliza Moya. Moya es una biblioteca de red de código abierto. Moya proporciona una clase de servicio preparada (MoyaProvider), y al escribir pruebas, no tenemos que crear un objeto simulado que reemplace a ApiProvider. Moya proporciona un modo de prueba especial, cuando está activado, MoyaProvider no interrumpe la red, pero devuelve datos de prueba (se pueden encontrar más detalles aquí). En este caso, el presentador no se refiere a la abstracción de MoyaProvider, sino a la implementación. Y recibimos comentarios de este servicio mediante cierres. Un ejemplo de implementación se puede encontrar en el proyecto de demostración.

Este ejemplo es más una excepción que una regla, y muestra que la adhesión a SOLID no siempre es la mejor solución.

Navegación

Consideramos la navegación en la aplicación como una responsabilidad separada. HandsAppMVP utiliza una clase especial para ello: enrutador. El enrutador contiene un enlace débil a la Vista, con el que puede mostrar una nueva pantalla o cerrar la actual. El enrutador también interactúa con el presentador utilizando la interfaz RouterInput:

imagen

[Agregar un componente para la navegación (Enrutador)]

Ensamblaje de componentes

La última adición al MVP clásico que usamos es Assembly, una clase de colección. Se utiliza para inicializar la Vista y otros componentes de HandsAppMVP, así como para implementar dependencias. El ensamblaje contiene el único método público: `assemble () -> UIViewController`, cuyo resultado es el UIViewController deseado (o UIView) con el gráfico de dependencia necesario.

No mostraremos Ensamblaje en el diagrama de arquitectura, ya que no está conectado con componentes MVP y su ciclo de vida finaliza inmediatamente después de su creación.

Codigo de GENERACION

Para ahorrar tiempo, automatizamos el proceso de creación de clases HandsAppMVP usando Generamba. Las plantillas utilizadas para Generamba se pueden encontrar en nuestro repositorio. Un ejemplo de configuración para Generamba está en el proyecto de demostración.

Como resultado de generar una pantalla específica, obtenemos un conjunto de clases que corresponde al esquema HandsAppMVP, un conjunto de pruebas unitarias para crear e implementar componentes, y también una clase de plantilla para pruebas de presentador.

Que pasó

Si compara Head-to-Head HandsAppMVP y VIPER, notará que son muy similares y el primero solo se distingue por la ausencia del componente Interactor. Pero, al deshacernos de la capa entre los servicios y el presente (el interactor), además de simplificar la interacción con la red usando Moya, recibimos un notable aumento en la velocidad de desarrollo.

Le recomendamos que preste suficiente atención a la arquitectura en la etapa de diseño para evitar errores globales, disputas con los clientes y el tormento de los desarrolladores en el futuro, y en su lugar liderar el proceso de desarrollo de manera competente y previsible.

Recuerde que cualquier arquitectura puede no ser adecuada específicamente para su proyecto, así que no se apresure a aferrarse ciegamente a plantillas ya preparadas e historias exitosas de su aplicación. No tenga miedo de desarrollar y aplicar sus soluciones, pueden ser más valiosas y flexibles para usted que las ya preparadas.

En conclusión, recomendaremos algunos buenos artículos sobre la arquitectura de las aplicaciones de iOS que nos ayudaron a comprender las complejidades y tomar una decisión:

La documentación de código abierto de SurfStudio también fue muy útil e inspirada .

Finalmente, estamos poniendo un enlace en el proyecto DEMO , escrito en HandsAppMVP, que hemos mencionado repetidamente en el artículo.

HandsAppMVP: arquitectura iOS para la subcontratación de desarrollo de estudio