All posts in Android

KMM : découverte de Kotlin Multiplateform Mobile

Définition

Kotlin Multiplateform Mobile, plus communément appelé KMM, est une technologie open source créée par JetBrains. Stable et en production depuis novembre 2023, elle permet de simplifier le développement multiplateforme, notamment pour Android et iOS.
Le principal langage de programmation de KMM est, comme son nom l’indique, Kotlin. Développé en 2011 par JetBrains, ce langage, moins verbeux que Java, permet une écriture de code plus rapide et concise, offrant une accélération conséquente du rythme de développement. Kotlin propose également des améliorations, notamment avec l’introduction de la null-safety, afin d’éviter les NullPointerException en déclarant des variables pouvant être nulles, assurant ainsi un code plus limpide et robuste. Depuis 2017, il est devenu le langage officiel du développement mobile Android.

Fonctionnement

KMM permet d’intégrer le code métier de l’application de manière partagée entre Android et iOS, réduisant drastiquement le temps de développement et évitant la redondance. Il est utilisé pour écrire les différents modèles de l’application, les appels réseau et aux bases de données. Pour une architecture MVVM, certaines librairies offrent la possibilité de partager également les ViewModels sur les deux supports. Seule la partie visuelle doit être écrite nativement, en XML ou Jetpack Compose pour Android, et en SwiftUI ou UIKit pour iOS, assurant ainsi des performances et une expérience utilisateur optimales.

Exemple

Prenons l’exemple de base d’un projet KMM tout nouvellement créé :

Arborescence KMM (Kotlin Multiplateform Mobile) composeApp : contient le code source de l’application Android en Compose, non partagé.
iosApp : contient le code source de l’application iOS en Swift/SwiftUI, non partagé
shared : contient le code partagé entre les 2 plateformes séparé en 3 dossiers

 

Dans le dossier shared, nous pouvons remarquer la présence des classes et des fichiers Kotlin. Le fichier Platform.kt quant à lui, dans commonMain, contient une interface qui retourne le nom de la plateforme associée au téléphone ainsi qu’une fonction expect. Déclarer une fonction expect permet d’implémenter du code spécifique natif à la plateforme, et c’est pour cela que dans androidMain et dans iosMain, nous retrouvons l’utilisation de cette interface afin de récupérer nativement le nom et le numéro de version de la plateforme. Dans la classe Greeting, nous pouvons appeler une fonction qui nous retournera le nom de la plateforme associée à la fois en Compose sur Android et en SwiftUI sur iOS.

Code KMM (Kotlin Multiplateform Mobile)

Code KMM (Kotlin Multiplateform Mobile)

Conclusion

À l’instar des autres technologies de développement hybride, comme React Native ou Flutter, Kotlin Multiplateform Mobile permet de conserver l’aspect natif de l’application. Il permet en effet d’utiliser les composants et l’expérience des écosystèmes Android et iOS tout en partageant du code métier, alliant à la fois performance de l’application et rapidité de développement. Pour ma part, je trouve que KMM est une véritable innovation dans la création d’applications mobiles natives, permettant d’éviter la redondance d’écriture de code métier lors de la création d’une application Android et iOS. KMM prend dors et déjà de plus en plus d’ampleur au sein des stacks de développement mobile, qu’il s’agissent de nouvelles application ou de refonte.

A noter que les développeurs Android auront forcément plus d’attirance pour cette approche basée sur un langage et un écosystème Kotlin. Cela ouvre également un débat plus organisationnel au sein des équipes mobiles. En effet, il faudra savoir quels développeurs sont ou seront responsables du développement du code partagé.

Honeywell confie à DocDoku l’évolution de son socle mobile Android

« Une expertise évidente et une très bonne communication qui ont permis à ce projet d’être un succès » : c’est en quelques mots le retour d’Honeywell Safety and Productivity Solutions sur sa collaboration avec la Team DocDoku.

Spécialisée dans la performance des process, Honeywell Safety and Productivity Solutions construit et commercialise des solutions de capture des données (RFID, lecture de codes-barres…) et de management de l’information.

La société avait choisi DocDoku pour les accompagner dans l’évolution de leur SDK (Software development Kit) mobile sous Android.

Retrouvez la success story complète dans l’espace Nos Clients.

DevFest Toulouse 2017 : passion et innovation

Merci aux 450 participants du DevFest et bravo à nos équipes pour avoir suscité l’interêt de nos visiteurs lors de cette journée dédiée aux développeurs !

Une occasion pour l’écosystème toulousain de se retrouver et d’assister à des conférences de pointe sur l’évolution du métier de développeur, le développement mobile ou encore l’IoT.

Chez DocDoku, nous encourageons nos collaborateurs à prendre part à cette journée.
Plusieurs membres de nos équipes ont ainsi participé aux conférences : un réel atout pour renforcer leur veille technologique, réseauter et trouver de l’inspiration sur les méthodologies et outils de demain.

Rendez-vous l’année prochaine !

Android 4.4 KitKat

Alors que l’on attendait une version 5 d’Android, Google a surpris tout le monde en annonçant une version 4.4, qualifiée donc de « version mineure ». Mineure car elle apporte peu de changement « visible » pour le grand public et est donc plus difficile à « marketer ». Pourtant sous le capot, on constate un grand nombre d’évolutions importantes que je vais tenter de vous résumer dans cet article.

NFC : Host Card Emulation

