Exemple d'amélioration dans Qt Creator 3.0 : vous recevrez maintenant une notification si le SDK n'est pas correctement configuré pour interagir avec Android.
Le premier problème était que, lors de la compilation pour Android, Qt Creator ajoutait des fichiers qu'il générait au répertoire des fichiers de source de votre projet. Certains de ces fichiers contiennent un mélange d'informations modifiables par l’utilisateur et d'informations générées. C'est fondamentalement mauvais d'ajouter des fichiers générés à la compilation dans le dossier de compilation. Typiquement, seulement les fichiers qui contiennent véritablement des modifications du projet devraient être vérifiés par le système de révision.
Un autre problème est que toute la logique de déploiement résidait au sein de Qt Creator. Il était de ce fait difficile d'utiliser ce dernier avec d'autres moteurs de production ; de même, il n'était pas facile d'automatiser la tâche.
Un troisième problème était l'interdépendance entre Qt et Qt Creator. Le modèle pour les fichiers générés était dans Qt, alors que l'instanciation du modèle se faisait dans Qt Creator. Avoir les modèles dans Qt est tout à fait logique, étant donné qu'ils doivent être synchronisés avec d'autres parties de Qt, tel le plug-in de plate-forme ou la bibliothèque d'assistance Java. Cependant, cela signifie qu'un changement dans Qt nécessitera un changement dans Qt Creator. De ce fait, les plannings des sorties et les dates butoir devaient être synchronisées, ce qui ajoutait de la tension au processus de sortie.
Du côté de l'utilisateur, cela réduit la fenêtre de tir quant à la date de mise à jour. Une nouvelle version de Qt pour Android nécessitera souvent une nouvelle version de Qt Creator. Ce n'est peut-être pas le plus gros souci mais cela constitue tout de même une bonne part des reports de bogues et des questions.
Pour régler ces problèmes dans Qt 5.2, l’empaquetage et la logique de déploiement sont séparées de Qt Creator et déplacées dans un outil en ligne de commande. Ce dernier peut être trouvé dans le dépôt
qttools et s'appelle
androiddeployqt. En plus, la logique a été mise à jour, ce qui permet maintenant de se passer d'un fichier de compilation Android dans votre projet. Avec Qt 5.2 et le nouvel outil de déploiement, vous devriez prendre n'importe quel
.pro et l'exécuter.
1 2 3
| qmake
make install INSTALL_ROOT=android-build/
androiddeployqt --output android-build/ |
Ces commandes produiront un fichier .apk que vous pourrez installer et exécuter sur votre appareil. Notez que cela nécessite, bien évidemment, que l'application soit écrite avec une approche multi plate-forme. Si l'application utilise des fichiers externes, vous devriez les ajouter à un fichier QRC, ou les placer dans le répertoire
android-build/assets du paquet.
Le répertoire
android-build/ est, dans cet exemple, un dossier de compilation propre, qui peut être recréé en répétant les étapes ci-dessus. Vous pouvez supprimer ce répertoire afin de détruire les anciens paquets et fichiers de compilation. Par défaut, il ne contiendra que les fichiers provenant du modèle d'application Qt, avec quelques changements afin de consigner les modifications au sein du fichier
.pro. Cela devrait être un bon point de départ pour n'importe quelle application étant donné que cela vous permet de vous concentrer sur le code multi plate-forme et de rapidement compiler et tester sur un véritable appareil. Avant de distribuer votre application, vous voudrez sûrement ajouter des fichiers spécifiques à votre projet. Pour ce faire, ajoutez un
AndroidManifest.xml pour les décrire ainsi qu'ajouter diverses informations requises par le
market sur lequel vous désirez publier votre application. Cela peut aussi être facilement fait avec l'outil de déploiement. Ajoutez un répertoire à votre projet où vous désirez placer le contenu spécifique à Android et ajoutez ensuite une référence à ce dossier dans votre fichier
.pro. Ce dossier sera alors fusionné avec le modèle, en écrasant les fichiers dupliqués. C'est ainsi que vous pouvez facilement adapter les paquets à vos besoins. Consultez la
documentation pour plus d'informations à ce sujet.
Qt Creator 3.0 utilisera automatiquement cet outil pour les projets basés sur Qt 5.2 ou ultérieur, vous ne devrez donc pas utiliser ces outils en ligne de commande, sauf si vous le désirez ; vous aurez, cependant, toujours la séparation entre les fichiers de compilation et les fichiers sources. En plus, Qt Creator conserve son caractère pratique, vous permettant de créer et d'éditer votre
AndroidManifest.xml, d'écrire, de compiler, d'exécuter, de déboguer et même de signer vos applications sans quitter un seconde Qt Creator.
Si tout cela vous intéresse, téléchargez le SDK ou compilez le manuellement depuis les sources. Vos retours seront très importants afin de corriger les derniers bogues avant la sortie de la version finale de Qt 5.2.
Partager