AIR pour Android – Debug sur mobile FroYo / emulateur avec Flash Builder 4
Dans cet article, on va voir comment debugger une application Air lancée sur Android (device ou emulator). Cet article est largement inspiré d'un article écrit par Renaun Erickson (Adobe Platform Evangelist):
Debug AIR apps on Android with Flash Builder 4
Avant de commencer à debugger, il faut tout d'abord que vous ayez une connaissance basique du développement Air pour Android (notamment au niveau du déploiement sur émulateur / mobile). Pour cela, je vous conseille vivement cet article:
Air Android – Créer une application Air pour Android (apk), le guide de A à Z
Maintenant que vous savez comment développer une application dans de bonnes conditions, vous allez rapidement avoir besoin de débugger votre application. Ne serait-ce que pour identifier certaines procédure qui ne passent pas sur Android ou pour tester les fonctionnalités spécifiques d'Android (changement de rotation, etc.). On verra dans un prochain article que l'on peut aussi faire du logg, un peu comme on le fait avec les instructions "trace()".
Les grandes étapes
Pour débugger votre application, vous allez devoir suivre plusieurs étapes (dans l'ordre). Voici les étapes qui seront détaillées plus tard dans cet article:
- Connecter le mobile Android sur le même réseau que la machine sur laquelle se trouve Flash Builder et récupérer son adresse IP. On verra que l'on peut aussi profiter de l"émulateur Android si vous n'avez pas de device.
- Compiler l'application pour du debug (l'application Air avec mxmlc et l'application Android native APK avec adt)
- Déployer la version de debug de l'application sur le mobile ou sur l'émulateur
- Configurer le projet Flex Builder pour lancer la session de debug sans lancer l'application
- Lancer la configuration de debug que vous venez de créer
- Lancer l'application Air sur le mobile ou sur l'émulateur
- (Optionnel) Si vous n'avez pas défini d'option -connect pour adt, entrer l'IP de la machine sur laquelle se trouve Flash Builder.
Compilation de l'application Air en debug
Pour pouvoir débugger l'application, il faut que votre application soit compilée en indiquant que vous souhaitez un mode debug. C'est le cas des applications crées dans Flash Builder 4, que l'on a crée dans le tutorial sur le développement Air pour Android.
Vous pouvez directement prendre le SWF généré dans le répertoire "bin-debug" de votre projet. Si vous utilisez une compilation en ligne de commande avec mxmlc, il vous suffit d'ajouter l'option -debug=true.
Voici par exemple la ligne de commande (sous Max OS X):
AIR_SDK=$USER_WORKSPACE/FlexSDKs/flex_sdk_4.0.0.14159_air2_android_prerelease
$AIR_SDK/bin/amxmlc -target-player 10.0.0 -debug=true DebugDemo.mxml
Notez que l'on utilise ici "amxmlc" et pas "mxmlc". amxmlc est un script qui fait le même travail que mxmlc mais configuré pour utiliser les librairies Adobe Air
A l'issue de cette compilation, vous obtiendrez un fichier SWF qui vous sera utile pour compiler votre application Android (.APK)
Compilation de l'application Android en debug
On va voir maintenant comment compiler votre application Android en debug. La aussi, très simple, il suffit de modifier la ligne de commande que vous utilisez avec l'utilitaire "adt".
Voici par exemple la ligne de commande utilisée dans le tutorial Air pour Android:
adt -package -target apk -storetype pkcs12 -keystore cert.p12 AndroidFT.apk AndroidFT-app.xml AndroidFT.swf assets/
Pour compiler la même application en mode debug, il suffit de modifier l'argument "target" qui est à la valeur "apk" de base. Pour une version debug, remplacez "apk" par "apk-debug" et vous obtiendrez:
adt -package -target apk-debug -storetype pkcs12 -keystore cert.p12 AndroidFT.apk AndroidFT-app.xml AndroidFT.swf assets/
Il faut rajouter à cela un attribut "-connect" qui va spécifier la machine sur laquelle l'application va essayer de se connecter pour lancer la session de debug. Vous pouvez entrer plusieurs types de valeur:
- Un nom de machine (nom réseau)
- Une adresse IP (celle de la machine sur laquelle se trouve FB4
- la chaîne "…". Dans ce cas-là, l'application va vous demander sur quelle IP vous voulez connecter la session de debug au lancement de l'application
Pour un debug local avec l'émulateur, on a donc:
adt -package -target apk-debug -connect 127.0.0.1 -storetype pkcs12 -keystore cert.p12 AndroidFT.apk AndroidFT-app.xml AndroidFT.swf assets/
Pour nos tests, on va mettre comme paramètre connect "…" afin de pouvoir entrer l'adresse IP au démarrage de l'application.
Transfert de l'application Android APK
Pour transférer votre application Android vers l'émulateur, suivez les instructions du tutorial sur le dév Air pour Android. Pour déployer sur un mobile, connectez votre mobile en USB et assurez-vous d'être en mode Debugging USB. Envoyez ensuite l'application sur votre mobile comme vous le feriez avec l'émulateur (adt -e install).
Si vous n'avez pas le câble, vous pouvez aussi vous l'envoyer par email et récupérer la pièce jointe. Android vous permettra d'installer directement l'apk téléchargé.
Création de la configuration de debug dans Flash Builder 4
Pour pouvoir debugger depuis Flash Builder, on va créer une "Debug configuration". C'est un processus très simple, vous utilisez sûrement déjà les configurations de debug par défaut pour vos projets Flex / Air. Ici, le cas est assez particulier, on va donc créer une "Debug configuration" personnalisée.
Pour accéder à l'interface de configuration, Run > Debug > Other ou depuis les icônes:
On va ensuite créer une nouvelle configuration de debug pour une Web Application:
Configurez ensuite les options comme ceci:
Notez que notre cas est un peu spécial et vous devrez entrer le nom de votre projet à la main car Browse va seulement chercher les projets Flex et ActionScript, pas les projets Air pour un configuration "Web Application".
Vous remarquerez que l'on ne va pas utiliser le path par défaut pour le lancement. Au lieu de cela, on remplace la valeur par défaut par "about:blank" volontairement. De cette manière, la configuration de debug ne va pas lancer d'application et va simplement se mettre en attente d'une session de debug. Cette session de debug sera initiée par notre application Android à son démarrage.
Création de la connexion debug entre l'application Air et Flash Builder
C'est là que cela devient marrant, il faut maintenant faire le pont entre les deux. Pour l'instant, je n'ai pas réussi à faire du debug avec une application sur l'émulateur. A mon avis, je ne prend pas le bonne IP de connexion. En effet, l'émulateur est sur un Linux qui possède ses propres interfaces ethernet (adresses en 10.quelque chose). Je n'ai pas de réseau Wifi chez moi donc pour connecter les deux machines sans le cable, il m'a fallu une autre solution
Heureusement, j'ai actuellement un HTC Desire sous Android 2.2 et avec Android 2.2 vient non seulement Flash Player mais aussi la possibilité de transformer votre mobile Android en Hotspot Wifi ! Si vous avez le câble USB, je pense qu'il vous faudra activer l'option "USB tethering" dans les Settings et votre portable fera partie de votre réseau local.
Transformer votre mobile Android en Hotspot Wifi
C'est assez trivial, rendez-vous dans Settings > Wireless & Networks puis activez "Portable Wi-Fi hotspot". Depuis votre PC, connectez vous au réseau HTC Mobile. Le mot de passe de connexion se trouve sur l'écran Portable Wi-Fi hotspot settings (1234567890 par défaut). Restez sur cet écran pour visualiser l'adresse IP de votre PC connecté en WiFi. Pour cela, rendez-vous dans Manage Users
Ensuite, cliquez sur votre utilisateur et son adresse IP va s'afficher. Dans mon cas, 192.168.1.157 (ok, les photos sont de très mauvaise qualité !):
Ce sera utile pour la suite, notez la quelque part. Transférez l'application vers votre mobile si vous ne l'avez pas déjà fait puis lancez-là. Si vous avez bien compiler une application avec comme paramètres -target "apk-debug" et -connect …, vous devriez avoir un écran comme celui-ci:
Avant d'entrer l'adresse IP de votre PC, vous devrez lancer l'application en debug depuis Flash Builder à partir de la configuration de debug que vous venez de créer plus haut:
Cette configuration devrait vous passez automatiquement dans la vue de debug de Flash Builder. Vous pourrez ainsi vous que le debug est en attente d'une connexion:
Alors ensuite, j'ai du désactiver mon Firewall Windows. J'ai essayé d'ajouter des règles sur certains ports spécifiques (la connexion de debug utilise le port 7935) mais sans succès. Par contre, en désactivant totalement le firewall, cela fonctionne. Si vous avez trouvé la bonne règle, merci de laisser un commentaire sur cet article!
Entrez l'adresse IP de votre PC sur votre application Android et la session de debug devrait se faire. Vous pouvez ensuite utilisez vos points d'arrêt, faire des Watch sur vos variables etc.
Si la connexion ne se fait pas, vérifier que vous essayez de vous connecter à la bonne IP et vérifiez que vous avez bien autorisé tous les ports nécessaires.
Test Driven Development (TDD) avec FlexUnit 4, un exemple complet
Ce n'est pas vraiment une mode puisque le TDD existe déjà pour des technologies plus anciennes que le Flex (Java, ASP, …). En quelques mots, celui-ci consiste à coder les tests avant de développer. Le développement ne commence que lorsque les tests ont tous donné le feu vert. Ainsi, toute l'étape de "debugging" est réalisée en amont.
Cela parait un peu flou au premier abord, et c'est pour cela que Elad Elrom a publié un article très complet sur le Test Driven Development:
Test Driven Development (TDD) with FlexUnit 4 – Complete Tutorial
Le bon côté de cet article est de présenter une approche du TDD sur une application qui ne soit pas un calculatrice (souvent l'exemple utilisé pour démontrer l'intérêt des tests unitaires). On a ici un client tweeter en Flex pour lequel on va tout d'abord écrire des tests (récupérations des tweets) puis le code correspondant.
De manière très subjective, je ne trouve pas ma place dans le TDD. Même si dans cet article, on tente de faire rentrer un "vrai cas d'application", on peut quand même voir que l'on doit pas mal travailler (création et code de tests) avant de pouvoir même valider le test. En une fois testé, il reste quand même la plupart des développements "ennuyeux" à faire (création et calage de l'interface au pixel, communication entre les classes & co). Bref, je n'y vois pas un gain de temps.
Si vous avez testé le TDD, que vous l'utilisez en production ou que vous avez fait machine arrière ou même que vous avez simplement envie de donner votre avis, n'hésitez pas à laisser un commentaire, je suis curieux de connaître votre opinion sur le Test Driven Development.
Mes projets (Open Source)
Autres
