LAlex devblog v6

Bug de l'IDE Flash: Bibliothèque, héritage et déclaration automatique

-Alexandre LEGOUT aka LAlex- — Tue, 29 Nov 2011 23:22:00 +0100

J'aimerais aujourd'hui vous exposer un bug de l'IDE Flash, notamment de son compilo, lorsque l'on combine l'utilisation des symboles de la librairie avec une classe, et la fonctionnalité de déclaration automatique des instances (présente dans les paramètres de publication). Cette option est cochée par défaut, et lorsque l'on travaille sur la timeline, a priori le meilleur process quand on travaille avec des créas, il est à mon sens important de donner le moins de contraintes possibles à ces derniers. Il doivent pouvoir donner (ou pas) des noms aux éléments qu'ils posent sur la timeline, notamment en prévision de code que viendra brancher un développeur ou pour de simples raisons d'organisation... d'où l'importance à priori de laisser cochée l'option "Déclarer automatiquement les instances de la scène". Avec quelques instructions, les créas peuvent ainsi créer leurs assets, voire utiliser directement du code fourni par un framework ou une bibliothèque de code au moyen des propriétés "Classe" et "Classe de base" pour les éléments de la bibliothèque.

Par exemple, comme beaucoup de développeurs je pense, je dispose d'une classe qui me permet de gérer les rollovers de boutons fait sur la timeline. Il suffit d'utiliser cette classe comme classe de base d'un élément pour qu'un créa puisse faire des boutons fonctionnels sans l'aide d'un codeur. Pour mes exemples, je vous propose une classe "BaseButton":

package com.lalex.display {

        import flash.display.MovieClip;

        import flash.events.MouseEvent;



        /**

         * @author LAlex

         */

        dynamic public class ButtonBase

                extends MovieClip {



                public function ButtonBase() {

                        mouseEnabled = true;

                        buttonMode = true;

                        useHandCursor = true;

                        mouseChildren = false;

                        

                        addEventListener(MouseEvent.CLICK, clickHandler);

                }



                protected function clickHandler(event : MouseEvent) : void {

                        trace("Base button clicked");

                }

        }

}

Un intégrateur peut alors utiliser les fonctionnalités de cette classe en créant un élément de la bibliothèque, dans cet exemple RedButton:

Le contenu de RedButton consiste en un clip représentant un rond rouge, sans nom d'instance.

A la compilation, le résultat est celui attendu, à savoir un rond rouge cliquable, qui affiche une main lorsque l'on passe dessus, et trace "Base button clicked" lorsqu'on clique dessus.

Afin de démontrer mes dires, je compile le .fla dans un .swc, que j'ouvre avec FDT pour voir ce que le compilo génère comme classes. Je fais en sorte que les classes générées automatiquement par l'IDE Flash fassent partie du package "com.lalex.flash". Avec les paramètres précédents appliqués à ce bouton tout simple, j'obtiens donc logiquement une classe générée qui a la structure suivante (en passant sur les imports inutiles):

// Generated from  ButtonBase.swc

// Breakpoints are not supported

package com.lalex.flash {

        import com.lalex.display.ButtonBase;



        import flash.display.DisplayObject;

        import flash.events.EventDispatcher;

        import flash.display.Sprite;

        import flash.display.InteractiveObject;

        import flash.display.MovieClip;

        import flash.display.DisplayObjectContainer;



        public dynamic class RedButton extends ButtonBase {

        }

}

Ma classe ButtonBase est évidemment inchangée:

// Generated from  ButtonBase.swc

// Breakpoints are not supported

package com.lalex.display {

        import flash.display.DisplayObject;

        import flash.events.EventDispatcher;

        import flash.display.Sprite;

        import flash.display.InteractiveObject;

        import flash.display.MovieClip;

        import flash.events.MouseEvent;

        import flash.display.DisplayObjectContainer;



        public dynamic class ButtonBase extends MovieClip {

                protected function clickHandler(arg0 : MouseEvent) : void;

        }

}

Voyons maintenant ce qui se passe lorsque l'on donne un nom d'instance à mon rond rouge:

Lors de la compilation, toujours aucun problème, le résultat est exactement le même. Si on y réfléchit, on pense tout naturellement que cette fameuse option de déclaration automatique des instances a bien évidemment rajouté une propriété "background" dans ma classe com.lalex.flash.RedButton, or lorsque l'on regarde les classes du SWC on y trouve bien autre chose. En effet, ma classe RedButton est inchangée:

// Generated from  ButtonBase.swc

// Breakpoints are not supported

package com.lalex.flash {

        import com.lalex.display.ButtonBase;



        import flash.display.DisplayObject;

        import flash.events.EventDispatcher;

        import flash.display.Sprite;

        import flash.display.InteractiveObject;

        import flash.display.MovieClip;

        import flash.display.DisplayObjectContainer;



        public dynamic class RedButton extends ButtonBase {

        }

}

