Adaptación de una arquitectura universal para plataformas móviles

Siempre estamos mirando hacia adelante en Launch, razón por la cual nos movimos para integrar una arquitectura universal para nuestro equipo móvil en las plataformas iOS y Android. Ha cambiado la forma en que todo el equipo crea aplicaciones, estima nuevos trabajos y entrena cruzando plataformas. Entonces, ¿qué hicimos y por qué lo hicimos?

Fuimos con una arquitectura Model-View-Presenter (MVP) modificada. MVP es un patrón de diseño maduro, y hay un montón de artículos e información sobre qué es MVP, por lo que mantendremos esta discusión de su arquitectura de aplicación a software en un alto nivel. La M significa Modelo. Alberga todos los datos y conexiones de red. Además de estos componentes principales, hemos adoptado el concepto de UseCases de la arquitectura Clean, que permite que nuestras llamadas a la capa de datos y otras lógicas sean reutilizables y del tamaño de un bit. La V significa View, la parte de la aplicación que muestra contenido al usuario y envía eventos desde las interacciones del usuario hasta el Presenter. La Vista es tonta y no sabe hacer nada a menos que implique dibujar o animar. Dentro de ese ámbito de visualización, la vista puede ser tan inteligente como sea necesario. El P significa Presentador. El Presentador recibe eventos de la Vista y emite órdenes a la Vista a medida que interactúa con la capa de datos de la aplicación.

Esta arquitectura permite que nuestras Vistas estén desprovistas de lógica de negocio, nuestros Presentadores contengan (casi) todos los datos y el enrutamiento de eventos del usuario sea comprobable. Nuestra capa de datos puede centrarse exclusivamente en la búsqueda y modelado de datos. Es limpio y sencillo. Existen muchas arquitecturas que pueden hacer lo mismo, entonces ¿por qué fuimos con esta versión de MVP? Cuando elegimos una arquitectura, queríamos tener algo que funcionara bien en ambas plataformas. Si bien Android empuja a MVVM, y Apple tiene una larga historia con MVC, no sentimos que ninguno de los dos enfoques funcionaría tan bien en ambas plataformas. Debido a que MVP está cerca de MVC, pudimos adaptarlo bastante rápido tanto en iOS como en Android. Hemos implementado un conjunto similar de clases base e interfaces en Swift y Kotlin que permitió a nuestro equipo móvil unificar nuestro enfoque para construir aplicaciones nativas en ambas plataformas.

Eficiencia de conducción

Dado que Swift y Kotlin son lenguajes similares, nuestros ingenieros pueden aprender rápidamente a trabajar en Android e iOS. El hecho de que nuestro enfoque interno compartan la misma arquitectura y la misma ideología de diseño MVP hace que sea fácil para nuestros ingenieros principales diseñar los protocolos o interfaces para las partes más importantes de un proyecto en ambas plataformas. Un equipo también puede hacer referencia a los detalles de implementación a partir del trabajo que ya se ha realizado en la otra plataforma. Nuestros ingenieros pueden abrir un proyecto en ambas plataformas y encontrar fácilmente dónde se implementa una pieza de funcionalidad. A medida que nuestros desarrolladores ganan facilidad en Android e iOS, cuando necesitan agregar una función, ya están pensando en cómo hacerlo en cualquiera de las plataformas. Los ingenieros que antes solo conocían Android o iOS podrían rápidamente subir al otro. Esto es especialmente cierto para las nuevas contrataciones — dado que casi todos nuestros proyectos se convierten en ejemplos de esa arquitectura en ambas plataformas, el conocimiento institucional es fácilmente accesible.

Nada es perfecto, y todavía hay algunos baches en el camino, pero que el equipo se desplace a donde existe una necesidad de proyecto es invaluable. En lugar de contratar a otro desarrollador de Android, podemos hacer que nuestros desarrolladores de iOS se vuelvan totalmente capaces de escribir en Android (y viceversa). O bien, si necesitamos contratar al nuevo desarrollador de Android, pueden cambiar más fácilmente a iOS en unos meses cuando se complete el proyecto de Android para el que fueron contratados inicialmente.

Adaptación

Al administrar nuestra propia arquitectura compartida, también podemos realizar cambios rápidamente cuando cambia cualquiera de las plataformas. Un ejemplo destacado de esto que completamos recientemente fue el soporte de los cambios de ViewBinding en Kotlin que reemplazaron las capacidades de vista sintéticas que inicialmente se soportaron. Dado que nuestras clases View contenían solo código de vista, la transición fue fluida y no ralentizaron otras áreas del desarrollo de aplicaciones.

Las características de arquitectura limpia que agregamos después de nuestro cambio inicial a una arquitectura común para ambas plataformas también han sido una adición bienvenida que solucionó un problema, ya que nuestros presentadores a menudo tienen lógica de código duplicada en múltiples pantallas. Y dado que este es nuestro trabajo interno, obtenemos flexibilidad de alto nivel que nos permite agregar características y corregir errores en nuestras clases base tan pronto como las necesitemos. No estamos atrapados en un ciclo esperando una solución de terceros o creando soluciones alternativas que pueden romperse nuevamente más tarde. Al continuar invirtiendo en nuestras propias bibliotecas internas, podemos evolucionarlas al ritmo que necesitamos, y continuamos explorando la adición de nuevas funcionalidades para que nuestro código base sea más claro para los desarrolladores que asumirán un proyecto en una fecha posterior.

Nuestra biblioteca interna continuará evolucionando y tomando forma de la manera que mejor se adapte al equipo. Estamos explorando cómo los cambios en los kits de herramientas de interfaz de usuario pueden afectar a nuestra biblioteca MVP en un futuro próximo. A medida que SwiftUi y Compose están saliendo de su infancia, podemos investigar nuevas eficiencias que se obtendrán. Al mismo tiempo, como equipo ahora tenemos la experiencia que ayuda a llevar el performance nativo a bases de código separadas que están estrechamente alineadas.

¿Interesado en aprender cómo podría integrar una arquitectura universal para sus equipos móviles? Contáctanos ¡para impulsar la eficiencia e implementar una solución de arquitectura MVP propia!