Archives pour la catégorie Debugging

Flex Tip – Intercepter tous les dispatch d’évènement d’une application Flex (logging, …)

Avant de vous présenter ce « tip », je vais quand même présenter le site sur lequel je l’ai trouvé, qui s’appelle Flex Army kNife:

http://www.flexarmyknife.org/

Un blog que j’ai découvert aujourd’hui (il n’est jamais trop tard) et qui contient quelques perles, notamment sur des sujets assez avancés. Il est tenu par @benzonico et @epascal, des suisses que j’ai pu rencontrer lors de Back From MAX Paris. Ils avouent eux-même que le blog n’est pas souvent mis à jour, faute de temps mais cet article va peut-être les encourager :)

Le tip du jour est sur cet article:

http://www.flexarmyknife.org/2010/09/logging-all-events-of-flex-application.html?spref=tw

Un petit article qui date de Septembre 2010 mais qui peut vous être utile, notamment lorsque vous faites un debug assez laborieux sur un système très asynchrone. A partir d’une certaine complexité, il est difficile de s’y retrouver et parfois, on aimerait juste mettre un point d’arrêt sur tel et tel type d’évènement.

Le code suivant permet d’ajouter un « hook » et de s’abonner au dispatch de tous les évènements:

import mx.core.mx_internal;
private static function hookDispatchEvent():Boolean
{
   UIComponent.mx_internal::dispatchEventHook = logEventHook;
   return true;
}
private static function logEventHook( event:Event, uic:UIComponent ):void
{
   trace(event.toString()+" event dispatched from "+uic.toString()+ " to "+event.currentTarget);
}

Vous allez ainsi récupérer l’objet Event ainsi que le composant qui a dispatché l’évènement. Pour placer plus stratégiquement votre point d’arrêt, vous pouvez simplement faire un test sur la propriété « type » de l’Event ou sur le type de UIComponent qui a propagé l’évènement.

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

runas

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:

nexus

Ensuite, cliquez sur Run et le simulateur va se lancer:

emul

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.

Flex Tips – Ne donnez jamais « controlBar » comme id de composant

Un petit « bug » assez original que j’ai trouvé avec un collègue sur une application Flex toute simple.Voici en simplifié, le code que l’on avait pour notre application Flex 3:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" paddingBottom="0" paddingLeft="0"
                paddingRight="0" paddingTop="0">
  <mx:Canvas width="100%" height="100%" backgroundColor="white">
    <mx:HBox id="controlBar" backgroundColor="0xBBBBBB" width="100%">
      <mx:Button label="button 1" />
      <mx:Button label="button 2" />
      <mx:Button label="button 3" />
      <mx:Button label="button 4" />
    </mx:HBox>
  </mx:Canvas>
</mx:Application>

Plutôt simple, non? Il y avait bien sûr d’autres composants mais voilà le point principal qui nous intéresse. En théorie, on devrait avoir un Canvas blanc qui prend tout l’écran avec dedans, une barre de menu horizontale contenant quelques boutons. Voici pourtant le résultat:

controlBar

Bon, si vous avez lu le titre de ce billet (vous l’avez lu, non ?), vous avez sûrement compris ce qui cloche: l’identifiant donné à notre HBox: « controlBar« . Alors pourquoi cela représente-t-il un problème?

Et bien il existe déjà une déclaration de variable dans le composant Application qui est « controlBar »:

    /**
     *  The ApplicationControlBar for this Application. 
     *
     *  @see mx.containers.ApplicationControlBar
     *  @default null
     */
    public var controlBar:IUIComponent;

Votre composant vient donc en quelque sorte « surcharger » cette variable réservée pour une éventuelle ApplicationControlBar. Celle-ci vient se docker en haut de l’application, l’espace lui sera alors réservé même si votre composant est ailleurs dans la display list.

Voilà, pour corriger ce « bug », donnez simplement un autre identifiant à votre composant

AIR pour iPhone, iPad – Optimisation des performances

Le Packager For iPhone (alias PFI) n’a toujours pas été mis à jour pour fonctionner avec AIR 2.5 mais vous pouvez toujours l’utiliser dans le cadre d’applications ne nécessitant pas les APIs présentes dans AIR 2.5 ou les projets pur ActionScript 3. Pour l’instant, ce Packager a encore du chemin à faire car Adobe a perdu quelques mois de développements après les annonces d’Apple. La compilation est donc extrêmement longue, ce qui rend le développement laborieux.

