AIR Mobile – Application Pokémon (4) – Lancer l'application dans l’émulateur + debugger
Les Flexeurs expérimentés connaissent déjà cas manipulations mais on va les revoir pour ceux qui nous rejoignent en route. On va voir comment lancer notre projet dans l'émulateur intégré à Flash Builder. Cette étape est importante car c'est comme cela que l'on va tester notre projet en cours de développement.
Flash Builder vous permet aussi de lancer directement votre application sur votre device si celui-ci est relié à votre machine en USB et si vous avez bien installé les drivers appropriés (Android). Pour l'instant, on ne va pas détailler cette opération, admettons que vous n'ayez pas de smartphone.
Il est aussi possible de débugger votre application, soit dans l'émulateur, soit sur device (en USB ou en Wifi). Très utile pour détecter les problèmes dans votre application ou pour tester directement les valeurs renvoyées par les interactions multi-touch par exemple.
Pour le premier lancement, vous allez devoir configurer quelques options. Flash Builder se souviendra de celles-ci et vous permettra de lancer directement l'application avec les derniers paramètres enregistrés.
Faites un clic droit sur le fichier principal de votre application, PokemonInfos.mxml puis Run As > Mobile Application
Une boîte de dialogue va s'ouvrir vous présentant les différentes options. Pour l'instant, on va simuler un appareil Android, n'importe lequel. Prenez le Nexus One par exemple:
Ensuite, cliquez sur Run et le simulateur va se lancer:
Super, non ? ^^Pour la suite, vous pouvez directement cliquer sur Run ou Ctrl+F11 pour lancer la dernière configuration. Pour éditer la configuration de lancement, rendez-vous dans le menu Run > Run Configurations….
Pour le debugging, même manipulations, mais avec Debug et pas Run. Le debugging dans Flash Builder s'est grandement amélioré au fur et à mesure des versions mais cet article que j'ai écrit il y a 3 ans sur Flex Builder 2 est presque toujours d'actualité:
Flex Debug – Debugging avec Flex Builder 2
Pour vous faire la main, ajoutez un point d'arrêt dans la méthode "onAppComplete" et effectuez un pas-à-pas dans le code. Vous pouvez aussi inspecter (Watch) des Expressions et leurs valeurs pour voir les changements lors de l'exécution du code. Cela vous sera utile quand vous devrez déterminer la cause d'un problème, une variable qui reste "null" par exemple.
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.
Flex Tips – Debugger avec Firefox 3.6.6 et supérieur (protection anti-crash Flash)
Pour debugger mes applications Flex, j'utilise comme navigateur Firefox, bien pratique surtout grâce au plugin Firebug. Depuis la versions 3.6.6, Firefox sépare tous les plug-ins dans un processus séparé (plugin-container.exe sous Windows). De cette manière, si Flash plante, votre navigation peut continuer, vous aurez simplement un message "Flash crashed" à la place de l'animation et on vous proposera de redémarrer le plug-in Flash.
Très bonne nouvelle donc, puisque FF suit les traces de Chrome, qui avait fait de cette séparation, son "principal argument de vente".
Sauf que cette protection est uniquement utile pour un utilisateur final. En effet, quand on entre en debug dans Flash Builder, FF considère que l'application Flash ne répond plus et au bout de 45 secondes, il va tuer le processus, en tuant en même temps, notre session de debugging.
45 secondes pour débugger, c'est très court, mais il y a un moyen pour contourner cette protection (la désactiver):
Mozila Firefox – Disable hang protection
Après cette modification, vous pourrez reprendre vos sessions de debugging comme avant 
Au passage, on se rend aussi compte avec ces nouvelles protections de l'importance d'un code propre. Si vous avez le Flash Player Debugger, vous vous êtes sûrement rendu compte que de (trop) nombreux sites lancent des erreurs d'exécution (null pointer, nombre d'arguments non correspondants, …). Parfois on se demande même si certains sites ont été testés avant d'être mis en production.
Si vous êtes développeur sur un de ces sites, corrigez ces erreurs d'exécution (si vous n'y arrivez pas, envoyez-moi un mail!). Cela rendra vos utilisateurs plus heureux et cela évitera de nuire un peu plus à la réputation de Flash
Flex Tips – Afficher facilement les trace() de son application sans passer par Flex Builder avec Notepad++
Pour logger des informations de debug, la plupart d'entre nous utilise simplement des instructions trace() (ou tout autre système détourné de Logging qui fait des trace() au final). D'autres utiliseront des debugger externes comme Alcon ou De MonsterDebugger.
Dans un environnement de développement, vous allez installer le Flash Player Debugger et simplement lancer votre application en Debug dans Flex Builder afin que tout se retrouve dans la console. Mais vous pouvez aussi indiquer à Flash Player qu'il doit écrire sa sortie dans un fichier texte sur votre disque. La procédure est plutôt simple puisqu'il suffit de placer un fichier mm.cfg sur votre disque (au bon endroit) avec 2 instructions dedans et de relancer votre navigateur.
Si vous ne l'avez pas encore fait, voici la procédure:
Debugging Flex applications with mm.cfg and flashlog.txt
Vous avez donc votre flashlog.txt contenant votre logging sur votre disque que vous pouvez analyser avec un outil externe. Mais si vous êtes comme moi et que votre machine mouline car Flex Builder lui mange toute sa RAM, vous n'avez sûrement pas envie d'installer/lancer une autre application.
Le plus simple et productif que j'ai trouvé est d'utiliser Notepad++. Si vous ne l'avez pas, c'est un excellent éditeur de texte (sorte de super Notepad comme son nom l'indique), avec coloration du code dans de nombreux langages.
Bref, un outil indispensable pour les développeurs. L'aspect sympa de Notepad++ est que lorsque vous avez un fichier ouvert, il va régulièrement vérifier s'il a été modifié sur le disque. Et comme Flash Player va écrire dans le fichier flashlog.txt, Notepad++ va détecter ce changement et vous demander si vous voulez recharger ce fichier. Et comme vous vous trouvez dans un éditeur de texte, vous pouvez facilement l'utiliser pour faire de la comparaison de texte, du replace de caractères et autres.
La vue est aussi bien plus dégagée que la console de Flex Builder et le logiciel est très light d'un point de vue mémoire. A vous de vous faire votre avis mais c'est la solution que j'ai choisi 
Flex Debug – Utilisation de trace() dans une application Flex
Bien que ce ne soit pas une technique avancée de debug, de temps à autre, un développeur va avoir besoin de faire un trace (aussi appelé log) de ses messages depuis l'intérieur d'une application. C'est pour cela que Flash Player expose une méthode globale trace(). Les messages peuvent être loggés depuis n'importe quel point de l'application, simplement en appelant la méthode trace() et en lui passant des paramètres de types String:
trace ("application initialisée");
Mes projets (Open Source)
Autres
