Création et publication de la bibliothèque multiplateforme Kotlin sur Bintray
Kotlin Multiplatform est une excellente technologie dans la période de maturation, ce qui signifie qu’il n’est pas toujours possible de trouver ce dont vous avez besoin pour votre projet et vous doit le fabriquer vous-même. Êtes-vous prêt pour un défi?
Dans cet article, je vais partager un guide étape par étape de création et de publication de la bibliothèque KMP pour JVM, Android et iOS cibles. La cible, si elle est simplement définie, n’est qu’un type de périphérique sur lequel vous souhaitez que votre bibliothèque fonctionne.
Codeforces WatchR est un Open source client mobile pour Codeforces plate-forme, où des milliers de programmeurs s’affrontent dans des défis algorithmiques hebdomadaires. Il y a les deux, iOS et Android applications, qui sont disponibles dans les magasins.
Récemment, nous avons migré les deux applications à Kotlin Multiplatform. Dans le processus, nous venons de copier / coller ReKotlin code source (ne prend pas en charge KMP pour le moment) au module commun KMP, qui était le solution a court terme.
Mais alors nous avions besoin ReKotlin dans un autre projet KMP, nous avons donc décidé de le publier en tant que bibliothèque KMP sur Bintray. Maintenant, il peut être inclus en tant que dépendance dans build.gradle
fichier. Autres développeurs pouvez aussi avantage de notre travail.
Tout le code source peut être trouvé dans l’officiel ReKamp (c’est ainsi que nous avons appelé la bibliothèque) repo sur GitHub. Comme vous pouvez le voir, toutes les classes sont situées sous src/commonMain
dossier, ce qui signifie ReKotlin était 99% prêt pour KMP.
Il n’y a pas de code dépendant de la plateforme et nos modifications sont limitées à quelques petits ajustements liés à la façon dont Kotlin / Native le compilateur transforme Kotlin dans Obj-C:
- Pour certaines raisons
===
n’a pas fonctionné comme prévu dans Kotlin / Native, même si les adresses imprimées étaient les mêmes. Les a changés en==
. - Toutes les classes doivent étendre les autres classes ou
Any
. Sinon, vous aurez foiré les génériques, qui sont limités même sans ce problème. - Toutes les méthodes, qui commencent par
new
ouinit
sont préfixés pardo
. ModifiénewState
àonNewState
pour rester cohérent entre les plates-formes.
La configuration de votre build se produit dans kotlin
bloquer où vous spécifiez votre ensembles source et cibles. jvm
correspond à n’importe quelle cible alimentée par JVM et vous donne accès à différentes API liées à Java. android
est un sous-ensemble de jvm
, mais vous permet d’accéder à des API spécifiques à Android.
C’est beaucoup plus compliqué pour ios
cible. Dans de nombreuses bibliothèques répertoriées dans https://github.com/AAkira/Kotlin-Multiplatform-Libraries J’ai vu un raccourci pour ios()
prédéfini de cibles, qui fonctionne bien jusqu’à ce que vous essayez d’archiver l’application iOS, qui utilise la bibliothèque, dans XCode.
Architectures
Si vous inspectez la valeur par défaut Valid Architectures
champ dans votre Projet XCode, vous verrez qu’il contient à la fois arm32
(armv7, armv7s) et arm64
(arm64, arm64e) architectures.
Mais pour une raison quelconque, le raccourci pour ios()
dans KMP contient seulement x64
(simulateur) et arm64
(dispositifs) architectures. Et lorsque vous essayez d’archiver le projet, vous verrez erreurs suivantes:
Une des solutions est se débarrasser de arm32
architectures à la fois dans votre module KMP commun et Projet XCode, mais je ne suis pas sûr des implications de ce choix. Commentez si c’est sûr, s’il vous plaît.
Nous en avons choisi un autre, plus solution robuste et a décidé de soutenir iosArm32
dans ReKamp. Cela peut être fait en incluant explicitement iosArm32
, iosArm64
et iosX64
cibles dans le build.gradle
. Assurez-vous simplement que leurs ensembles de sources correspondants dépendent de nativeMain
.
Métadonnées
Quand tu fais ./gradlew build
, des sorties pour chaque cible sont créées. Ceux-ci sont jar
fichiers pour les cibles JVM et klib
pour les autochtones. Jusqu’ici tout va bien.
Le problème est qu’il n’y a pas de cible pour common
ensemble source, donc aucune sortie n’est générée. Mais Android Studio a besoin jar
fichier, qui est nommé your-library.jar
soutenir mise en évidence dans votre module KMP commun.
La solution est simple, vous devez renommer your-library-metadata.jar
(et autres sorties de métadonnées) à your-library.jar
. Voici le code, qui fait exactement cela + s’assure que les autres sorties sont nommées correctement.
Nous avons utilisé com.jfrog.bintray
plugin, qui fournit des méthodes pratiques pour télécharger vos sorties et métadonnées vers Bintray dépôt. Pour nous assurer que toutes les sorties sont correctement téléchargées, nous les avons ajoutées à publications:
publish.gradle
fournit le plus important information au plugin de publication: URL du référentiel, groupe, artefact et version.
pom.gradle
est juste un autre script Gradle, qui est utilisé pour fournir Additionnel information sur la licence de la bibliothèque, le développeur, etc. au format POM.
Toutes les valeurs que vous voyez dans les fichiers Gradle sont rassemblées dans gradle.properties
:
2 autres valeurs se trouvent dans local.properties
, qui sont privé: bintrayUser
et bintrayApiKey
, que vous pouvez obtenir en vous inscrivant sur https://bintray.com/ pour gratuit.
À ce moment, vous devriez pouvoir publier votre bibliothèque avec ./gradlew bintrayUpload
. Vous devriez voir environ 20 lignes de Uploaded to ...
Tout d’abord, vérifiez que vous avez toutes les sorties ont été téléchargées avec succès à Bintray: Référentiel -> Package -> Fichiers. Vous devriez voir quelques dossiers (communs, mavenProject + un par cible).
Vous pouvez maintenant inclure ces dépendances pour les cibles dont vous avez besoin comme ceci:
Cache Gradle
La moitié du temps que j’ai passé se battre avec le cache Gradle, ce qui était super persistant à garder anciennes versions de ma bibliothèque après des changements sans changer de version.
Voici quelques conseils pour surmonter le mécanisme de mise en cache:
- mise à jour version de votre bibliothèque après chaque changement
- retirer tout obsolète versions de la bibliothèque du cache Gradle local (vue Projet -> Bibliothèques externes -> votre-bibliothèque.jar (et toutes les cibles).
- une fois fait retirer tout obsolète versions de bibliothèque de Bintray
La création et la publication de la bibliothèque Kotlin Multiplatform étaient super difficile pour la première fois. Il m’a fallu presque 2 semaines pour tout arranger en plusieurs tours et quelques projets cassés.
J’espère que ce genre de guide étape par étape avec des exemples pratiques aidera d’autres développeurs à publier leur bibliothèque et à travailler beaucoup plus rapidement.
Bonne chance!