Jusqu’à la version 4.3, le support NFC sur les téléphones Android est limité à une fonction de lecture de tags NFC. Ceci permet par exemple de déclencher des actions sur le téléphone en l’approchant d’un tag NFC.

Nous avons d’ailleurs réalisé plusieurs POC à ce sujet avec un grand groupe pharmaceutique français qui étudie actuellement la mise en place de tags NFC dans ses emballages.

Avec KitKat, il sera désormais possible d’émuler un tag NFC avec son téléphone. Cette nouvelle capacité va permettre de dématérialiser un grand nombre de cartes que nous possédons tous : carte de fidélité, carte de transport, et pourquoi pas à terme carte de paiement… Il suffira alors de rapprocher son téléphone NFC d’un lecteur, au lieu de fouiller dans son portefeuille.

Quand on voit le succès rencontré par Passbook qui permet de regrouper des cartes, des tickets, des bons de réduction avec une technologie de code barres ou qrcode, on peut imaginer ce que sera demain l’engouement du « sans-contact ».

Low-power Sensors

Android KitKat introduit un nouveau mode de gestion des capteurs du téléphone (accéléromètre, détecteur de positions, de pression, température etc..) : les événements peuvent désormais être traités par lots, on parle de « sensor batching ». En fonction des besoins, les applications peuvent être notifiées à un intervalle choisi avec un ensemble de données provenant des capteurs. Jusqu’à présent, chaque événement devait être traité par les applications d’une manière unitaire.

Cerise sur le gâteau, cette optimisation est faite au niveau hardware. Concrètement cela veut dire que les applications pourront continuer à « tracker » les événements des différents capteurs même lorsque le téléphone est éteint ou en veille, ce qui a pour effet de réduire drastiquement la consommation de batterie. (ex : une application de randonnée qui enregistre le trajet n’a plus besoin d’être active pendant la randonnée, il suffira de traiter à posteriori les données de position à la fin du parcours.)

Cette fonctionnalité, combinée à de nouvelles puces permettant de détecter les pas, vient se placer en concurrence directe des dispositifs embarqués (ex: les podomètres dans les chaussures.)

Évolution de la WebView

La WebView bénéficie enfin du même moteur que Chrome Android : Chromium ! Une bonne nouvelle qui devrait sans conteste améliorer les performances des applications dites « hybrides » qui embarquent une WebView pour gérer la partie vue.

Ce changement amène un meilleur support des standard HTML5, CSS3 et Javascript avec notamment le support attendu des websockets et des web workers.

Enfin, une nouveauté et non des moindres, est que l’on peut debugger une WebView directement dans Chrome sur le poste du développeur via les Chrome Developer Tools.

Un “vrai” plein écran : Immersive mode

Depuis KitKat les applications peuvent profiter du moindre pixel disponible avec un vrai mode plein écran. Il est désormais possible de cacher entièrement et de façon permanente la « status bar » et la « navigation bar ». Précédemment, cacher la navigation bar n’était possible que jusqu’à ce que l’utilisateur touche l’écran. (utilisé notamment dans les players video).

Dans ce nouveau mode, les applications peuvent capturer les événements de « touch » n’importe où sur l’écran, y compris sur les emplacements habituels des barres. Pour faire réapparaître les barres (qui sont en partie transparentes dans ce mode) par dessus le contenu, un nouveau geste a été introduit :  un swipe de haut en bas en partant de l’extérieur du téléphone.

Préparer l’avenir

Les ingénieurs Google prépare l’avenir en proposant une preview de ce que pourrait être la nouvelle machine virtuelle qui sera amenée à remplacer Dalvik : ART (Android Runtime)
Alors qu’aujourd’hui le bytecode des applications est transformé en instructions natives à chacune de leurs exécutions (via un compilateur Just-In-Time), avec ART il est pré-compilé une bonne fois pour toute à l’installation (on parle de compilation Ahed-Of-Time).

Au prix d’un temps d’installation plus long, et d’un poids des applications de 10 à 20% plus lourd, il est donc possible d’améliorer les performances à l’exécution tout en économisant de la batterie.

Il est d’ors et déjà possible d’activer ART dans les “Options pour les développeurs” et les retours sont dans l’ensemble assez prometteurs.

Google travaillerait en secret sur ce projet depuis plus de 2 ans, certains avancent même que les poursuites d’Oracle à propos de brevets portant sur la machine virtuelle Dalvik pourraient avoir menées à l’émergence de ce projet.

Un seul mot d’ordre : performance

Un gros travail d’optimisation a eu lieu pour réduire l’utilisation de la mémoire et permettre à des devices peu puissants (512MB de RAM) de faire tourner KitKat. De nouvelles APIs sont désormais disponibles pour détecter ce genre de device (ActivityManager.isLowRamDevice).

Les composants majeurs ont été réécris, le système est plus agressif envers les applications qui consomment le plus, les services sont lancés en petit groupe et en série si le besoin s’en fait sentir.

On peut donc espérer de la part des constructeurs de téléphone, ou à défaut de la communauté, un déploiement de KitKat sur un plus large panel de device que les versions précédentes.

Pour le développeur, cela veut dire qu’il est de plus en plus primordial de s’orienter vers une approche « responsive » des applications, non seulement au niveau de l’affichage (tablette vs téléphone) mais surtout aussi au niveau de leurs fonctionnements et de leurs possibilités.
Ceci afin de tendre vers le but suprême : proposer des applications responsives, fluides et adaptées quelque soit le matériel sur lequel elle sont déployées.