Kotlin Multiplataforma Android / iOS: Estrategias de estructura de proyectos

Bienvenido, soy Miguel y aquí les traigo este post.

Multiplataforma Kotlin

Multiplataforma Kotlin (KMP) es una forma de escribir código multiplataforma en Kotlin. No se trata de compilar todo el código para todas las plataformas y no lo limita a un subconjunto de API comunes.

KMP proporciona mecanismos para escribir implementaciones específicas de la plataforma para una API común.

Android / iOS

Uno de los casos de uso comunes, y de hecho mi caso de uso principal, para KMP es compartir código entre un proyecto de Android e iOS.

Opciones

Con KMP tiene algunas opciones diferentes a la hora de decidir cómo estructurar sus proyectos.

Todo en uno

Puede combinar su proyecto de Android e iOS en un solo proyecto. Vivirían dentro del mismo directorio y ambos podrían acceder y construir el código compartido de KMP.

Beneficios

El principal beneficio de este enfoque es lo fácil que es acceder al código compartido. Independientemente de la plataforma en la que esté trabajando,  puede acceder, actualizar y crear el código compartido .

Esto acelera el desarrollo, especialmente para equipos de desarrollo individuales.

Inconvenientes

Esta configuración puede resultar abrumadora para los nuevos miembros del equipo que se unen a un proyecto. Hay mucho código para digerir y comprender.

Para equipos con desarrolladores independientes de Android e iOS, trabajar de esta manera puede resultar complicado.

Se pueden realizar cambios en el código compartido, lo que requiere cambios en ambas plataformas. Lo que significa que  debe trabajar más en conjunto , lo que puede resultar difícil para la programación de recursos.

Todos separados

Puede separar completamente sus proyectos compartidos y de plataforma. Esto implica escribir lógica de compilación (Gradle) para distribuir su código compartido entre proyectos.

Android Lib

KMP proporciona una tarea gradle para crear un archivo JAR de JVM para el código de Android.

./gradlew [targetName] Jar

Marco de iOS

Para crear el marco necesario para iOS, puede escribir una tarea gradle personalizada, por ejemplo:

task releaseFatFramework(type: FatFrameworkTask) { 
    group = LifecycleBasePlugin.BUILD_GROUP
    baseName = frameworkName 
    destinationDir = file("$buildDir/fat-framework/release") 
    from( 
        kotlin.targets.iosX64.binaries.getFramework("RELEASE"), 
        kotlin.targets.iosArm64.binaries.getFramework("RELEASE")
    ) 
}

Esto puede variar según la configuración de destino exacta.

Beneficios

El código tiene una buena separación de preocupaciones y es ideal para equipos más grandes. Puede distribuir el código compartido de una manera más estructurada. Decidir exactamente cuándo lanzar a las dos plataformas.

Para equipos más grandes, que tienen ingenieros de Kotlin separados, este podría ser un enfoque útil.

Inconvenientes

Este enfoque podría resultar en una gran cantidad de configuración de CI y repetición. Probablemente lleve más tiempo configurarlo.

Tener que tener varios proyectos abiertos provocará cambios frecuentes de contexto durante el desarrollo. También se necesitará más carga cognitiva para comprender la imagen completa.

Terreno medio

El enfoque de término medio significaría tener el código compartido dentro de uno de los proyectos de la plataforma.

Esto naturalmente (y posiblemente obviamente) caería dentro del proyecto de Android. Esto no es necesario, pero dado que comparte un idioma con Android, esta sería mi recomendación.

Dentro del proyecto de Android, configura el código compartido como un módulo KMP. IntelliJ tiene algunos asistentes útiles para esto.

Este enfoque hace que, dependiendo del código compartido, dentro de Android, sea fácil:

dependencies {
    // ...
    implementation project(':shared')
    // ...
}

Luego, puede agregar una tarea de generación de marco para iOS, como la que se detalla anteriormente.

Luego integré esta generación de marco en nuestra estrategia de CI. Todas las noches, si el código compartido ha cambiado, enviamos una solicitud de extracción al proyecto de iOS.

Esta solicitud de extracción actualiza el marco compartido. Esto significa que su equipo de iOS estará al tanto de la actualización y podrá fusionar el cambio rápidamente. También encaja en el proceso de CI de iOS, y le advierte de cualquier error de prueba y, por lo tanto, de los cambios necesarios.

Usamos CircleCI (versión 2.1), y esta es la configuración del trabajo:

Trabajo:

Comandos:

Variables de entorno:

Beneficios

Este enfoque reduce la carga cognitiva y minimiza la configuración y el modelo estándar. Mantiene el código de Kotlin en un proyecto, por lo que no presenta más gastos generales a su equipo de iOS.

Inconvenientes

Es posible que traspasar la responsabilidad del código compartido a su equipo de Android no sea el enfoque adecuado para usted. Significa programar sus recursos de manera diferente.

Nuestro Enfoque

Actualmente usamos KMP para compartir el M (Modelo de MVVM) entre Android e iOS. Lo que significa que compartimos lógica empresarial, integración de API y almacenamiento de datos local.

Estos conceptos no suelen requerir variaciones específicas de la plataforma y se comparten bien entre plataformas.

Intentamos programar nuestro trabajo de Android un poco antes que iOS, para dar tiempo a que se inicie el código compartido. Esto facilita el desarrollo de iOS y reduce la cantidad de bloqueos.

Espero que te haya sido de utilidad. Gracias por leer.