Retour d’expérience sur Kotlin Multiplatform Mobile (KMM)

by Antoine Marcadet · 5 août 2021

KMM ou Kotlin Multiplatform Mobile est un outil de développement crossplatform pour applications mobiles offrant une nouvelle approche au développement hybride en prenant le parti pris de mutualiser les logiques métiers et de conserver un développement natif pour la partie graphique. Encore en version Alpha aujourd’hui, le site officiel référence déjà Netflix, Philips, Autodesk ou encore VM Ware parmi ses utilisateurs. Comme toute technologie hybride il est possible développer des briques communes mais également des briques spécifiques à chaque plateforme comme nous le verrons dans la suite de l’article.

Cet article nécessite des connaissances en Gradle et Kotlin ainsi que quelques bases avec les outils de l’écosystème iOS tels que Cocoapods.

L’objectif de cet article n’est pas de reprendre la documentation officielle mais de vous présenter la solution mise en place chez Sedona afin de pouvoir livrer une librairie développée via KMM qui sera ensuite intégrée au sein de deux applications natives Android et iOS. Afin de favoriser une bonne adoption et intégration au sein des habitudes et des outils de chacune des deux plateformes, la librairie sera mise à disposition via Artifactory pour Android et Cocoapods pour iOS.

À la différence de ce qui est présenté dans la documentation officielle, nous n’utiliserons pas KMM pour compiler les applications mais uniquement pour compiler une librairie. En effet, nous avons souhaité intégrer KMM dans une application déjà existante et limiter l’impact sur la toolchain en place au minimum, c’est-à-dire au simple ajout d’une dépendance.

Initialisation du projet

Tout d’abord veuillez suivre les instructions de la documentation officielle de KMM pour créer votre nouveau projet (anglais).

La structure de votre projet devrait ressembler à celle présente sur la capture ci-contre (à la différence que shared a été renommé libutils dans notre cas).

androidApp : contient le code source de l’application Android ;
iosApp : contient le code source de l’application iOS ;
libutils : contient le code source de notre librairie qui sera partagée entre iOS et Android.

Au sein de votre dossier shared vous trouverez les répertoires suivants :

androidMain et iosMain : contiennent le source spécifique à chaque plateforme ;
commonMain : contient le code source partagé entre les différentes plateformes.

Chaque source est accompagnée d’un dossier destiné à recevoir les tests associés.

Passage à la pratique

Préambule

KMM introduit deux nouveaux mots clefs :

expect : utilisé dans les sources appartenant au commonMain, ce mot clé permet d’indiquer au compilateur qu’une implémentation spécifique à une plateforme est disponible dans le dossier correspondant ;
actual : utilisé dans les sources spécifiques à chaque plateforme afin de fournir l’implémentation spécifique à la plateforme.

D’un point de vue conceptuel, on peut assimiler le mot clef expect à une abstract. Ces deux nouveaux mots clefs permettront de réaliser des implémentations spécifiques par plateforme comme par exemple une écriture disque ou l’utilisation d’une librairie spécifique à un OS, nous y reviendrons dans la suite de l’article.

Ajout des dépendances

Dans notre projet nous avons utilisé les librairies Storage et RemoteConfig de Firebase avec une implémentation spécifique à chaque plateforme en fonction des besoins.

Tout d’abord il faut ajouter les dépendances suivantes pour Android dans le fichier gradle présent dans le dossier shared/build.gradle.kts :

kotlin {
    // ...
    android() {
        publishLibraryVariants("release")
    }
    // ...
    sourceSets {
        // ...
        val androidMain by getting {
            dependencies {
                implementation("com.google.android.material:material:1.2.1")
                implementation("com.google.firebase:firebase-storage-ktx:19.2.1")
                implementation("com.google.firebase:firebase-config-ktx:20.0.4")
                implementation("io.ktor:ktor-client-serialization:1.5.2")
            }
        }
        // ...
    }
    // ...
}

kotlin {

// ...

android() {

publishLibraryVariants("release")

}

// ...

sourceSets {

// ...

val androidMain by getting {

dependencies {

implementation("com.google.android.material:material:1.2.1")

implementation("com.google.firebase:firebase-storage-ktx:19.2.1")

implementation("com.google.firebase:firebase-config-ktx:20.0.4")

implementation("io.ktor:ktor-client-serialization:1.5.2")

}

// ...

}

// ...

}

Pour iOS, référez-vous à la documentation officielle du plugin Cocoapods (anglais) et ajoutez ceci à votre fichier shared/build.gradle.kts :

val libName = "myLibrary"

kotlin {
    ios {
        binaries.framework(libName)
    }
    cocoapods {
        frameworkName = libName
        summary = "KMM Library"
        homepage = "https://host.com/path/to/repository/"
        podfile = project.file("../iosApp/Podfile")
        ios.deploymentTarget = "14.0"

        pod("FirebaseStorage")
        pod("FirebaseRemoteConfig")
    }
}

val libName = "myLibrary"

kotlin {

ios {

binaries.framework(libName)

}

cocoapods {

frameworkName = libName

summary = "KMM Library"

homepage = "https://host.com/path/to/repository/"

podfile = project.file("../iosApp/Podfile")

ios.deploymentTarget = "14.0"

pod("FirebaseStorage")

pod("FirebaseRemoteConfig")

}

Lors du gradle sync, un fichier .podspec sera généré dans le dossier iosApp. Il s’agit d’un fichier décrivant le contenu de votre librairie et donnant un ensemble d’instructions à Cocoapods afin de permettre la configuration du projet Xcode. Pour plus d’info sur le format du fichier .podspec vous pouvez vous consulter la documentation sur le site officiel (anglais).

Implémentation

Voici un exemple d’utilisation du mot clef expect que nous plaçons dans le dossier commonMain :

expect class FirebaseRepo(context: Any?) {
    // ...
    fun getDbFromStorage(
        url: String, 
        createdAt: String, 
        type: String, 
        dbName: String, 
        success: (String) -&gt; Unit, 
        failure: (MyError) -&gt; Unit
    )
    // ...
}

expect class FirebaseRepo(context: Any?) {

// ...

fun getDbFromStorage(

url: String,

createdAt: String,

type: String,

dbName: String,

success: (String) -> Unit,

failure: (MyError) -> Unit

)

// ...

}

La contrepartie en natif côté Android utilisant le mot clef actual :

actual class FirebaseRepo actual constructor(val context: Any?) {
    // ...
    actual fun getDbFromStorage(url: String, createdAt: String, type: String, dbName: String, success: (String) -&gt; Unit, failure: (MyError) -&gt; Unit) {
        val storage = Firebase.storage
        val storageRef = storage.reference
        val pathReference = storageRef.child(url)
        val path: String = (context as Context).getDatabasePath(dbName).absolutePath
        val localFile = File(path)
        localFile.createNewFile()
        storage.maxDownloadRetryTimeMillis = 30000
        pathReference.getFile(localFile).addOnSuccessListener {
            if (localFile.exists()) {
                updateIndexFolder(type, createdAt)
                success(localFile.absolutePath)
            } else {
                failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))
            }
        }.addOnFailureListener {
            failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))
        }
    }
    // ...
}

