DevFest Niamey 2025 - Kotlin Multiplatform

Transcript

1. Niamey Kotlin Multiplatform SABIOU GODI Farouk Consultant, Developpeur Mobile
2. L’évolution vers le code unique
3. 🎯 Objectif ancien : une seule base de code pour iOS et Android. • Plusieurs frameworks ont tenté de relever le défi : ◦ PhoneGap : l’un des premiers (HTML5, CSS3, JavaScript). ▪ Arrêté en 2020. • Apache Cordova : fork open source de PhoneGap. • Ionic : basé sur Angular, React ou Vue. • Appcelerator Titanium : SDK en JavaScript pour iOS, Android, Windows, Blackberry. ◦ Abandonné en 2022, puis open-sourcé.
4. Limites des anciens frameworks • Ces frameworks utilisaient les technologies web pour afficher : des contrôles natifs, ou des imitations de contrôles natifs. • Problèmes rencontrés : ◦ Communication lente entre JavaScript et le code natif. ◦ Besoin de mises à jour fréquentes à chaque changement du système d’exploitation.
5. Les frameworks modernes • Xamarin (.NET, C#) ◦ Framework Microsoft basé sur le runtime .NET. ◦ Compilation native sur iOS → plus rapide qu’Android (JIT). ◦ Support arrêté le 1er mai 2024, remplacé par .NET MAUI. • React Native (Facebook) ◦ Basé sur React et JavaScript. ◦ Souffre également d’un pont lent entre le code natif et le web. • Flutter (Google) ◦ Fonctionne sur toutes les plateformes. ◦ Permet d’écrire presque toute l’interface utilisateur une seule fois. ◦ Écrit en Dart, un langage peu connu.
6. Flutter : un cas particulier
7. ✅ Avantages : • • UI réutilisable sur mobile, web et desktop. Rendu rapide grâce à son moteur graphique. ⚠ Inconvénients : • Certaines UI doivent rester spécifiques (ex. : pas de toolbar sur desktop/web). • Dart n’est pas encore très populaire. • null safety récente. • Plusieurs packages exigent une génération manuelle de code.
8. Kotlin
9. • Un langage moderne, concis et sûr. • Intègre la null safety pour éviter les erreurs de nul pointer. • Offre des fonctionnalités puissantes : ◦ Data Class et Sealed Class ◦ Fonctions d’extension. • Chargement paresseux (lazy loading) des variables. • Le langage par défaut pour le développement depuis 2019
10. Pourquoi utiliser Kotlin ? • Idéal pour les serveurs avec la librairie Ktor. • Intègre la null safety pour éviter les erreurs de nul pointer. • Offre des fonctionnalités puissantes : ◦ Data Class et Sealed Class ◦ Fonctions d’extension. • Chargement paresseux (lazy loading) des variables. • Le langage par défaut pour le développement depuis 2019
11. Kotlin sur plusieurs plateformes • Fonctionne sur les plateformes supportant la JVM (Android, Desktop Java…). • Pour les plateformes sans JVM : utilisation de Kotlin/Native. • Kotlin se compile pour : ◦ JVM, natif (iOS, desktop) et web. • Permet d’écrire une logique métier commune : ◦ Comportement identique sur toutes les plateformes. ◦ Moins de tests et de risques d’erreurs. ◦ Développement plus rapide. • Chaque équipe choisit quoi partager.
12. L’objectif de Kotlin Multiplatform • Ne remplace pas les SDK natifs. • Permet de partager la logique commune entre les plateformes : ◦ Modèles de données ◦ Contrôleurs ◦ Logique métier • Réduit la duplication de code tout en conservant : ◦ L’expérience utilisateur propre à chaque plateforme. ◦ Les intégrations natives (UI, API système).
13. Léger et performant • KMP ajoute peu de poids à l’application. • La bibliothèque standard est minimale, seules les parties utilisées sont incluses. • De nombreuses applications sur les stores utilisent déjà KMP. • Résultat : ◦ Gain de temps pour les équipes. ◦ UI native → expérience fluide et rapide pour l’utilisateur
14. Le cœur de l’approche KMP • Les équipes Android et iOS ont souvent : ◦ Les mêmes spécifications, mais deux codes différents. • Problème : divergences possibles dans le comportement. • Avec KMP : ◦ Une seule codebase pour la logique métier. ◦ Tests unifiés et cohérence totale entre plateformes. • Collaboration renforcée entre les équipes.
15. Utilisation progressive et flexible • KMP peut être intégré à petite ou grande échelle. • Pour une app existante : ◦ Utiliser KMP sur de nouvelles fonctionnalités. ◦ Remplacer progressivement la logique métier. • Exemples d’utilisation : ◦ SQLDelight pour gérer la base de données partagée. ◦ Logique d’accès réseau commune à toutes les plateformes.
16. Architecture typique et partage du code • Une app comprend généralement : ◦ Couche réseau ◦ Couche base de données ◦ Couche référentiel (repository) ◦ Logique métier ◦ UI
17. • KMP permet de partager ◦ Couche réseau ✅ ◦ Couche base de données ◦ Couche référentiel (repository) ◦ Logique métier ◦ UI (non fournie par KMP)
18. • KMP permet de partager ◦ Couche réseau ◦ Couche base de données ✅ ◦ Couche référentiel (repository) ◦ Logique métier ◦ UI (non fournie par KMP)
19. • KMP permet de partager ◦ Couche réseau ◦ Couche base de données ◦ Couche référentiel (repository) ✅ ◦ Logique métier ◦ UI (non fournie par KMP)
20. • KMP permet de partager ◦ Couche réseau ◦ Couche base de données ◦ Couche référentiel (repository) ◦ Logique métier ✅ ◦ UI (non fournie par KMP)
21. • KMP permet de partager ◦ Couche réseau ✅ ◦ Couche base de données ✅ ◦ Couche référentiel (repository) ✅ ◦ Logique métier ✅ ◦ UI (non fournie par KMP) ❌
22. • KMP permet de partager ◦ Couche réseau ✅ ◦ Couche base de données ✅ ◦ Couche référentiel (repository) ✅ ◦ Logique métier ✅ ◦ UI (non fournie par KMP) ❌
23. Architecture Android iOS Couche UI Jetpack Compose Couche UI SwiftUI Domain - GetTalksUseCase.kt getTalksByRoom(room: String): List<Talk> searchTalks(query: String): List<Talk> getTalksByLevel(level: NiveauTalk): List<Talk>
24. Architecture Android iOS Couche UI Jetpack Compose Couche UI SwiftUI Data - Talk.kt TalkLevel.kt (DEBUTANT, INTERMEDIAIRE, AVANCE) TalkRepository.kt Cache et synchronisation
25. KMP est-il natif ?
26. Oui, 100 % natif • Tous les rendus UI sont nativement dessinés. ◦ Android → View system ou Jetpack Compose. ◦ iOS → UIKit, SwiftUI ou Compose Multiplatform. ◦ Desktop → Java Swing, Compose Desktop, AppKit (Mac). • Compilation : ◦ Android → fichiers .class (Java). ◦ iOS → LLVM / framework Xcode.
27. Merci