Et ma classe BaseButton (donc une classe fournie par mes soins à l'IDE) a été modifiée:

// Generated from  ButtonBase.swc

// Breakpoints are not supported

package com.lalex.display {

        import flash.display.DisplayObject;

        import flash.events.EventDispatcher;

        import flash.display.Sprite;

        import flash.display.InteractiveObject;

        import flash.display.MovieClip;

        import flash.events.MouseEvent;

        import flash.display.DisplayObjectContainer;



        public dynamic class ButtonBase extends MovieClip {

                // [LAlex] This property has been added by Flash!!!

                public var background : MovieClip;



                protected function clickHandler(arg0 : MouseEvent) : void;

        }

}

Comment se fait-il donc que l'IDE se "permette" de modifier une classe qui lui a été donnée?!? Cela risque en effet de modifier son comportement, notamment lorsque cette classe est aussi destinée à être étendue. C'est pourquoi cette propriété "background" aurait clairement du être ajoutée à la classe com.lalex.flash.RedButton...

Par exemple, je veux maintenant créer une classe GreenButton qui va étendre ButtonBase. Cette classe aura une propriété "background" qui peut être un Bitmap. Quid de l'héritage?

package com.lalex.test {

        import flash.geom.ColorTransform;

        import flash.geom.Transform;

        import com.lalex.display.ButtonBase;



        import flash.display.Sprite;



        /**

         * @author LAlex

         */

        public class GreenButton

                extends ButtonBase {

                

                public var background:Bitmap;

                

                public function GreenButton() {

                }

        }

}

Au vu de la manière dont Flash a géré/modifié les classes, on obtient logiquement un conflit entre la déclaration de la propriété "background" dans la version modifiée de ButtonBase, et la déclaration de la propriété "background" dans la classe GreenButton.

/****/com/lalex/test/GreenButton.as, Line 14 | 1152: A conflict exists with inherited definition com.lalex.display:ButtonBase.background in namespace public.

Evidemment, il est toujours possible d'imposer aux créas des process un peu plus stricts sur le nommage de leurs objets sur la scène, l'idéal étant de pouvoir désactiver l'option "Déclarer automatiquement les instances de la scène". Mais dans la pratique, on sait bien que cela n'est pas toujours évident et que l'absence de déclaration automatique, plus propre, ne convient qu'aux codeurs qui travaillent en toute fin du production, sans parallélisation des taches dev/créa, ou sans intervention d'un créa après le développement. Et il faut le dire, ce mode de travail est bien rare sur des projets courts et/ou urgents dont les acteurs se télescopent souvent...

De toutes façons, le problème vient surtout que l'IDE Flash, qui est censé générer des classes via les éléments de la bibliothèque, se permet à ce moment là de modifier des classes qui lui sont fournies au format .as, ce qui est tout à fait anormal. Cela va à l'encontre du principe d'héritage en POO: une base commune et plusieurs sous-classes qui héritent de celle-ci sans la modifier...

Livraison d'une application Flash

-Alexandre LEGOUT aka LAlex- — Mon, 07 Mar 2011 23:00:00 +0100

Une fois n'est pas coutume, ce blog reprend un petit poil de la bête pour un article même pas fait (que) pour les techos... mais plutôt pour les chefs de projets.

Lorsqu'un développeur code une application ou un site, il est victime systématiquement de l'effet "anguille". Cette pure invention de ma part signifie juste qu'il va tester généralement les cas qu'il a lui-même prévu lors de son développement et se faufiler naturellement entre les bugs qui pourraient intervenir lors d'une utilisation "normale" par un utilisateur "classique". C'est là qu'intervient la recette, généralement effectuée par le chef de projet, ou par un autre développeur, ou dans les structures les plus importantes par le service qualité. La recette est ensuite effectuée par le client final pour une dernière vérification.
La recette effectuée "en interne" est donc très importante, d'abord parce que moins il y a de bugs à la livraison finale plus on est crédible, ensuite parce que le client final n'a pas à sa disposition la même compétence, ni les même outils pour assurer une recette efficace.

Vous trouverez donc dans cet article un ensemble de conseils et d'outils pour une livraison en douceur d'un projet Flash.
Je précise que je travaille sur MacOSX, mais les pratiques citées ci-dessous sont tout aussi valables dans le monde PC.

I. Le serveur de livraison

Afin de s'assurer d'avoir le moins de surprises possible lors du déploiement en production, il est important pour le client livré de fournir un environnement de livraison ayant les mêmes caractéristiques que l'endroit ou sera déployé l'application finale. Il s'agit du serveur de pré-production, dit "préprod".
La livraison s'effectue le plus souvent par FTP sur un serveur qui idéalement:

tourner sur le même OS que la prod, donc pas de Linux pour une prod Windows et vice-versa
fournir les mêmes autorisations sur les dossiers/fichiers (les scripts de manipulation de fichiers doivent pouvoir accéder aux mêmes choses qu'en prod)
faire tourner les mêmes versions mineures des logiciels utilisés (PHP, MySQL, Apache ou IIS, AMFPHP, etc...)
donner les mêmes possibilités d'administration des URLs (redirections, .htaccess, erreurs 404, etc...)
donner l'accès aux même conditions d'URL (ne pas tester dans un sous-répertoire d'un nom de domaine un site qui tournera à la racine d'un domaine). Par exemple, tester un projet qui tournera sur http://www.monprojet.com sur une préprod qui serait http://preprod.monclient.com/monprojet peut donner des surprises au déploiement.

!NOTE AUX DÉVELOPPEURS! Comme ce dernier point n'est pas toujours possible, il est important dans ses développements de privilégier les chemins d'accès relatifs (../xml/config.xml) aux chemins d'accès absolus (/xml/config.xml). De la même manière, je conseille de toujours partir sur la base d'un seul fichier de configuration, commun à tous les codes de l'application (PHP, Flash, JS, sur front-office comme sur back-office), qui sera le seul nécessitant une modification lors du déploiement sur l'environnement de production. Ca simplifiera la vie à tout le monde!

II. Configurer son ordi pour une recette

1. Un ordinateur stable

Ca peut paraître bête à dire, mais si on utilise un ordinateur qui plante tout le temps (je serais mesquin, je dirais "un PC par exemple" :-P), on ne saura jamais si c'est l'application ou l'environnement qui plante. Avoir un système propre et stable est donc la première étape d'une recette.

2. Un navigateur configuré pour "recetter"

Personnellement, j'utilise Chrome au quotidien, selon moi plus adapté au surf de tous les jours car rapide et léger. Je n'ai pas besoin d'une quelconque extension tant mes besoin ne sont vraiment pas exceptionnels en matière de surf. De plus, la mise à jour est transparente, autant pour le browser lui-même que pour le player Flash, et je suis donc sûr d'être sur la dernière version disponible en permanence. De plus, le Flash player est interne à Chrome, ce qui me permet d'installer une version différente pour mes autres navigateurs.

Pour le travail, notamment sur Flash, j'utilise par contre Firefox, pour ses nombreuses extensions dédiées au développement, que nous verrons plus loin. Il peut-être bien pratique d'installer un navigateur uniquement pour le débugage: si vous utilisez Firefox en tant que navigateur principal, je crois qu'il est possible d'en installer plusieurs instances.
Un navigateur destiné à la recette doit être configuré pour ne pas utiliser de cache: on n'imagine même pas le nombre d'heures passées en discussions stériles entre développeurs et testeurs uniquement parce que ce n'était pas la même version qui était testée... Les navigateurs sont parfois capricieux à vider leur cache, qui se répand dans les méandres du disque dur. Alors pour vous épargner ce temps en étant sûr de ne pas avoir affaire au cache, vous pouvez utiliser un plug-in qui va le désactiver. Pour ma part, il s'agit de la Web Developer Toolbar de Firefox.

3. Le player DEBUG

Une erreur Flash ne remonte pas lorsque le player classique est utilisé. Il est donc important d'avoir installé le player DEBUG afin de les retourner au développeur lorsque l'on rapporte un bug. Etant donné que ces même erreurs interrompent complètement l'exécution du code, il donnera au développeur une précieuse information, bien plus utile que "ca ne fait plus rien"... Les versions debug des players sont disponibles à l'addresse: http://www.adobe.com/support/flashp...
Si vous utilisez le même navigateur pour la recette et votre usage quotidien, s'il s'agit de Firefox, vous pouvez installer la bien pratique extensions Flash Switcher. Vous pouvez ainsi utiliser une version debug pour une recette, et une version "normale" pour le reste...

4. Un proxy

Pour les applications communiquant avec un serveur, il peut être bien utile pour le développeur de savoir si un message réseau est parti, s'il est revenu, et quel est le contenu de ce retour. Fournir cette information lors de la déclaration du bug est un gain de temps évident pour sa résolution.
Pour ma part, j'utilise Charles: pas cher, entièrement en Java donc dispo pour toutes plateformes, il installe également un plug-in Firefox qui active/désactive le proxy facilement... Il existe aussi des extensions Firefox qui font cela, ainsi que d'autres logiciels standalone.
Un proxy permet également de voir si des ressources (images, fichiers XML ou autres...) on été demandées par le Flash, mais pas trouvées sur le serveur (erreurs 404 ou 500).

5. Une console de traces

Les développeurs insèrent souvent des messages de trace, ne serait-ce que pour vérifier que le code passe bien par là où il doit passer. Afin de lire ces messages, en plus du player DEBUG, il faut vous munir d'une console où les afficher. Elles ne manquent pas, que ce soit sous forme d'extension pour navigateur ou en standalone. Pour ma part, j'utilise SOS, développé par les excellents PowerFlasher (je suis un fan absolu de FDT).
Le testeur ne sais pas toujours à quoi correspondent les différentes traces, mais cela permet à un développeur de demander si tel ou tel message s'est affiché dans la console, cela permettant de clarifier et accélérer les échanges qui mèneront à la résolution du bug. Evidemment un message du type "EH MERDE, CA MARCHE PAS" qui apparait dans la console peut être pertinent à remonter au développeur!

III. Echanger avec le développeur

1. Avoir un outil de suivi de bugs

Il peut prendre plusieurs formes. La plus fréquente est un BugTracker. En ce qui me concerne, lorsque mes clients n'en ont pas, je leur propose Mantis. En PHP, simple d'accès et de configuration, il est pour moi un des meilleurs compromis efficacité/simplicité. De grosses structures utilisent souvent JIRA, pour ma part, je le trouve un peu nébuleux, mais il s'avère efficace lorsqu'il est bien configuré, et que le projet l'est également. J'ai également entendu dire beaucoup de bien d'un tracker en mode hébergé, nommé SifterApp.
Un BugTracker permet non seulement de remonter un bug au développeur, mais également de suivre toute son évolution: qui l'a reporté, les compléments d'information nécessaires, les captures d'écran, la résolution (ou non) de celui-ci, etc...
Lorsqu'aucun BugTracker n'est disponible, les remontées de bugs se font trop souvent sur un document Excel ou PowerPoint. Autant le dire tout de suite: C'EST LA PIRE RECETTE POSSIBLE!

sur Excel, aucune capture d'écran n'est possible, et à moins d'écrire une tartine difficilement lisible dans une case, il est compliqué de donner des infos détaillées sur le bug
sur PowerPoint, le bug est souvent une grosse capture d'écran, avec une flèche pointant vers le bug quand on a de la chance, suivie d'une phrase trop courte par manque de place

Dans les deux cas, il est surtout impossible ou extrêmement laborieux d'échanger avec le développeur. Cela se fait souvent par mail ou IM, avec pour référence "Le document du 17 Février, page 14", sachant que 2 documents similaires ont pu être échangés depuis, avec ou sans répétition des précédents.
Si ce support devait absolument être utilisé, certaines règles sont essentielles à respecter afin de limiter les dégats:

donner un numéro unique à chaque bug, et organiser le document de reporting par ordre de numéro de bug (facilite la recherche dans le document)
pour chaque document échangé, le dernier en date fait foi. Cela veut dire qu'il doit contenir tous les bugs restant à résoudre, ou qui nécessitent l'attention du dev.
chaque bug doit faire l'objet d'une description détaillée (voir ci-dessous), avec copie d'écran annotée si nécessaire.
mettre la date du document dans le nom du fichier, au format <année>_<mois>_<jour>: cela permet un classement alphabétique cohérent quand on affiche une liste de fichiers sur son ordi.

En l'absence de tracker, une option a été trouvée avec un de mes clients et elle s'avère limiter les dégats sous la forme d'une feuille de calcul sur GoogleDocs (ou tout autre outil de collaboration en ligne). Sans atteindre le confort, la puissance et donc l'efficacité d'un tracker, cela permet malgré tout une réactivité améliorée par rapport à un échange de mails, si le document est bien organisé et comporte toutes les infos nécessaire (voir ci-dessous).

2. Déclarer un bug

Il s'agit là de la partie la plus anodine, et en même temps la plus importante d'une recette. Afin d'optimiser la durée et le nombre d'échanges, un bug doit être déclaré de la manière la plus complète. Souvent, un BugTracker demande un certain nombres des informations utiles dans des zones de saisie dédiées, facilitant ainsi la clarté du bug. Dans tous les cas, il est nécessaire d'avoir pour chaque bug:

un numéro, trés important pour les échanges, il identifie de manière commune le bug, pour le testeur comme pour le dev. Il permet d'éviter les noms du genre "Le bug du bouton rouge qui cliquait pas comme il faut"
un titre clair et concis. Voire ci-dessus un exemple de nom à éviter!
une catégorie. Souvent, elle est liée à l'endroit ou à l'écran sur lequel se situe le bug. Quand ce champ n'est pas prévu, il peut apparaître sous forme de "tag" avant le nom du bug, par exemple: (Editeur de niveau) Bouton SAVE inopérant.
une description détaillée. Elle doit contenir les effets du bug: un bouton qui ne fait rien, un graphique qui ne s'affiche pas ou part en sucette, une couleur qui n'est pas la bonne, bref la différence entre le comportement attendu et le comportement effectif.
une priorité. Pour un développeur, un bug est un bug. Selon la méthode de travail qu'il utilise ou le mode de raisonnement qu'il suit, ses priorités peuvent être différentes des vôtres. Si vous avez besoin que certains soient résolus avant d'autres, faites le savoir.
une sévérité. Ca peut être "Bloquant", "Majeur", "Mineur", "Anecdotique", "Amélioration", etc...
un scénario. Une des parties les plus importantes. Le développeur doit savoir comment reproduire le bug avant de pouvoir le résoudre. Le testeur doit donc bien reconstituer l'ensemble des manipulations effectuées pour arriver à ce bug, quitte à reprendre le parcours depuis le lancement de l'application. A noter cette phrase tellement vraie: "Quand un chef de projet reproduit un bug, il est déçu car cela veut dire qu'il reste un bug. Quand un développeur reproduit un bug, il est content car cela veut dire qu'il va pouvoir le résoudre".
une reproductibilité. C'est la facilité que l'on a à reproduire le bug. Un testeur ne doit pas remonter un bug tant qu'il ne s'est pas battu bec et ongles pour le reproduire. La reproductibilité sera de type "Toujours", "Fréquent" ou "Non reproduit"... Les bugs relevant de cette dernière possibilité étant bien évidemment les plus difficiles et donc les plus longs à résoudre. Souvent d'ailleurs, si on arrive pas à le reproduire au bout d'un certain nombre d'essais, on le considère comme inexistant par la force des choses.
une cause probable. C'est là qu'interviennent les outils cités plus haut qui permettent au testeur de faciliter et donc d'accélérer le travail du codeur. Il peut s'agir d'un message réseau qui n'a pas eu de réponse, ou dont la réponse contient une erreur (message d'erreur PHP par exemple), d'une ressource non trouvée (image, fichier XML, etc...), d'un message d'erreur remonté par Flash (player DEBUG), ou simplement remonté par le codeur dans ses traces (console de trace).
un statut (voire ci-dessous).

3. Suivi d'un bug

Afin que tout le monde parle le même langage durant la recette, pouvoir suivre les bugs est important, ne serait-ce que pour éviter des échanges informatifs superflus. Le suivi donnera non-seulement un état des lieux de la recette, mais évitera aussi, par exemple, de redéclarer un bug que l'on pensait résolu, alors que le développeur n'a même pas commencé à le regarder, ou qu'il l'a résolu et pas livré... Ce suivi se fait généralement par deux moyens:

a. Un statut pour le bug

Il permet de savoir quel est l'état de traitement de celui-ci. Les états courants, dans l'ordre classique, sont les suivant:

déclaré. Le bug vient d'être déclaré par le testeur.
accepté / refusé / incomplet. Le développeur a lu le bug. Il le prend en charge, le refuse en expliquant la raison (ça peut aller de "Mauvaise interprétation du CDC" - les testeurs ne sont pas toujours les demandeurs/concepteurs - jusqu'à "Hors de périmètre de la mission" - dans le cadre d'une amélioration par exemple - ou une impossibilité de reproduire, ou qu'il s'agit d'un doublon avec le bug N°__), ou bien il demande plus d'informations pour pouvoir ensuite accepter / refuser le bug.
en cours. Dans certain process, le développeur notifie le testeur quand il commence à travailler sur le bug. Très honnêtement, il est rare qu'un dev utilise ce statut, ne serait-ce que parce qu'il oublie de le faire...
résolu. Le développeur notifie le testeur qu'il a résolu le bug, mais que ce fix n'est pas encore deployé sur la plateforme de test.
deployé. La résolution du bug est disponible sur l'environnement de test.
retourné. Le bug a été testé, mais pas considéré comme résolu. Le testeur retourne alors ce bug au développeur, avec les informations détaillées qui lui font dire qu'il n'est pas encore fixé.
fermé. La résolution du bug est validée par le testeur.

L'état d'un bug peut-être notifié par un code couleur, facilitant ainsi la vue d'ensemble d'une recette par ses différents intervenants. Cela est encore plus utile dans le cadre d'un document de reporting qui n'est pas un tracker.
Le processus de travail est principalement centré sur ce statut, car il permet à chaque partie de savoir où il doit intervenir pour faire avancer la situation du bug: les testeurs doivent intervenir sur les statuts "incomplet" (pour le complèter) et "deployé" (pour le tester), les devs sur "déclaré" (pour l'accepter), "accepté" (pour le traiter), "résolu" (pour le déployer) et "retourné" (pour l'accepter).

b. Des commentaires

Cela constitue la colonne vertébrale du bug et représente la partie "échanges" du bug. Dans le cadre d'un BugTracker, les commentaires de chaque intervenant permettent de retracer la vie du bug, et donc de savoir ce qui a mené à son état actuel. En dehors d'un tracker, il s'agit le plus souvent de mails, et ce qui pose problème alors et qu'on aborde souvent plusieurs bugs dans un même mail. Si les échanges par mails étaient le seul moyen, essayez de ne faire qu'un mail par bug, et de spécifier dans le titre de celui-ci le numéro du bug (par exemple (BUG #__) Demande d'infos), permettant ainsi le regroupement de plusieurs mail parlant du même bug, pour ainsi reconstituer cette colonne vertébrale.

IV. Conclusion

Donner la touche finale à un projet n'est pas évident.
La livraison peut se révéler parfois un véritable parcours du combattant avant un déploiement en production, et les conseils ci-dessus peuvent aider à la rendre bien plus douce, et surtout rendre l'échange testeur/développeur bien plus qualitatif, ce qui permet de préserver les nerfs, le temps et donc l'argent de tout le monde, pensez-y!

Déformation de vidéo

-Alexandre LEGOUT aka LAlex- — Mon, 14 Sep 2009 02:37:00 +0200

J'ai découvert récemment le clip de la chanson "Unintended" de Muse.
Hormis la beauté de la chanson, j'ai beaucoup accroché sur l'effet donné à la vidéo dans le clip.

Bon, ben il ne restait plus qu'à le reproduire dans Flash...

Bon alors déjà, le principe.
En observant un peu, c'est assez simple: plus on descend vers le bas de l'image, plus les pixels sont anciens...
En gros, l'image se renouvelle par le haut, ligne par ligne, au fur et à mesure. Il suffit donc de garder en mémoire les anciennes images, et d'afficher pour la première ligne, la première ligne de l'image actuelle, sur la deuxième, la deuxième ligne de l'image à t-1, etc...

Ensuite, s'agissait de trouver une vidéo sur laquelle l'effet rendait bien. En gros, il faut une partie d'image fixe, et une partie qui bouge lentement sinon c'est moche.
Et donc au final, j'ai fait une vidéo rapide de porte qui s'ouvre depuis ma petite maison de campagne, et voilà! (cliquez sur l'image pour voir tout çà)

Et comme je sais que vous êtes joueurs, je vous ai même fait une version ou qu'on peut le faire avec la webcam!

Et bien sûr la classe, qui hérite de Bitmap pour être plus pratique!

package com.lalex.unin {

        import flash.display.Bitmap;

        import flash.display.BitmapData;

        import flash.events.Event;

        import flash.geom.Point;

        import flash.geom.Rectangle;

        import flash.media.Video;



        /**

         * @author lalex

         */

        public class UnintendedVideo

                extends Bitmap {



                // Targeted video

                private var video : Video;

                

                // Time after capture has been stopped

                private var time:int = 0;

                

                // Bitmap datas

                private var datas : Array;



                public function UnintendedVideo(vdo : Video) {

                        video = vdo;

                }



                public function start() : void {

                        bitmapData = new BitmapData(video.width, video.height);

                        bitmapData.draw(video);

                        

                        time = 0;

                        datas = [bitmapData.clone()];

                        refresh();

                        addEventListener(Event.ENTER_FRAME, samplingEnterFrameHandler);

                }

                

                public function stop() : void {

                        removeEventListener(Event.ENTER_FRAME, samplingEnterFrameHandler);

                        addEventListener(Event.ENTER_FRAME, endingEnterFramehandler);

                }

                

                private function endingEnterFramehandler(event : Event) : void {

                        //If still ending, duplicate the previous image

                        if (time++ < bitmapData.height) {

                                datas.push(datas[datas.length-1]);

                                refresh();

                        

                        //If last image is fully displayed, stop handling enter frame event

                        } else {

                                removeEventListener(Event.ENTER_FRAME, endingEnterFramehandler);

                        }

                }



                private function samplingEnterFrameHandler(event : Event) : void {

                        var newBitmapData:BitmapData = new BitmapData(video.width, video.height);

                        newBitmapData.draw(video);

                        datas.push(newBitmapData);



                        refresh();

                }



                private function refresh() : void {

                        var curY:int = -1;

                        var maxY:int = bitmapData.height;

                        

                        var curDatas:Array = datas.concat();

                        

                        var rect:Rectangle = new Rectangle(0, 0, bitmapData.width, 1);

                        var pnt:Point = new Point(0, 0);



                        bitmapData.lock();

                        

                        

                        while(++curY < maxY) {

                                var last:Boolean = false;

                                var curData:BitmapData = curDatas.pop();

                                rect.y = curY;

                                

                                //If there's not enough history, let's draw to the bottom

                                if (curDatas.length == 0) {

                                        rect.height = maxY - curY;

                                        last = true;

                                }

                                

                                pnt.y = rect.y;

                                bitmapData.copyPixels(curData, rect, pnt);

                                if (last) break;

                        }

                        

                        

                        bitmapData.unlock();

                        

                        // Keeping more history than height is useless and cost memory

                        datas = datas.slice(-bitmapData.height);

                }

        }

}

Oui bon, pour un retour aprés autant de silence, j'aurais pu faire plus pointu je vous l'accorde...
Mais j'ai du bon thème a développer, reste à trouver le temps, et la motivation (quand on passe son temps la tête dans le code, pas évident d'y passer son temps libre non plus...)

MonBeauSapin.org

-Alexandre LEGOUT aka LAlex- — Mon, 17 Nov 2008 16:35:00 +0100

Ne parlons pas toujours de code... et pensons aux autres.

Etant fan de BD, et donc accrocs aux blogs BDs depuis un certain nombre d'années maintenant, j'ai eu part de cette délicieuse initiative de Pénélope Jolicoeur: monbeausapin.org. Elle a ainsi rameuté de nombreux et talentueux dessineux pour créer un blog donc l'audience se transformera en dons à la croix rouge, qui s'en servira pour acheter des cadeaux de Noël aux enfants qui ne peuvent pas en avoir faute de moyens.

J'aime l'idée, donc si je peux m'y associer en vous la faisant découvrir tant mieux!

Adobe CS4, ou le vol fait au vieux continent (MAJ)

-Alexandre LEGOUT aka LAlex- — Tue, 23 Sep 2008 12:24:00 +0200

Ça y est, les suites Adobe CS4 sont annoncées, pour fin-Octobre en Anglais et mi-Décembre.
Plein de nouveautés qu'elles sont bien, mais je ne vais pas faire duplicata du site Adobe.

Par contre, la Production Premium (exemple pas au hasard, c'est celle que je vais acheter) se voit passer de 1699dollars (soit aujourd'hui 1156euros) à 1899eurosHT pour la traversée de l'Atlantique. Au final, les européens paient 60% de plus (sans compter la TVA): autant dire que c'est carrément du vol qualifié!

Je cherche donc s'il existe une astuce légale pour l'acheter aux états-unis...

MAJ: Il semblerait qu'il ne soit absolument pas illégal d'acheter les produits Adobe aux États-Unis, dixit le service client Adobe lui-même (concernant la suite CS3 en tout cas, déjà honteusement chère en Europe à l'époque). Cela empêche seulement de disposer du support pour l'Europe.
Toujours selon ce même service client, la différence de prix est due aux garanties complémentaires accordées à l'Europe, et aux frais de traduction (j'ai bien fait la comparaison plus haut des versions anglaises, donc aucune traduction).

Reste à voir si c'est toujours valable pour la suite CS4.

Pratiques Flex (1/?) : les bindings

-Alexandre LEGOUT aka LAlex- — Wed, 03 Sep 2008 15:41:00 +0200

Les bindings sont un aspect de Flex bien séduisants car il permettent de refléter automatiquement la modification du contenu d'une variable vers une autre. Seulement, lorsqu'ils sont utilisés intensément, ils peuvent également devenir un goulot d'étranglement en terme de performances.

Pour éviter cela, la solution est plutôt simple, et nécessite de savoir comment fonctionne la balise [Bindable] et comment elle est utilisée par le framework Flex...

Les bindings fonctionnent grâce à des meta-balises qui sont interprétés par le compilateur Flex (ou plutôt le traducteur MXML/AS3). Cette meta-balise va servir à dire quel évenement va signaler le changement de la valeur d'une propriété.

En prenant un exemple simple:

<mx:Button id="enableButton" toggle="true" />
<mx:TextInput id="textInput" enabled="{enableButton.selected}" />

Dans cet exemple, si le bouton est enfoncé (selected=true), la zone de saisie sera activée, et si le bouton est relevé (selected=false), la zone de saisie sera désactivée. Cela se fait grâce a un binding, qui met a jour la propriété enabled du champ de saisie lorsqu'un événement signale que la propriété selected du bouton à été modifiée. Tout cela est géré automatiquement par Flex car la propriété selected de la classe Button est déclarée comme étant [Bindable].

Il est possible de créer ses propres propriétés [Bindable], de manière plus ou moins assistée par Flex:

[Bindable]

Le traducteur MXML/AS3 (même si la meta-balise est dans une classe AS3 et non pas un MXML) va créer à la place un getter/setter qui va dispatcher un événement standard pour signaler le changement de valeur. Cet événement sera un PropertyChangeEvent de type PropertyChangeEvent.PROPERTY_CHANGE. Vous verrez ci-aprés un exemple de code AS3 avant (avec son [Bindable]) et aprés.

Avant

[Bindable] 

protected var mc:MessageController;

Aprés

/**

 * generated bindable wrapper for property mc (protected)

 * - generated setter

 * - generated getter

 * - original protected var 'mc' moved to '_3478mc'

 */



[Bindable(event="propertyChange")]

protected function get mc():MessageController

{

    return this._3478mc;

}



protected function set mc(value:MessageController):void

{

    var oldValue:Object = this._3478mc;

    if (oldValue !== value)

    {

        this._3478mc = value;

        this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this, "mc", oldValue, value));

    }

}

[Bindable(event="eventName")]

Lorsque l'on précise dans la méta-balise le nom de l'événement qui sera diffusé lors d'un changement de valeur de la variable, le traducteur MXML/AS3 n'interviendra pas sur le code: le framework se contentera d'écouter l'événement précisé pour mettre à jour les variables de destination. C'est donc au développeur de diffuser lui-même l'événement dans son code, que ce soit dans le setter de la propriété, ou n'importe quel méthode qui va affecter la propriété. On voit d'ailleurs dans l'évenement précédent qu'un [Bindable] est transformé en [Bindable(event="propertyChange"].

Étant donné qu'il n'est pas possible d'utiliser de variable dans les meta-balises, j'ai également pris l'habitude d'utiliser systématiquement des chaînes de caractères pour le type de mes événements: étant donné qu'à priori on n'utilise nulle part ailleurs dans le code l'écoute de cet événement, ça permet de différencier le dispatch d'un événement destiné à être écouté et celui d'un événement destiné au binding... J'ai également pris l'habitude de créer pour chaque binding "à la main" une méthode notifyMonBinding qui dispatche l'évenement qui va bien.

Les performances

Voyons maintenant comment Flex se sert des bindings: un BindingManager (classe non documentée) va écouter les différents événements spécifiés dans les balises [Bindable] et lorsqu'elle en reçoit ce fameux événement, elle va relire la propriété concernée et l'appliquer à tous les endroits où elle est utilisée en tant que source.

On peut voir facilement ce qu'il se passe si on utilise partout uniquement la balise [Bindable] simple.
Imaginons une classe disposant de 10 propriétés [Bindable] (sans event spécifié). Imaginons également que ces dix propriétés sont utilisées deux fois chacune en tant que source via la binding. Lorsqu'une propriété va changer, un événement PropertyChangeEvent.PROPERTY_CHANGE va être diffusé pour signaler ce changement. Hors, chaque propriété étant liée au même événement (propertyChange, le type d'évenement généré par défaut), Flex va faire appel aux getter de chaque propriété, et appliquer les modifications (qui en l'occurrence n'ont pas eu lieu sur 9 d'entre elles) sur la totalité des 20 bindings, avec toute la procédure qui s'ensuit, soit le calcul du layout et le dessin des différents éléments affectés. Pour ne pas être alarmiste non plus, la plupart des setters bien fait évitent de provoquer une action si la nouvelle valeur qu'on lui affecte est la même que l'ancienne valeur, et le processus d'invalidation permet de ne redessiner qu'une fois un composant dont on change plusieurs propriétés.

C'est pourquoi pour soulager l'application, il est très important de:

définir ses propriétés de binding sous la forme [Bindable(event="eventName")]
définir un événement de binding différent par propriété (ou par groupes de propriétés analogues)

Conclusion

Les bindings sont pratiques et sexys: par une simple affectation dans un fichier XML (ou création d'un binding avec BindingUtils), on arrive a faire interagir deux entités Flex facilement. Mais attention à ne pas provoquer une cascade d'instructions lourdes à l'exécution sur une action bénigne! C'est pour cela qu'il est important de savoir le fonctionnement du binding et ses conséquences.
Parfois, s'en tenir au schéma EventDispatcher.addEventListener est largement suffisant

Flex et/ou les frameworks: pas tout le temps, pas n'importe comment

-Alexandre LEGOUT aka LAlex- — Fri, 29 Aug 2008 13:07:00 +0200

La demande est forte en ce moment sur le développement Flex.

Flex a cet espèce d'aura de "vrai outil pour les pros":

de ceux qu'on confie à des SSII, blindées d'ingénieurs qu'il font du code sérieux vous comprenez....
de ceux que les freelances proposent pour faire plus expert, parce qu'ils ont déjà affiché un item qui change quand on sélectionne une entrée dans un Combo Box, et qu'ils n'ont pas envie de recoder un bouton dans un site liquide redimensionnable...

Si j'écris ce billet, c'est parce que je me retrouve tout à tour devant ces deux situations.

Seulement voilà, ce type de développement Flex, lorsqu'il a besoin d'être repris par un développeur autre que le développeur d'origine, peut poser des problèmes différents selon celle des deux situations citées plus haut qui se présente - la troisième, qui a priori ne pose aucun problème, étant le développement de l'application par un codeur Flex expérimenté pas trop attaché aux usines a gaz

Le développement par une SSII

La plupart des ingénieurs en développement sont formés sur des langages type Java ou .NET. Quand je me parle à moi-même (et oui, ca m'arrive), j'appelle ca des langages "non-visuels". Ces langages disposent d'un framework extrêmement développé, sans compter le nombre de frameworks annexes(type Spring, MINA, etc..), utilisés par tellement de monde que c'est comme s'ils étaient natifs au système et disposent d'un support énorme par la communauté.

Ces développeurs reproduisent naturellement les mêmes mécanismes quand ils se retrouvent dans un environnement Flex et utilisent le premier framework qui passe et qui ressemble à ce dont ils pensent avoir besoin. Je dis bien ils pensent, car l'utilisation de ces frameworks revient souvent à compliquer une architecture qui n'en a pas besoin. Cela permet la plupart du temps au développeur de retrouver un environnement de développement qui lui est familier concernant le MVC, ou l'utilisation de connecteurs plus "standards" (j'entends par là standard à leur langage de prédilection) pour la récupération de données (WebService la plupart du temps).
La formation ou le transfert de compétence étant le plus souvent effectuée par la première personne qui a initié le projet, cela ne semble poser de problème à personne. Sauf si l'on pense au fait qu'une fois le produit livré, ça laisse difficilement la possibilité au client final de confier la maintenance ou l'évolution du produit à un autre prestataire, a moins que le doc soit vraiment extrêmement complète - ce qui, avouons le, est très rare: une bonne doc (ASDoc + doc rédigé) prenant beaucoup de temps, ce que peuvent rarement se permettre les prestataires s'ils veulent respecter leur délais sans facturer la partie documentation.

Le problème là n'est pas lié à Flex, mais bien à la philosophie SSII (la plus répandue en tout cas): des ingénieurs parlent aux ingénieurs. Et étant donné que Flex commence à être vu, comme je le disais, comme un outil "serieux", les SSII sont de plus en plus sollicitées sur cette technologie, mais pour des clients "web", dont la politique n'est pas de se retrouver pieds et mains liées à cause de choix technologiques du prestataire.

Les prestataires peu expérimentés

Suite à un assez vieux post, j'ai été considérés par certain comme un élitiste casseur de débutants, alors que le message que je désire faire passer est qu'il faut seulement essayer de faire ce que l'on sait, et apprendre ce que l'on ne sait pas.
En tant que codeur AS2, mon passage à l'AS3 s'est fait via Flex2, avant que ne sorte Flash CS3. J'ai eu l'immense chance à ce moment là de faire partie d'une entreprise pour laquelle le projet que je devais réaliser avait un besoin impératif d'une conception propre, quitte à passer beaucoup de temps à étudier le framework Flex avant de commencer à coder l'application. J'ai donc passé beaucoup de temps en R&D avant de passer en production, ce qui m'a permis d'apprendre beaucoup de mes tests et erreurs.

Flex a ce côté séduisant du fait que pas mal de choses peuvent sembler se faire toutes seules: positionnement, binding, navigation, composants... Mais il faut malgré tout en connaître le fonctionnement précis pour, par exemple:

ne pas utiliser une gestion des states avec manipulation de la display list là où une ViewStack est plus indiquée...
ne pas utiliser un binding là ou un simple événement suffit...
ne pas utiliser un (Binding) là où un (Binding(event="..")) sera bien plus performant... (les crochets passent mal sur Dotclear)

C'est pourquoi le seul conseil que je peux donner ici est de ne pas se lancer dans un projet qui est au delà de ses compétences actuelles. L'auto formation est une excellente chose et je ne jure que par elle, mais pour un freelance, c'est selon moi un manque de respect au client que de vendre une prestation qui a 9 chances sur 10 d'être plus ou moins bancale (par exemple, je préviens systématiquement mes clients si je n'ai pas la compétence/expérience sur une techno précise, quitte a refuser le contrat).
Cela en plus complique la tache d'un éventuel autre prestataire qui aurait besoin d'assurer la maintenance ou l'évolution du produit: c'est donc aussi pas très cool pour les collègues...
Je parle bien ici précisément de Flex: rien a voir avec le fait d'accepter de coder un diaporama sans en avoir jamais fait: il s'agit bien là d'un framework complet et de toute la philosophie de développement qui lui est attaché, ainsi que de ses outils.

Les frameworks en général

Beaucoup de développeurs de haut-niveau se sont essayés, souvent avec succès, au développement d'un framework open-source... Rappelons d'ailleurs que Flex n'est "qu'un" framework AS3, auquel est associé un "traducteur" MXML->AS3. Ces frameworks permettent de faire plus de choses, ou d'encapsuler un certain nombre de comportements communs. Que ce soit une implémentation du MVC, une couche d'accès aux données ou tout autre fonctionnalité, ces frameworks disposent pour chacun d'une philosophie de développement propre à son concepteur ou à ceux qui ont adhéré au framework.

Ce qui veut dire également que ceux qui n'ont pas adhéré au framework se voient affronter un mode de développement complètement différent de la technologie qu'ils pratiquent, pour laquelle ils se sont déjà formés. Alors s'il s'agit d'un easyMVC (7 classes) ou d'un cairngorm(22 classes), ca peut encore aller. Mais s'il s'agit d'un servebox foundry (121 classes en comptant commons+foudry+toolbox), d'un VEGAS (171 classes) ou autre lowRIA (265 classes), ça commence a faire usine à gaz...
Et quels que soit les avantages et inconvénients de chacun de ces frameworks, il est à chaque fois obligatoire de se conformer à la philosophie de développement de chacun sous peine de perdre tout l'intérêt des les utiliser.

Bref, je dirais que l'utilisation d'un framework "propriétaire" dans le cadre d'un framework agence ou de projets perso peut être une excellente chose: il peut correspondre ainsi à un goût pour tel ou tel mode de travail, ou devenir une politique d'entreprise dans le cas des agences. Mais pour un prestataire qui sait que ce projet va lui échapper, je pense que ce n'est certainement pas une bonne idée: non pas pour son propre travail, mais pour ceux qui peuvent être amenés ensuite à intervenir sur le projet.

Et moi en tant que prestataire aujourd'hui, faudrait-il que je maîtrise l'ensemble des frameworks les plus courants pour pouvoir accepter les missions que l'on veut me confier? Ce serait l'idéal, mais travail+R&D+sommeil sont rarement tous les 3 compatibles!
Et faire de la R&D pour maîtriser un framework qui ne me permet pas de faire plus de choses que ce que j'aurais fait sans, je dois avouer que ça me rebute un peu...

Et puis quand je livre un client, je fais systématiquement en sorte qu'il ne soit pas "verrouillé". C'est avec j'avoue un peu de fierté que je dis en général à mes clients qu'ils peuvent faire appel a n'importe quel prestataire compétent dans la technologie (Flash ou Flex) pour prendre la suite, sans requis supplémentaires. C'est bien plus pratique pour tout le monde: le client ne se sent pas prisonnier d'un prestataire, et je ne culpabilise pas de ne pas pouvoir assurer la maintenance si mon emploi du temps ne me le permets pas car je sais qu'un autre prestataire pourra le faire facilement.

Pour finir, je rappelle que les Design Patterns sont une solution générique pour un problème précis, généralement pour des problèmes que l'on rencontre souvent dans du développement Objet. Cela veut aussi dire qu'il ne sert à rien de les utiliser si le problème ne se pose pas! Un MVC avec une seule vue et un seul contrôleur est par exemple totalement inutile, et pourtant j'en vois si souvent... Car évidemment, quelqu'un qui utilise un framework qu'il aime pratiquer en vient à l'utiliser systématiquement, même quand il n'est pas nécessaire...

Si j'ai le temps et la foi suffisante, j'essaierai de faire un ticket sur un ensemble de pratiques personnelles en Flex, qui se sont avérées être efficaces et productives sur le terrain, qui grâce aux commentaires pourraient être débattues et enrichies.

Tips: Angles et géométrie

-Alexandre LEGOUT aka LAlex- — Fri, 20 Jun 2008 13:45:00 +0200

Je suis actuellement en train de me bruler les neurones sur un éditeur, permettant entre autres de modifier un visuel à la souris. De quoi devoir replonger dans nos bonnes vieilles notions de trigo.
J'en profite donc pour donner ici 2-3 astuces

Rotation d'un point

Pour passer d'un point (x, y) à un autre (x', y') en lui appliquant une rotation d'angle a, l'équation est la suivante:

        x' = x*cos(a) - y*sin(a)
        y' = x*sin(a) + y*cos(a)

Ce qui nous donne un petite méthode AS3:

public function rotatePoint(point : Point, angle : Number, isRadian : Boolean = false) : Point {

        if (ang == 0) return point.clone();

        var radAngle : Number = isRadian ? angle : angle * Math.PI / 180;

        var angleCos : Number = Math.cos(radAngle);

        var angleSin : Number = Math.sin(radAngle);

        return new Point(point.x * angleCos - point.y * angleSin, point.x * angleSin + point.y * angleCos);

}

Notez que l'on peut passer cette méthode un angle en degré (par défaut) ou en radians.

Angle fait par un vecteur

L'AS3 nous fournit une méthode toute prête: Math.atan2. Elle prend en paramètre les coordonnées du vecteur (j'utilise un point dans l'exemple) et retourne un angle en radian (d'où le flag isRadian de la méthode précédente).
Notez bien que la coordonnée 'y' est le premier argument (chez moi, FDT m'affiche 'x' en premier, je me suis fait avoir au début)

var vector : Point = new Point(mouseX, mouseY);

var angRadian : Number = Math.atan2(vector.y, vector.x);

Normaliser un angle

Selon les besoins, il peut être nécessaire d'utiliser systématiquement un angle entre 0 et 360, ou entre -180 et 180. Avec les modulos, cela peut se faire facilement:

// Get a random number between -1500 and 1500

var angle : Number = Math.random() * 3000 - 1500;



// Normalize angle between 0 and 360

var angleIn360 : Number = ((angle % 360) + 360) % 360;

// Normalize angle between -180 and 180

var angleIn180 : Number = ((angle % 360) + 540) % 360 - 180;

---

Voilà pour les ch'tites astuces de l'oncle LAlex

Do you speak english? Yes, I speak dummies english...

-Alexandre LEGOUT aka LAlex- — Mon, 26 May 2008 20:03:00 +0200

Dans la famille "J'me la pête international", je doit être le fiston!
Eh oui, je cède finalement aux sirènes de la langue de Shakespeare (enfin, il doit se retourner dans sa tombe un peu, quand-même) et ouvre mon ch'tit blog en Anglais : ApplicationDomain.net

Le but est de pouvoir échanger facilement avec plus de monde, et de la jouer moins "nombril", parce qu'il faut bien le dire, au vu de la fréquence et du contenu de mes dernières contributions: je baisse!
Donc, en terme de contenu, je prévois de l'AS3 uniquement: des articles sur certains modes de programmation, des outils (IDE, Workflow, etc...), du code bien sûr mais a priori plus complet que de simples tips, du Flex, du AIR, etc...
J'espère arriver à me limiter à du plus abouti que ces derniers temps: en gros, j'évite les liens vers les articles que tout le monde a lu 10 fois, les news qu'on a lu 100 fois, la demi-ligne de code que j'ai pondu la veille, etc...

Un seul petit article est là pour l'instant, sur l'installation de FDT pour le Flash Player 10.
Je n'ai trouvé qu'un seul article en Russe traduit via Google translations, et qui en plus utilise le playerglobal.swc d'une ancienne beta de Flash CS4 au lieu de celui, évidemment plus récent, des nightly builds de Flex 4...

Pour ce qui est du contenu restant sur ce blog (ne fuyez pas tout de suite), je continuerai a proposer les astuces de code (dont je suis moi-même friand chez les autres), le PHP, les coups de gueule voire eventuellement des liens vers les sites qui m'ont plu (mais ca HebiFlux le fait quand-même mieux que personne), et bien sur des liens vers les articles super top de ApplicationDomain... :p

Et pour ceux qui vont me sortir que le theme ressemble vachement a celui de l'ami Francis BOURRE, je répondrai: oui!
J'avais fini la modification de ce thème 2 jours avant qu'il ne relance tweenpix, et je n'ai pas eu la foi suffisante pour chercher autre chose...

Flash Player Security Update

-Alexandre LEGOUT aka LAlex- — Thu, 10 Apr 2008 16:39:00 +0200

Pour info, la nouvelle version du Flash Player, orientée sécurité, est maintenant disponible. Estampillée Flash Player 9.0.124, elle fixe pas moins de 7 failles, dont celle qui avait permis à un pirate de prendre possession d'un système OSX.

Dnas la même lignée, Adobe AIR 1.0.1, qui intégre ces même corrections, est également disponible.

JSFL mon amour...

-Alexandre LEGOUT aka LAlex- — Mon, 31 Mar 2008 17:30:00 +0200

L'équipe d'envrac avait prévenu, mais je suis en train de doucement glisser vers la dépendance au JSFL...

Un p'tit langage qui permet de scripter l'IDE et ainsi de raccourcir drastiquement les taches répétitives, c'est quand-même du pain béni pour peu qu'on prenne le temps de s'y pencher. Pas encore interessé aux panneaux "custom", j'ai pondu quelques petites déclinaisons d'un script inspiré par une ancienne collègue - si tu te reconnais, un paquet de Carambars - et qui facilite grandement l'intégration timeline/code (un petit article prévu la dessus dés que je lève un peu la tête des mes projets et que je me défénéantise en ce qui concerne ce blog).

Bref, ceci est un ensemble de 4 scripts JSFL qui font le tour des instances nommées dans un clip, et affiche dans le panneau de sortie les déclarations AS3 de celles-ci : je ne parlerais pas ici de la quasi obligation morale qui nous incombe à tous de décocher la case "Déclarer automatiquement les instances etc..." si vous êtes pas des trouillards... :p

Plusieurs déclinaisons donc:

"Lazy Timeline Variables": affiche les déclarations sour forme public var monClip:MonClip;
"Lazy Timeline GetSet": même chose, mais déclare les variables en mode private préfixées avec un underscore, ainsi que les getter/setter publics corrspondant (pratique si vous voulez détecter l'ajout d'un clip à la timeline, sans attendre un Event.ADDED puis un Event.RENDER)...
"Lazy Selected Variables"/"Lazy Selected GetSet": même chose que les deux précédents, mais uniquement pour les instances sélectionnées dans l'IDE: pratique quand on a déjà utilisés les précédents, mais qu'on a rajouté une instance entre temps...

A savoir que chacun de ces scripts:

Utilise les classes renseignées dans l'IDE: en gros, si les éléments ne sont pas exportés pour AS dans la bibliothèque, c'est MovieClip ou SimpleButton qui seront utilisés, sinon, c'est soit la BaseClass, soit la classe elle-même qui seront utilisées.
Copie ces déclarations dans le clipboard, pour qu'il n'y ai plus qu'un "coller" à faire dans le vrai environnement de développement que vous utilisez certainement!

Ces scripts se décompressent dans le répertoire ~/Library/Application Support/Adobe/Flash CS3/en/Configuration/Commands (sur Mac, vous trouverez l'équivalent sur Windows), et deviennent accessibles depuis Flash dans le menu "Commandes"...

Pour le petit exemple de "Lazy Timeline GetSet" pour 2 boutons:

/* JSFL Example*/

                // Private timeline properties



                private var _upButton:MinimalButton;

                private var _downButton:MinimalButton;



                // Public timeline getters/setters



                public function set upButton(displayObject: MinimalButton) : void {

                        _upButton = displayObject;



                        // Rajouté a posteriori

                        _upButton.addEventListener(MouseEvent.CLICK, upButtonClickHandler);

                }

                

                private function upButtonClickHandler(event : MouseEvent) : void {

                        trace("Up clicked")

                }



                public function get upButton() : MovieClip{

                        return _upButton;

                }



                public function set downButton(displayObject: MinimalButton) : void {

                        _downButton = displayObject;



                        // Rajouté a posteriori

                        _downButton.addEventListener(MouseEvent.CLICK, downButtonClickHandler);

                }

                

                private function downButtonClickHandler(event : MouseEvent) : void {

                        trace("Down clicked")

                }



                public function get downButton() : MovieClip{

                        return _downButton;

                }

Tous ces zoulis scripts sont téléchargeables: LazyScripts.zip

Les composants, c'est pour les graphistes!

-Alexandre LEGOUT aka LAlex- — Tue, 18 Mar 2008 20:09:00 +0100

... qu'y disent! Eh ben, non madame, c'est bien pour les codeurs aussi!

Prenons totalement au hasard un exemple de petite classe utilitaire de debug pour afficher le framerate et la mémoire utilisée: et bien c'est quand-même bien plus pratique de déposer un petit composant sur sa scène plutôt que de se frapper un 'new FramerateViewer()' dans une DocumentClass quand-même... Et ca se fait tout aussi vite!
Et que même si on veut mettre une icone et tout et tout, ca prend bien 2mn de plus!

Allez, l'exemple en pratique: Framerate.swc

PS: Merci famfamfam pour l'icone

Des fois, on s'demande....

-Alexandre LEGOUT aka LAlex- — Mon, 17 Mar 2008 17:28:00 +0100

1046: Type was not found or was not a compile-time constant: MovieClip.

No comment...

Flex 3, AIR 1.0, etc...

-Alexandre LEGOUT aka LAlex- — Mon, 25 Feb 2008 12:58:00 +0100

Ca y est! Les blougs du monde entier l'ont déjà dit, le Flex 3 SDK, première release OpenSource de Flex et Adobe AIR, la saint graal gratuit des développeurs de RDA (Rich Desktop Applications, bande d'inclutes), sont sortis!

Tout ca semble extremement prometteur.
Je ne vais pas faire la liste des features, mais juste mettre le doigt sur un enorme point positif de cette release: la disponibilité des sources de la classe WebService de Flex! Le passage a l'AS3 avait tout simplement zappé cette classe dans Flash CS3.

Maintenant, reste à voir s'il est possible de se servir de celle-ci sans se trimbaler la moitié du framework Flex...
Si je trouve le temps de faire des tests, j'en donnerai le resultat ici...

Pathfinding A-star sur bitmap

-Alexandre LEGOUT aka LAlex- — Thu, 21 Feb 2008 20:02:00 +0100

L'algorithme A* (A-star) connait de nombreuses implémentations. La plupart utilisent une grille (tableau à deux dimensions) en tant que carte. Etant à la base des jeux "tile-based", celles-ci suffisent la plupart du temps à la grande majorité des jeux. Seulement cela impose un certain nombre de contraintes, notamment en terme de dimensions des "obstacles", mais aussi en terme de performances: l'algorythme se basant sur des noeux (nodes), une grille de 40/40 offre 1600 cases (maximum, l'A* n'étant pas exhaustif), ce qui est déjà bien important...

J'ai voulu essayer de me baser plutôt sur un bitmap, simple (pour l'instant), une couleur étant celle du sol, l'autre celle des obstacles :

Ma jolie video

En gros, l'appel de méthode utilisé ici est

var bmp:BitmapData = new BitmapData(400, 400);



// Génération d'un bitmap aléatoire: fillRect aléatoires, etc...



var finder:BitmapAStar = new BitmapAStar;

var path: /*Point*/ Array = finder.findPath(bmp, new Point(5, 5), new Point(395, 395));

L'A* n'a évidemment pas été le plus compliqué à mettre en oeuvre, mais c'est bien l'analyse et le découpage de ce bitmap qui ont été difficiles à mettre en place. Beaucoup de choses restent à faire malgré cette démo fonctionnelle, notamment l'optimisation du placement des "portes" (ronds blancs sur l'affichage "debug"), et des trajectoires (je pense notamment faire un lissage du chemin à parcourir). D'autres fonctionnalités peuvent être envisagées, comme la gestion des altitudes (terrain en pente, ou les falaises qui seraient des portes à sens unique - qu'on peut sauter mais pas grimper) ou des types de terrain (un malus associé à chaque couleur par exemple).

Dans le plus ardu, on peut aussi imaginer un découpage des formes non rectangulaires (polygones ou courbes).

Une fois cleanées (l'API notamment) et optimisées, je mettrai les sources à disposition sur ce blog...

Options d'une méthode "Array-like"

-Alexandre LEGOUT aka LAlex- — Wed, 20 Feb 2008 19:57:00 +0100

Un appel à une méthode paut parfois avoir besoin d'un certains nombre "d'options", comme c'est le cas pour la méthode Array.sort par exemple.

Il existe alors plusieurs possibilités, la plus simple étant de proposer un certain nombre de paramètres booléens facultatifs, avec des valeurs par défaut. Le problème est tout d'abord que cela alourdit considérablement le code, mais aussi que rajouter une option supplémentaire modifie la signature de la méthode: si on travaille avec des interfaces, bonjour la galère).

Bref, il existe aussi la possibilité de passer un seul entier, qui sera la somme de puissances de 2. En gros, cela permet d'avoir, en binaire, une suite de 0 et de 1, chacun correspondant à l'activation (ou pas) d'une option.
Voyons comment cela fonctionne concrètement avec l'exemple de Array.sort

Les différentes options de cette méthode ont toutes une valeur numérique puissance de 2:

Array.CASEINSENSITIVE: valeur 1 (2 puissance 0)
Array.DESCENDING : valeur 2 (2 puissance 1)
Array.UNIQUESORT : valeur 4 (2 puissance 2)
etc...

Pour les utiliser, on se sert de l'opérateur OU binaire | (pipe simple) de la manière suivante:

myArray.sort(Array.DESCENDING | Array.UNIQUESORT);

Pour utiliser ce système dans d'autres situations, j'ai développé une ch'tite classe toute simple qui génère des options propres à chaque classe, et permet de tester si une option donnée est donnée dont voici l'utilisation:

package com.lalex.utils {

        import flash.display.BitmapData;        

        import com.lalex.utils.Options; 

        

        /**

         * @author LAlex

         */

        public class LAlexDemo {



                // Create options on the fly

                

                public static const SHOW_DEBUG : int = Options.create(LAlexDemo);

                public static const SHOW_BORDER : int = Options.create(LAlexDemo);

                public static const HIDE_FILL : int = Options.create(LAlexDemo);

                

                public function drawShape(bdt : BitmapData, options:int = 0) : void {



                        if (Options.hasOption(options, SHOW_DEBUG)) trace("We will show debug infos");

                        if (Options.hasOption(options, SHOW_BORDER)) trace("We will show shape's border");

                        if (Options.hasOption(options, HIDE_FILL)) trace("We will hide shape's fill color");



                }

        }

}



// Utilisation



var demo:LAlexDemo = new LAlexDemo;

demo.drawShape(myBitmapData, LAlexDemo.SHOW_DEBUG | LAlexDemo.HIDE_FILL);

Voila, un p'tit clic pour télécharger com.lalex.utils.Options

Freelance

-Alexandre LEGOUT aka LAlex- — Wed, 20 Feb 2008 19:23:00 +0100

A compter du 3 Mars, je démarre une activité de développeur indépendant, spécialisé dans l'Actionscript 3 pour Flash, et pourquoi pas Flex 2/3 (que j'ai pratiqué intensemment dans mon précédent poste sur la Côte) et Adobe AIR.
Une nouvelle page (simplissime certes, mais tirée au cordeau en XHTML/CSS) orne donc maintenant le site LAlex.com pour rendre compte de cette nouvelle direction dans ma vie!

Si vous avez donc besoin d'un prestataire sérieux, n'hésitez pas à me contacter pour connaitre mes disponibilités!

Voilà, c'était le billet "nombril" du jour

Actionscript 3 pour GeSHi

-Alexandre LEGOUT aka LAlex- — Mon, 11 Feb 2008 12:43:00 +0100

Eh oui, un gentil belge a fait le fichier de colorisation Actionscript 3 pour GeSHi, disponible sur son blog.

Merci à lui!

TextField, htmlText et retours à la ligne

-Alexandre LEGOUT aka LAlex- — Mon, 07 Jan 2008 19:37:00 +0100

Le nouvelle gestion des TextField avec AS3 est assez géniale je dirais: plus de propriété html, et une gestion commune entre le texte "classique" associé aux TextFormat et le texte HTML. Du coup, on peut manipuler indifféremment le HTML ou les TextFormat, la modification de l'un sera reportée sur l'autre, comme on peut le voir via le code suivant:

// Crée le champ texte

var tField:TextField = new TextField;

tField.text = "LAlex";



// Crée le format (couleur rouge)

var tFormat:TextFormat = new TextFormat();

tFormat.color = 0xFF0000;



// Applique sur les deux premiers caractères

tField.setTextFormat(tFormat, 0, 2);



// Affiche le resultat HTML de tout ca

trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#FF0000" LETTERSPACING="0" KERNING="0">LA<FONT COLOR="#000000">lex</FONT></FONT></P>

Bon, aprés on va pas chipoter sur la cohérence du formatage HTML, évidemment il y a mieux, mais le tout est d'avoir notre correspondance TextFormat/HTML...

Bref, tout ceci étant fait, si on veut obtenir le copie conforme d'un texte dans un autre, il suffit alors de copier le htmlText du premier sur le second, sans se préoccuper des TextFormat? Eh bien pas forcément...

En effet, un petit bug (a mon avis, car j'ai du mal à expliquer la logique derrière ca) s'est glissé dans la gestion du HTML par les TextField. En effet, quelle que soit la valeur de la propriété condenseWhite (sensée faire le même travail qu'un navigateur HTML, à savoir ne pas afficher les espaces blancs consécutifs), un TextField va systématiquement zapper les paragraphes vides, alors que c'est ce qu'il utilise en interne pour faire des retours à la ligne! Bref, tous les retours à la ligne vont sauter quand on copie le htmlText... Par exemple, si j'ai mis trois retours à la ligne et un texte dans un TextField, les retours à la ligne seront en fait des paragraphes vides <p>:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

Bon, OK. Et si maintenant on réaffecte cette valeur à htmlText et qu'on la relit? Voilà ce que ca donne:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



var myHtmlText:String = tField.htmlText;

tField.text = "";

tField.htmlText = myHtmlText;



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

(a noter que je remet le texte à zéro avant de le réattribuer, car sinon il ne fait aucun traitement: il doit exister en interne un traitement du type if (_odlHtmlText != _newHtmlText) {...}).

Comment parer ce problème? J'ai constaté qu'un "vrai" retour à la ligne entre deux paragraphes restaure le retour à la ligne dans le champ texte. Il suffit donc de rajouter un \n entre la fin d'un paragraphe et le suivant. Du coup, une petite regexp fait l'affaire:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



var myHtmlText:String = tField.htmlText;

tField.text = "";



var reg : RegExp = new RegExp("</([Pp])><", "g");

tField.htmlText = myHtmlText.replace(reg, "</$1><");



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

Et voilà!

Interfaces et classes internal

-Alexandre LEGOUT aka LAlex- — Mon, 17 Dec 2007 13:04:00 +0100

L'AS3 nous a amené les classes internes (mot-clé internal) qui nous permettent d'encapsuler un certain nombre de fonctionnalités dans une classe disponible uniquement à la classe publique qui l'utilise. Bien pratique, cela évite les classes trop longues, et grâce à l'héritage (une classe interne peut en étendre une autre), cela peut aussi éviter l'utilisation d'un trop grand nombre de if, et donc abaisser la complexité du code.

Cela peut aussi permettre de disposer d'une classe qui n'est pas instanciable depuis l'extérieur. Seulement, il peut parfois être utile d'accéder à une instance de ces classes, et là, la solution c'est tout simplement les interfaces...

Prenons l'exemple d'une liste de contacts (VoIP un jour, VoIP toujours!), dans laquelle on peut sélectionner un contact. Le XML sera utilisé pour remplir cette liste, et un certain nombre d'actions peuvent être effectuées sur les contacts, mais la liste reste le seul moyen d'avoir des contacts: en gros, il est impossible de créer un contact via un constructeur de type new Contact(...).

L'utilisation conjointe des classes internes et des interfaces nous donnerai ceci: Une interface contact

package {



        /**

         * Contact public interface

         * 

         * @author LAlex

         */

        public interface Contact {

                function sendMail(text:String) : void;

                function get firstName() : String;

                function get lastName() : String;

        }

}

Une classe ContactList et son implémentation de l'interface en tant que classe interne

package {



        /**

         * @author LAlex

         */

        public class ContactList {



                private var _contacts:Array = [];               

                private var _selectedContactPosition : int = -1;

                

                function ContactList(dP:XML = null) {

                        if (dP != null) {

                                setDataProvider(dP);

                        }

                }

                

                // Methods

                

                public function setDataProvider(x : XML) : void {

                        for each (var contactNode:XML in x.contacts.contact) {

                                _contacts.push(new ContactImpl(contactNode));

                        }

                }

                

                public function selectContactAt(ind : int = -1) : void {

                        if (ind < _contacts.length) {

                                _selectedContactPosition = ind;

                        }

                }

                

                public function get selectedContact() : Contact {

                        if (_selectedContactPosition != -1) {

                                return _contacts[_selectedContactPosition] as Contact;

                        }

                        return null;

                }

                

        }

}



// Contact interface implementation

internal class ContactImpl

        implements Contact {

        

        private var _firstName:String;

        private var _lastName:String;

        

        function ContactImpl(x : XML) {

                _firstName = x.@first;

                _lastName = x.@last;

                // Other initiation

        }

        

        public function sendMail(text : String) : void {

                // Mail sending implementation

        }

        

        public function get firstName() : String {

                return _firstName;

        }

        

        public function get lastName() : String {

                return _lastName;

        }

}

L'utilisation de cette classe donnerait:

var list : ContactList = new ContactList(<dataprovider><contacts><contact first="Alexandre" last="LEGOUT" /><contact first="Gérard" last="DUPONT" /></contacts></dataprovider>);

list.selectContactAt(1);



var selected : Contact = list.selectedContact;

trace(selected.firstName + " " + selected.lastName);

Et voilà, on a accès depuis l'extérieur de la classe à tous les comportements "publics" d'un contact, sans avoir accés à son implémentation!
Alors je sais que c'est justement le but des interfaces, mais j'ai trouvé cette utilisation intéressante, et assez représentative de l'utilité des interfaces, au cas où vous ne seriez pas encore convaincus...