Les plate-formes Apple sont certes puissantes pour des téléphones portables / tablettes mais bien moins puissantes que la plupart des PCs actuels. Les performances que vous avez pour votre application Desktop seront meilleures que celles sur iOS. Android, lui est plus optimisé (à ce que j’en ai ressenti) et offre une bonne vitesse d’exécution. Comme les ressources sont peu moins disponibles, l’application peut se mettre à « ramer » et le framerate peut descendre.

Pour éviter les ralentissements, il ne suffit pas de rejeter la faute sur les devices Apple. Celles-ci ne changeront pas, donc c’est vous (puisque le Packager n’évolue pas vite) qui allez devoir vous adapter. Même si cette étape peut sembler laborieuse, surtout à cause des temps de compilation, dites-vous que ces améliorations/optimisations que vous allez mettre en place vont aussi bénéficier à votre code qui sera joué sur d’autres plateformes, ce n’est donc pas du temps de perdu. J’ai du moi-même réaliser ces optimisations pour mon application pour iPad et cela fonctionne bien mieux désormais :)

Optimisation de votre code ActionScript 3

Avant d’aller plus loin dans l’optimisation, il faut déjà que votre code soit propre. En effet, votre code peut être écrit de différentes manières mais certaines sont plus rapides que d’autres. Les instanciations de classes par exemple sont très couteuses, il faut les réduire au minimum et ré-utiliser vos instances. Ce n’est qu’un exemple, vous trouverez plus d’informations sur ces articles que je conseille fortement à n’importe quel développeur Flex / AS3:

Mesurer les performances de son application

On ne peut pas faire d’optimisation sans comparer de résultat. En effet, comment savoir si une application est plus rapide, sans avoir le nombre de FPS par exemple, l’instinct ne suffit pas. Il existe cependant des outils permettant de mesurer les performances de votre application, aussi bien en terme de FPS, que de mémoire ou que d’instanciation.

Le plus puissant étant le Profiler intégré à Flash Builder Pro puisqu’il permet de visualiser facilement le nombre d’instances courantes par exemple. Voici quelques tutoriaux pour vous aider à l’aborder:

D’autres outils comme la classe Stats de Mr Doob vous permettront d’avoir beaucoup d’informations, directement dans votre application. Ce composant est donc visible sur votre iPhone car il fait partie de l’application pas comme le profiler qui est externe. Il existe de nombreux autres outils qui sont référencés dans cet article d’Elad Elrom:

Optimize Flash Content and Improving Usability on Mobile Devices – Part #1

Autres documents intéréssants

Voici d’autres liens qui vous donneront une bonne dose d’informations:

Flex Roadmap – Le futur du SDK Flex (post-Hero)

Pendant Adobe MAX 2010 se sont déroulées de très nombreuses sessions parmi lesquelles, une session dirigée par Deepa Subramaniam (Senior Product Manager for the Flex SDK). Durant cette session d’environ une heure, elle a présenté le futur du Flex SDK.

Cette session est vraiment très très très intéressante. Si vous êtes développeur Flex /AIR, vous devez absolument la regarder, de nombreuses pistes sont dévoilées.

Les sessions peuvent maintenant être visualisées sur le site d’Adobe MAX 2010. Voici donc la vidéo de la présentation « Flex Roadmap »:

Comme je l’ai dit plus haut, je vous conseille très vivement de regarder cette vidéo en entier, on y apprend beaucoup. Pour ceux qui n’ont pas envie, voici un petit résumé.

Le futur du SDK Flex

Avant tout chose, il faut préciser que ce qui est dit lors de cette présentation (et répété ici) ne sera pas forcement implémenté. On parle d’objectifs à long terme qui pourront être modifié (ou supprimés) au cours du temps.

Voici donc les points forts de la présentation (selon moi).

Enrichissement de la librairie de composants Spark

Ce n’est pas nouveau et c’est plutôt un objectif aussi court terme, de nouveaux composants Spark vont arriver pour compléter les composants qui existaient en Flex 3 (Halo). Dans Hero, on a déjà accès à Spark Form, Spark Image et Spark DataGrid qui est toujours un peu en chantier. De nouveaux composants seront développés pour encore plus de possibilités out-of-the-box.

Utilisation des APIs de globalization de Flash Player 10.1

Flash Player 10.1 embarque de nouvelles APIs de « globalization » qui permettent de connaître la « locale » (le langage /pays) du poste client. Les composants seront ainsi automatiquement adaptés à la locale de l’utilisateur (Validator, Formatter, …)

Lire la suite