Deuxième journée de conférence, avec deux sessions orientées développement Android/iOS.« Coin Mining » par Jedrzej Nowacki
Présentation du système d’intégration continue Coin. Avec 250 développeurs actifs, il est impératif d’avoir un système d’intégration continu en place, afin de s’assurer de la qualité du code. Jedrzej Nowacki a fait un rapide historique, en remontant jusqu’à l’époque Trolltech :
- « whip approach » ou « politique du fouet ». Une personne est responsable des tests et s’assure que ces derniers s’exécutent correctement. Lorsqu’un test ne passe plus, cette personne notifie le développeur responsable ;
- avoir deux branches, une de développement et une autre stable. En pratique, cela ne fonctionne qu’un temps, car on se retrouve vite à avoir une branche à jour et une autre jamais maintenue ;
- introduction de Gerrit et de Jenkins, le plus gros changement dans l’histoire de l’assurance qualité de Qt. Grâce à ces deux logiciels, le code qui est intégré compile et les tests passent toujours ;
- puis développement de COIN, développé en interne chez The Qt Company, toujours en se basant sur Jenkins.
D’un point de vue technique, Coin repose actuellement sur vSphere, Git et Jenkins, mais pourrait être portée sur CloudStack ou une autre solution similaire. Il est même probable de passer sur une autre technologie de virtualisation, car vSphere ne satisfait pas pleinement ses développeurs.
À court et moyen terme, différents développements sont prévus :
- nouveau système de virtualisation, abandon à plus ou moins long terme de vSphere ;
- possiblement rendre disponible Coin sous une licence open source. Coin a été conçu dès le départ comme un projet générique, pas uniquement pour Qt. Même s’il y a des dépendances comme fortes comme Git, le projet ne dépend ni de Jenkins ni de vSphere. Des contributions dans ce sens pourraient être acceptées ;
- « CI command bot », une interface en ligne de commande, pour tester des configurations spécifiques ou un système d’exploitation en particulier avant que le code ne soit proposé sur Gerrit ;
- support de différents appareils, dans le but de faire tourner les tests sur des appareils physiques ;
- exécution distribuée des tests, faire tourner la moitié des tests sur une machine et le reste sur une autre, afin de paralléliser et de gagner un temps précieux ;
« Qt Build systems » par Kai Köhne
Présentation sous forme de BoF (ou encore « unconference »), discussions entre différents utilisateurs et développeurs de Qt. Pour le moment, trois systèmes de compilations cohabitent lorsque l’on parle de Qt : QMake, CMake et Qbs.
Le premier, QMake, est de l’avis de beaucoup un mort-vivant : il survit. Il reste le système de compilation par défaut lors de la création d’un nouveau projet Qt et est lui-même utilisé pour compiler Qt ainsi que Qt Creator. Cependant, il ne faut pas s’attendre à de gros développements.
CMake est un système de compilation générique, maintenu par la communauté et par l’entreprise Kitware. Il est très utilisé dans le monde C++, par le projet KDE ou Blender par exemple. Il est relativement facile d’utiliser CMake pour compiler un projet reposant sur Qt. Par ailleurs, de nombreuses bibliothèques annexes sont supportées.
Enfin, Qbs (prononcez « Cubes »), qui n’est plus l’acronyme de Qt Build System, développé par The Qt Company. Contrairement aux deux précédents, Qbs n’est pas un générateur de Makefile. Pour l’instant, seul Qt Creator peut être compilé avec Qbs, il reste encore du travail pour pouvoir compiler Qt avec ce dernier.
Étant donné que QMake est un mort-vivant, la question était de savoir lequel des deux autres serait le meilleur remplaçant. Les développeurs étaient d’avis divergents quant à l’impact du système de compilation utilisé par Qt lui-même sur celui qui serait utilisé pour des applications utilisant Qt. Il serait en effet difficile d’utiliser CMake en interne, tout en faisant la promotion de Qbs et inversement. Aucune décision ne fut prise.
Quoi qu’il en soit, quasiment tous les développeurs présents dans la salle utilisaient CMake pour leurs projets, la seule solution présentée comme « réaliste » pour un projet C++ à l’heure actuelle. Le système de compilation sur lequel repose Qt influence les utilisateurs de Qt.
« Continuous tests and distribution for Qt applications on desktop and mobile » par Nicolas Froment
Session en forme de retour d’expérience de la part d’un des développeurs principaux de MuseScore, un éditeur de partition, disponible pour Linux, macOS, Windows, iOS et Android. Il y a deux bases de code, une pour le bureau, une pour le mobile. Le code pour le bureau est libre, tandis que le code pour l’application mobile est propriétaire. Les deux plates-formes ont des attentes différentes quant aux fonctionnalités.
Après un bref passage en revue des différentes solutions existantes, Travis CI fut retenu. Il existe une offre gratuite pour les projets open source et l’intégration avec Github est totalement opérationnelle : il suffit d’avoir un fichier travis.yml à la racine du dépôt Git.
Il est possible de publier automatiquement les binaires testés sur différents supports : Google Play, Apple Store, S3. Extrêmement pratique, car faire télécharger un fichier APK aux testeurs est peu pratique. Pour Windows, on peut par exemple mettre en ligne un installeur et pour macOS une archive DMG. Plus le logiciel est facile à tester, plus il y aura de testeurs, donc meilleure sera la qualité du projet et du code.
Cependant, Travis impose différentes limites, notamment au niveau du temps alloué pour compiler et tester son projet :
C’est pour cela qu’il est important de réduire le temps nécessaire à la compilation, ce qui peut se faire grâce à différents outils et pratiques selon le projet.
Il ne faut stocker ni mot de passe ni clefs de licence directement dans le dépôt Git. Au contraire, il faut utiliser les fonctions de Travis pour ce faire, comme « Encryption Key », comme décrit dans la documentation.
Par ailleurs, il est fortement conseillé de confier la gestion et l’installation des dépendances au gestionnaire de paquet. Mais il arrive que les dépendances nécessaires ne soient pas encore disponibles, car les machines virtuelles proposées peuvent dater. Dans ce cas, il faudra télécharger l’installateur sur le site dudit projet et exécuter l’installateur depuis un script shell.
Même si cela paraît simple, il est en fait complexe d’utiliser l’installateur de Qt si l’on ne possède pas d’interface graphique. Il s’avère néanmoins qu’une personne de la communauté a développé un script permettant de réaliser cette tâche.
« Going all-in with Qt on mobile », par Kai Uwe Broulik
Tout est parti d’un client possédant une application Android dont le code était trop obscur pour pouvoir être maintenue. Lors du redéveloppement de cette application, une version iOS était aussi souhaitée.
Le client demandait différentes fonctionnalités non intégrées pour le moment, comme :
- deep link, un lien internet qui ouvre un contenu précis dans l’application ;
- les fonctions de partage via Facebook.
La plupart de ces fonctions ne sont pas directement mises à disposition par Qt, mais sont facilement utilisables. Ainsi, une surcouche QML a été développée par-dessus le SDK Facebook en moins de 150 lignes. Elle peut alors être réutilisée dans d’autres applications pour Android reposant sur Qt.
Le développement d’une telle application avec Qt est totalement faisable et l’application fut même propulsée dans le carrousel du Google Play (http://www.menshealth-personaltrainer.com/de/). Ce qui nécessite une notation supérieure à 4 et une apparence irréprochable.
Ce look-and-feel natif n’a cependant pu être atteint que par de nombreux bricolages et ajustements de la part de l’équipe de développement. Par défaut, le framework ne porte pas forcement attention aux détails. Par exemple, les polices de caractères, le bruit lors du clic, vitesse d’animation des composants.
Présentation très encourageante pour l’avenir quand on voit ce qu’il était possible de faire avec Qt il y a quelques années.
Envoyé par air-dex