actual class FirebaseRepo actual constructor(val context: Any?) {

// ...

actual fun getDbFromStorage(url: String, createdAt: String, type: String, dbName: String, success: (String) -> Unit, failure: (MyError) -> Unit) {

val storage = Firebase.storage

val storageRef = storage.reference

val pathReference = storageRef.child(url)

val path: String = (context as Context).getDatabasePath(dbName).absolutePath

val localFile = File(path)

localFile.createNewFile()

storage.maxDownloadRetryTimeMillis = 30000

pathReference.getFile(localFile).addOnSuccessListener {

if (localFile.exists()) {

updateIndexFolder(type, createdAt)

success(localFile.absolutePath)

} else {

failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))

}

}.addOnFailureListener {

failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))

}

// ...

}

Et la contrepartie en natif côté iOS :

actual class FirebaseRepo actual constructor(val context: Any?) {
    // ...
    actual fun getDbFromStorage(url: String, createdAt: String, type: String, dbName: String, success: (String) -&gt; Unit, failure: (MyError) -&gt; Unit) {
        val storage = FIRStorage.storage()
        val storageRef = storage.reference()
        val pathReference = storageRef.child(url)

        val applicationSupportPath = NSFileManager.defaultManager.URLsForDirectory(
            NSApplicationSupportDirectory,
            NSUserDomainMask
        )[0] as NSURL

        storage.setMaxDownloadRetryTime(30000.0)
        val dbPath = applicationSupportPath.URLByAppendingPathComponent("databases", true)
            ?.URLByAppendingPathComponent(dbName, false)
        dbPath?.let {
            pathReference.writeToFile(it) { success: NSURL?, err: NSError? -&gt;
                if (err != null) {
                    failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))
                } else {
                    updateIndexFolder(type, createdAt)
                    success?.let { path -&gt;
                        success(path.relativeString)
                    }
                }
            }
        }
    }
    // ...
}

actual class FirebaseRepo actual constructor(val context: Any?) {

// ...

actual fun getDbFromStorage(url: String, createdAt: String, type: String, dbName: String, success: (String) -> Unit, failure: (MyError) -> Unit) {

val storage = FIRStorage.storage()

val storageRef = storage.reference()

val pathReference = storageRef.child(url)

val applicationSupportPath = NSFileManager.defaultManager.URLsForDirectory(

NSApplicationSupportDirectory,

NSUserDomainMask

)[0] as NSURL

storage.setMaxDownloadRetryTime(30000.0)

val dbPath = applicationSupportPath.URLByAppendingPathComponent("databases", true)

?.URLByAppendingPathComponent(dbName, false)

dbPath?.let {

pathReference.writeToFile(it) { success: NSURL?, err: NSError? ->

if (err != null) {

failure(MyError(type, MyDbError.DOWNLOAD_STORAGE_ERROR.value))

} else {

updateIndexFolder(type, createdAt)

success?.let { path ->

success(path.relativeString)

}

// ...

}

Comme vous le constaterez dans les portions de codes spécifiques à chaque plateforme, les implémentations utilisent des APIs propres à l’OS correspondant, comme le NSFileManager sur iOS.

L’exemple met en avant une implémentation spécifique car l’écriture sur le disque n’est pas possible autrement, l’avantage de KMM étant de mutualiser l’intelligence de votre application dans une brique commune, il convient d’étudier la part de développement spécifique à chaque plateforme avant de recourir à cette technologie. La portion de code spécifique dans le projet utilisé pour illustrer cet article ne représente que 5% du code de la librairie.

Publication de la librairie

Pour Android, la librairie est publiée au format .aar via un repo Artifactory privé.

gradle assemble
gradle artifactoryPublish

1 2	gradle assemble gradle artifactoryPublish

Pour iOS, la librairie est commit / tag / push au format binaire dans un repo dédié puis publiée dans un repo privé Cocoapods. Afin de garantir que le binaire sera compatible avec le simulateur et les appareils physiques il est nécessaire de compiler la librairie pour les deux jeux d’architectures de processeur (ARM et x86) puis de les fusionner au sein d’un « fat bin » via la commande lipo. Je vous recommande de suivre la documentation officielle sur la création d’un repo Cocoapods privé (anglais) si vous souhaitez plus d’information sur le sujet. Suivez cet article pour obtenir un « fat bin » ou XCFramework (anglais).