Développement multi-plateforme avec Kotlin – Julius Canute

Conditions préalables

• Je suppose que vous connaissez le développement Android et iOS.
• Je suppose que vous avez une exposition suffisante à Kotlin & Swift pour comprendre le DSL.

Au cours d’un cycle de développement d’applications rapide, nous rencontrerons des problèmes. Nous allons les parcourir brièvement et définir un objectif que nous voulions atteindre.

1.1 Problème

Dans cette section, nous allons parcourir quatre scénarios qui peuvent créer des goulots d’étranglement.

1.2 Objectif

Après avoir traversé les préoccupations mentionnées ci-dessus, définissons notre objectif, comme indiqué ci-dessous:

«Étant donné que l’App possède le code nécessaire. nous voulions changer le comportement de l’application une fois déployée sur l’appareil avec un minimum d’effort. »

Compte tenu de notre objectif, nous voulions la flexibilité de modifier la configuration de notre application une fois déployée. Pour cela, nous allons placer un Point d’entrée de configuration(CEP) dans le lanceur de notre application, qui nous permet de mettre à jour la configuration avant le chargement de l’application principale. Pour illustrer cela avec un exemple, le diagramme ci-dessous montre le lanceur ayant deux points d’entrée pour notre application, celui montré en vert est le Point d’entrée principal(MEP) à notre application. En revanche, celui montré en jaune nous permet de personnaliser les paramètres avant de lancer le MEP.

2.1 DSL – Couche 1

Pour avoir une manière cohérente d’écrire la configuration sur les plates-formes iOS et Android, nous allons développer les DSL à l’aide de Kotlin Lambda Extension. Dans la mise en œuvre de ces DSL, les attributs suivants sont partagés.

• la description – fournit une option pour décrire l’intention de la configuration.

• article – options disponibles dans cette configuration.

• max – valeur maximale autorisée dans cette configuration
• valeur actuelle – la valeur actuelle de cette configuration

2.2 Persistance – couche deux

Une fois le changement de configuration appliqué, les démarrages ultérieurs de l’application principale doivent avoir la nouvelle configuration. Pour ce faire, la couche de persistance a deux responsabilités, l’une consiste à charger une configuration existante, l’autre à enregistrer une configuration modifiée. Pour ces responsabilités, nous avons une implémentation Android et iOS écrite à l’aide de Kotlin dans la couche deux.

• iOS utilise NSUserDefaults

2.3 UI – Couche trois

Lorsque nous lançons l’application via le CEP, nous transformons la configuration écrite en DSL en contrôles d’interface utilisateur correspondant à la plate-forme. Nous avons couvert cette logique en utilisant l’implémentation native d’Android et iOS écrite en Kotlin et Swift.

Après avoir développé les trois couches de notre bibliothèque, considérons que nous avons publié les bibliothèques Android et iOS sur Maven Central et CocoaPods. Dans la section suivante, nous utiliserons les bibliothèques publiées sur notre exemple de projet.

Pour utiliser ces bibliothèques en mode natif sur la plate-forme cible, suivez le processus d’installation ci-dessous:

L’exemple de projet a deux configurations différentes pour Gratuit et Prime utilisateurs et contient une vue avec un texte dont nous aimerions configurer les attributs avant le lancement. Les attributs qui nous intéressent sont listés ci-dessous:

• Taille du texte
• Texte actuel
• Couleur du texte

Nous pouvons initialiser notre module de configuration lors du démarrage de l’application comme suit.

3.4 Utilisation des valeurs de configuration actuelles

Après avoir initialisé notre bibliothèque, nous pouvons obtenir les valeurs de configuration mises à jour à tout moment dans notre application, comme indiqué ci-dessous. Nous pouvons utiliser les clés définies dans notre configuration DSL pour acquérir la valeur correspondant à la configuration.

Montre que notre application a deux points d’entrée le MEP et le CEP. Dans Android, y compris la bibliothèque, cela se produit automatiquement à la suite de la fusion du manifeste. Dans iOS, nous créons deux cibles et associons les cibles au même groupe d’applications, de sorte que la mise à jour des paramètres dans une cible se reflète dans l’autre.

Nous avons un œuf de Pâques caché dans la couche un du code commun qui peut être utile au moment de l’envoi de l’application où nous n’avons pas besoin de la couche deux (persistance) et de la couche trois (interface utilisateur). Il s’agit d’une configuration en lecture seule utile après avoir finalisé les valeurs de configuration.

5.1 Android

L’utilisation de cet œuf de Pâques dans Android est un processus en deux étapes.

5.2 Bibliothèque d’initialisation iOS

Vous constaterez que le nom du groupe et le contrôleur de démarrage sont manquants dans l’initialisation.

5.3 Sortie

La figure ci-dessous montre l’application commence à utiliser le DSL sans couche de persistance et couche d’interface utilisateur de la bibliothèque.

Bien que nous ayons nos différences, nous sommes les mêmes au cœur.

1. https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html
2. https://eladnava.com/publish-a-universal-binary-ios-framework-in-swift-using-cocoapods/
3. https://github.com/bintray/gradle-bintray-plugin
4. https://developer.apple.com/xcode/swiftui/
5. https://developer.android.com/jetpack/compose
6. https://kotlinlang.org/docs/reference/platform-specific-declarations.html
7. https://kotlinlang.org/docs/tutorials/native/apple-framework.html
8. https://kotlinlang.org/docs/reference/type-safe-builders.html
9. https://developer.android.com/training/data-storage/shared-preferences
10. https://developer.apple.com/documentation/foundation/nsuserdefaults
11. https://github.com/russhwolf/multiplatform-settings
12. https://github.com/Kotlin/kotlinx.serialization