Technical tracks cet après-midi, avec des présentations réparties dans cinq salles (
programme)
Je livre pour les personnes intéressées mes notes personnelles "brutes"...
Step by step Qt on Android tutorial
Bogdan VatraBogdan a porté Qt sur Android tout seul. Applaudissements. Mérités!
Salle plus que comble, des chaises sont rajoutées dans le fond. Le sujet éveille apparemment l'intérêt de nombreux développeurs désireux d'élargir leur public.
Au moment de demander à l'audience qui possède un téléphone Android, 95% de la salle lève la main.
Statut du développement: trop rapide pour tout noter, mais les fonctionnalités sont implémentées aussi vite que possible (beaucoup manquent encore ou sont hypothétiques)
OpenGL: dans 5.2, pas moyen de mélanger QGLWidget avec d'autres QWidgets (=> un seul widget affichable à la fois), "espoirs" de pouvoir faire mieux dans 5.3.
Mise en place de l'environnement ("complexe, mais pas si compliqué après tout"
:
- Linux, Windows, Mac sont supportés, démo faite sous Linux
- ant et openJDK6 (pas 7!) )nécessaires
- QtSDK (avec Android dans le nom)
- Android SDK (ver. 22+) (ADT pas nécessaire)
- Android NDK
- Android API-10 (aussi API-11 si vous voulez compiler Qt par vous-même)
- USB debugging activé sur le téléphone Android
- Tools->Options->Android
Android SDK, NDK, ant, JDK location
"Create kits for Android tool chain" coché
Presser "Apply" avant "OK" (oubli/bug)
Décocher "warn when debugging release builds"
Utilisation:
- Nouveau projet
- Choisir Kit Android
- Pour débugger, sous 5.1, choisir GDB 4.6 (ne fonctionne pas avec 4.8)
- Editer AndroidManifest.xml
- Signer l'application (le certificat de debugging est uniquement temporaire)
- Note: l'application est totalement réinstallée à chaque recompilation et redémarrage depuis le QtCreator (compter ~30 secondes) car les certificats sont temporaires.
Déploiement:
Options:
- Livrer les bibliothèques Qt dans l'APK: contient tout ce dont on a besoin, mais les fichiers deviennent énormes (50+ Mo), un APK doit être créé pour chaque plateforme (armv5, armv7, x86), les bibliothèques ne sont partagées avec d'autres applications,...
=> pas réaliste dans la plupart des cas!
- Utiliser Ministro:
Service installé sur le téléphone Android ou téléchargé du PlayStore au premier démarrage de notre app.
Ministro va chercher les bibliothèques Qt nécessaires
App ne contient que les bibliothèques .so et les resources.
=> App plus rapide, moins lourde... mais installation de Ministro nécessaire au premier démarrage d'une application Qt sur le téléphone Android
Solution recommandée si on veut développer sous Windows: installer Linux!
Conclusions personnelles:
- Intéressant, prometteur, mais pas encore assez stable et évolué pour être utilisé pour autre chose que l'expérimentation!
Qt on WinRT
Andrew KnightSalle à peine moitié pleine...
Andrew utilise un PC sous Windows 8.1 comme plateforme de développement.
Windows Runtime "raisonnablement" identique et compatible entre W8, WP8, WinRT
Pourquoi Qt sur WinRT?
- Base d'utilisateurs potentiels énorme
- Pourquoi pas, vu qu'une grande partie du code existe déja? => Une nouvelle QPA doit être développée
Statut:
- Courramment, dans la Dev Branch de Qt 5.3
- Tech Preview Snapshot dans Qt 5.2 Release
- Beta dans la version 5.3
Note: Clavier virtuel utilisable uniquement si la machine a un écran tactile
QPA/GL:
- ANGLE fournit OpenGL par le biais de Direct3D
- Les shaders doivent être pré-compilés (= fournis sous forme de blocs binaires) => Pas un problème sur WinRT (compileurs temps-réels disponibles), mais actuellement pas encore de solution sous WP8
- Gestion des fenêtres simplifiée à l'extrême... puisque l'on est toujours en mode plein-écran!
Widgets: stable, pas encore de styles
QtQuick2: fonctionne relativement bien
Déploiement via windeployqt, se charge des DLLs, etc.
Debugging: localement uniquement pour l'instant, remote planifié.
Qt Creator:
- Plugin expérimental développé sur la base du code de Qt Creator 3 (non livré sous forme binaire, à compiler soi-même, fonctionne uniquement sous W8)
- Les options du programme permettent de définir des arguments pour le programme, ce qui est utile car on ne peut pas définir d'arguments depuis les "launchers"
- Penser à livrer les ressources, p.ex. les fontes lorsque l'on affiche un texte!
- Utiliser le bouton "Stop" de Qt Creator pour terminer une application plutôt que d'essayer de fermer l'app depuis l'UI (scenario non supporté par W8)
Déploiement sous WP8:
- Effet démo, ne marche pas... :-/ (mais démo visibles au stand Digia, fonctionne sur tablette Surface (WinRT) et téléphone Lumia (WP8))
Marche à suivre pour prendre part au développement du port de Qt sur WinRT (toute aide bienvenue!):
- Installer MSVC, Windows 8 SDK, Windows Phone 8 SDK
- Cloner qtBase/dev, appliquer les patches dans devWinRT
- configure -xplatform <target> -<arch> -msvc2012
- targets: winrt, winphone
- arch: x64, x86, arm
- IRC: #qt-winrt
Questions:
- Equivalent de Ministro?
Pour l'instant, il n'existe encore aucun framework dans l'app store (privilège de MS??), mais si la situation change, Qt pourrait être proposé sur le store, ce qui simplifierait les choses!
- Emulateur? Yep, mais l'émulateur supporte certaines fonctions non encore supportées par le matériel => Faire attention à ce que l'on teste.
Qt for iOS
Richard Moe GustavsenSalle pleine (quoique pas autant que pour la présentation sur Android...)
Pas de slides, adepte du "live coding"...
Qt doit être attaché statiquement (requis par Apple) => Livrer toutes les bibliothèques avec les apps!
Qt5.1: Un peu de "plomberie" à faire dans Qt Creator, qui disparaîtra dès Qt5.2
xcode nécessaire pour le développement => le code créé peut tourner dans l'émulateur de xcode (permet un développement relativement réactif)
Il suffit d'éditer le code QML dans Qt Creator, de "nettoyer" le code depuis xcode et d'y lancer l'app (+ make si on a ajouté des fichiers au projet).
Garantie de pouvoir soumettre les apps créées sur l'App Store (= pas de risque de la voir rejetée à cause de bibliothèques livrées avec Qt)
Impression générale: beaucoup plus abouti que le port Android, le développement est efficace car les outils en place réactifs (probablement car basés sur une base stable: xcode)
A demain pour la suite... Ce soir, c'est "Party" au programme.
1 |
0 |
Envoyé par 0x4e84
!
