En 1979, l’auteur Australien Peter Allen chantait Everything Old Is New Again, une affirmation que dans le monde du logiciel (mais pas que) nous connaissons très bien.
En effet, rarement comme en 2019 avons-nous entendu parler d’interfaces déclaratives, surtout dans le domaine du développement mobile. Le concept remonte pourtant aux années ‘60 et plus précisément à 1969, quand Charles Goldfarb, Edward Mosher and Raymond Lorie définirent pour IBM le format GML (acronyme composé de leurs noms de famille) dont le but était d’étiqueter les contenus d’un texte, en termes de titres, paragraphes ou tableaux.
Vingt années plus tard, Tim-Berners Lee crée le HTML, entièrement basé sur SGML, un dérivé du GML conçu par Goldfarb, qui était devenu à l’époque le standard d’échange des publications scientifiques européennes.
Le principe fondamental des langages de markup, déjà depuis GML, est de séparer le Quoi du Comment, pour permettre aux créateurs des documents de se concentrer sur les contenus en faisant abstraction des détails d’implémentation nécessaires à les mettre en forme.
Aujourd’hui les interfaces déclaratives représentent bien évidemment une réalité dans le monde du Web et malgré certaines années de mauvaise presse, constituent la façon la plus répandue et compréhensible pour structurer du contenu numérique.
L’affirmation de JSX et de React Native, ces dernières années, a redonné une nouvelle lymphe au paradigme, à tel point qu’il semble être devenu un incontournable de la stack technique du développeur moderne d’interface.
Une problématique d’Expérience Développeur
Le processus d’implémentation d’interfaces utilisateur est souvent fastidieux : écrire la structure du contenu, son style, afficher l’aperçu, constater le moindre défaut, itérer. Again, and again, and again.
Pour les applications mobile ce cycle de développement est d’autant plus fastidieux car le développeur est souvent (voire toujours) obligé de recompiler le code et attendre parfois des minutes entières avant de voir le résultat des modifications.
Les solutions, bien entendu, existent et React/Native en est très probablement le meilleur exemple. Le cycle de développement est grandement accéléré en vertu du rafraichissement automatique lors de l’enregistrement et le débogage peut se faire à l’aide des Developer Tools des navigateurs Web. Cependant, l’adoption du framework, créé par Facebook, mais finalement maintenu par d’autres sociétés, est toujours matière à débat car il s’agit d’une dépendance majeure de source tierce et dont la compatibilité avec les plates-formes n’est pas assurée sur le moyen terme.
Interfaces déclaratives et flux de données
Bien que la possibilité de décrire une interface présente déjà de nombreux avantages, ceci n’est pas toujours suffisant pour réaliser une application simple à développer et à maintenir dans le temps.
En effet, comme dit plus haut, le format de représentation des interfaces, tant sur iOS que sur Android est, à l’heure actuelle, et depuis 10 ans déjà, basé sur XML.
Qu’est-ce qu’il manque, donc ? La réponse est dans le mot incontournable que nous n’avons pas encore écrit dans cet article : « donnée ». En effet, le développeur front et mobile doit se confronter au quotidien avec deux défis principaux : comment présenter la donnée de façon efficace à écrire et à maintenir et comment mettre à jour les interfaces de façon immédiate et performante, sans bloquer les actions de l’utilisateur (et le fameux « main thread », dont l’interruption est synonyme de mauvaise expérience utilisateur et, aussi, de terminaison abrupte de l’application).
Encore une fois, les solutions ne manquent pas. Programmation Réactive (d’où les fameuses bibliothèques Rx, Reactive Extensions) et Bindings (pour lesquels on ne remerciera jamais assez Microsoft) ont été conçus spécifiquement pour répondre à ces problématiques, notamment dans le cadre du développement des logiciels GUI Windows.
À vrai dire, les outils de Programmation Réactive, responsables de la prise en charge, manipulation et combinaison de flux de données asynchrones, sont déjà exploitables sur iOS et Android, mais à l’aide de bibliothèques tierces, je nomme RxSwift et RxJava. Ces bibliothèques apportent également des implémentations de Bindings spécifiques aux plates-formes cible : c’est le cas par exemple de RxCocoa, sous projet de RxSwift, dans le monde iOS.
Les avis sur ces frameworks restent par contre très polarisés : si chez Xebia / P.S. la plupart d’entre nous les considèrent comme des incontournables de tout projet mobile, d’autres développeurs préfèrent écarter ces solutions. Ce dernier choix se justifie généralement par une courbe d’apprentissage souvent ardue et le manque de support officiel de la part des langages et SDK natifs.
Pour résumer, bien que les interfaces mobiles actuelles se basent déjà sur une représentation déclarative (XML), les solutions tierces pour affichage de la donnée et interaction (notamment Rx) ne font pas l’unanimité dans le domaine.
2019 : une année révolutionnaire pour les UI déclaratives
Ce n’est pas donc pas par hasard que, dans l’espace de quelques mois, les plates-formes mobiles de Apple et Google ont assisté à l’introduction (ou à la réintroduction, dans le cas de Flutter) de nouveaux framework officiels de programmation d’interfaces en style déclaratif.
Si vous êtes un développeur Android, lors du mois de mai, vous n’aurez probablement pas arrêté d’en entendre parler un seul instant : le nouveau framework de la suite Jetpack, Compose. Compose permet de décrire rapidement une interface utilisateur (ironiquement, sans XML) tout en bénéficiant des bindings et de la gestion de l’asynchronisme déjà présents dans la toolchain made in Mountain View.
Les développeurs iOS n’avaient pas encore arrêté de manifester leur jalousie que, un mois après, c’était le tour d’Apple d’annoncer la nouvelle syntaxe déclarative pour construire les prochaines applications {i,tv,iPad,watch,mac}OS : SwiftUI. Basée sur Swift (ah bon ?), et en cours de développement depuis 3 ans, ce framework utilise la future fonctionnalité de DSL de Swift 5.1 pour implémenter les interfaces sans passer par le vétuste Interface Builder et ses storyboards (écrits en XML, double ironie). Tout comme pour Compose, SwiftUI s’appuie sur un moteur de binding et d’asynchronisme créé pour l’occasion.
Dans la suite de cet article, nous allons entrer davantage dans le détail de ces frameworks afin de vous donner une vision d’ensemble de leurs fonctionnalités.
SwiftUI
Une conséquence immédiate du lancement de Swift en 2014 est le sentiment d’inadéquation du SDK UI d’iOS, UIKit, développé en C++ et Objective-C pour iPhone OS 1 en 2007 et ouvert aux développeurs en 2008, suite à la perte d’intérêt de la part d’Apple pour les Web Apps (les PWA de l’époque).
Malgré l’expressivité de UIKit et ses performances, l’expérience développeur n’est depuis longtemps plus au rendez-vous : l’outillage, conçu pour l’écran (minuscule, aux yeux des développeurs d’aujourd’hui) de l’iPhone de 2007, a du mal à faire face aux interfaces complexes d’une application moderne et prend difficilement en charge les besoins d’adaptivité des applications, qui doivent maintenant tourner sur 8 tailles d’écran différentes, de l’iPhone 5 à l’iPad 13 pouces, sans oublier le support récemment annoncé de macOS.
L’annonce, lors de la WWDC de la semaine dernière, du nouveau framework SwiftUI est donc presque vu comme un soulagement de la part de la communauté iOS, qui demandait à grande voix un outillage capable de profiter pleinement du potentiel du langage Swift.
SwiftUI se base sur le support des DSL introduit par Swift 5.1 et permet la description d’interfaces en utilisant uniquement le langage Apple. Écrit en C++ et Swift, SwiftUI prend le pari de considérer les objets View comme des Value Objects (des structs en Swift), interdisant donc toute possibilité de sous-classement dont on avait parfois tendance à abuser avec UIKit. Ceci signifie donc que les vues seront passées par copie et pourront être serialisées/deserialisées : les avantages sont multiples et vont de l’absence de side-effects entre deux instances de vue, la simplification de la gestion de la mémoire (il sera beaucoup plus difficile de « leak » une vue) et la possibilité même de créer une vue à la volée à partir d’un autre format de représentation, comme par exemple JSON, en ouvrant les portes à des solutions de Server-Driven Rendering.
Afin d’accélérer le flux de développement, à chaque enregistrement du fichier implémentant la UI, Xcode opère une compilation instantanée du code source et une exécution d’une micro application permettant de visualiser le résultat. Comme pour React/Native, donc, l’aperçu ne sera pas une approximation de l’IHM finale, mais sera interactif et correspondra exactement à l’écran qui sera déployé dans l’application finale. Le hot reload est d’ailleurs garanti par un rechargement dynamique du binaire contenant l’interface compilée.
Quant à la donnée, SwiftUI introduit finalement des annotations utilisables dans un contexte de Binding : @State et @BindableObject. Ces éléments sont conçus dans l’optique d’activer une mise à jour réactive de l’interface qui sera donc synchronisée aux mises à jour de la donnée.
Et, toujours au sujet de la donnée, un autre framework inattendu a été annoncé par Cupertino : Combine, une implémentation simplifiée, mais tout de même assez complète, des Réactive Extensions qui deviennent donc first-party sur les plates-formes Apple et donc finalement partie intégrante du bagage de compétences des développeurs. Combine est censé s’adapter parfaitement aux besoins de mise à jour réactive de la donnée encouragée par SwiftUI.
Jetpack Compose
Le UI Kit d’Android a été conçu il y a un peu plus de 10 ans et il commence définitivement à être un peu rouillé par rapport à l’état de la technique. Google décide de s’inspirer de bibliothèques telles que React.js, Vue.js, Litho de Facebook et même de leur propre Flutter, et d’investir dans l’approche déclarative de l’interface utilisateur. Jetpack Compose a été annoncé pendant le Google I/O en mai dans le cadre des composants Jetpack, qui aident les développeurs à écrire des applications de haute qualité plus facilement.
Jetpack Compose est dissocié du SDK Android, réactif et entièrement écrit en Kotlin. Il a deux composantes principales :
- Compose UI Library, qui contient la boîte à outils principale de l’interface utilisateur avec le layout, l’input, le texte, les animations, les styles, les widgets et les graphiques.
- Compose Compiler, un plugin de compilateur Kotlin personnalisé qui prend des fonctions composables et met à jour automatiquement la hiérarchie de l’interface utilisateur.
L’idée principale de Compose est de considérer l’interface utilisateur comme une fonction. La fonction prend les données en entrée et émet la hiérarchie de l’interface utilisateur lorsqu’elle est appelée. Afin de déclencher l’événement sur les actions, nous pouvons transmettre les lambdas afin qu’elles soient invoquées en cas de besoin. Grâce aux blocs de construction composables, nous sommes en mesure de décomposer une interface complexe en fonctions composables. Un exemple très simple serait un message TextView affichant un message d’accueil. Le code réel ressemble à ceci (source https://developer.android.com/jetpack/compose) :
Il est important de comprendre comment les données circulent dans l’application et de clarifier la propriété de l’état afin de construire l’interface utilisateur de manière déclarative. Lorsqu’il existe plusieurs sources de données entrantes, par exemple pour les widgets d’interaction utilisateur, nous devons nous assurer de gérer correctement le flux de données, par exemple en choisissant le repository comme source unique de vérité.
Au moment de la rédaction de cet article, Compose est encore expérimental et n’est pas prêt pour la production. Pour le tester, il faudra juste téléchager la dernière version d’Android Studio en Canary. Vous pouvez regarder cette session du Google I/O – Declarative UI Patterns pour en savoir plus.
Conclusion
Dans cet article nous espérons vous avoir fourni une vision d’ensemble de la tendance la plus importante dans le domaine du développement mobile.
Cela dit, malgré notre enthousiasme, il faudra également retenir que les frameworks dont nous parlons ici viennent tout juste de sortir : entre défauts de jeunesse et évolutions, il sera difficile de les voir utilisés à l’intérieur d’applications à très grand public avant 2020.
La direction, en tout cas, est tracée et sera de nature à changer entièrement le flux de travail et les compétences requises à un développeur mobile pour les années à venir.