LAlex devblog v6

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...

Tweens: frame-based vs. time-based

-Alexandre LEGOUT aka LAlex- — Mon, 03 Dec 2007 15:55:00 +0100

Actuellement en train de travailler sur un séquenceur de différents types d'action, incluant notamment les interpolations, j'en viens à re-développer une classe de Tween, incluant les améliorations standards des TweenEngine en circulation sur la toile (tween de plusieurs propriétés par exemple).

Tout d'abord, il faut savoir qu'un tween a un principe tout simple: je veux qu'une propriété numérique d'un objet (le plus souvent un objet visuel, comme un Sprite par exemple) évolue entre une valeur de départ et une valeur d'arrivée sur une durée précise. Une équation est utilisée afin de déterminer l'évolution de cette valeur, la plus simple étant une équation linéaire (on partage la distance en intervalles réguliers).

Pour cela, il existe trois méthodes:

Le frame-based

Caractéristiques: La durée du tween est donnée en nombre de frames, et le calcul de chaque position se fait à chaque frame (typiquement, en écoutant l'évènement Event.ENTER_FRAME)
Concept: à chaque calcul, on regarde le nombre de frames écoulé depuis le départ par rapport à la durée en nombre de frames.
Avantages:

On travaille avec des nombres entiers et invariants concernant la position courante dans le temps (nombre de frames écoulé) et la durée. Il devient donc possible de cacher une interpolation et donc de réduire les temps de calcul pour les interpolations suivantes utilisant le même couple équation/durée. En effet, une équation donnée sur une durée donnée se comportera toujours de la même manière. En gros, elle sera toujours à x% de son trajet à la n-ième frame, et c'est donc possible de le mettre en cache.

Inconvénient:

L'intervalle de temps entre deux frames n'est pas fixe: si lors de l'exécution d'une frame un code oblige à ralentir le framerate, le player flash le fera automatiquement. Cela est probablement du à son mode d'exécution mono-threadé. Donc, sur une animation à 30fps, un tween d'une durée de 30 peut prendre plus d'une seconde... L'autre inconvénient, qui peut aussi être un comportement voulu, est que modifier le FPS global de l'animation revient à modifier la vitesse d'interpolation.

Le time-based

Caractéristiques: La durée du tween est donnée en seconde, et le calcul de chaque position est faite à un intervalle de temps donné (typiquement avec setInterval, ou plus "clean" avec la classe Timer).
Concept: un Timer lance le calcul de la nouvelle position toutes les x millisecondes. La base de calcul est le nombre de millisecondes écoulées sur la durée en nombre de millisecondes. Un TimerEvent.updateAfterEvent s'occupe de rafraichir l'affichage indépendamment du framerate.
Avantages:

L'interpolation se fait sur une notion de temps. Bien que le Timer ne soit pas forcément extrêmement précis, c'est ce qu'on peut obtenir de plus proche. Ainsi, le taux de rafraichissement du tween peut même être configurable dynamiquement. Par exemple, on pourrait avoir un tween fluide sur une animation pourtant compilée à 2FPS.

Inconvénients:

Justement, on ne contrôle pas la synchronisation anim/temps. Du coup, on surcharge beaucoup le moteur d'affichage du Flash Player, qui doit rafraichir l'affichage à chaque frame mais aussi à chaque calcul du tween. Il est également trés dur de synchroniser deux tweens: en effet, deux Timer de même durée peuvent dispatcher à plusieurs millisecondes d'intervalle, décalant d'autant les traitements.

Le "frame/time-based"

Caractéristiques: Mix entre le time-based et le frame-based: la durée du tween est donnée en secondes, et le calcul de chaque position se fait à chaque frame.
Concept: A chaque frame, on calcule le temps écoulé en millisecondes depuis le départ sur la durée totale en millisecondes
Avantage:

On obtient les avantages combinés du frame-based (économie du moteur d'affichage) et du time-based (durée constante, indépendante du framerate).

Inconvénient:

La fluidité de l'anim nécessitera un FPS élevé, comme pour le frame-based: fini les anims fluides à 2FPS!
Comme pour le time-based, il est difficile de synchroniser les tweens entre eux, ou alors ils peuvent être synchronisés alors qu'ils ne devraient pas. En effet, admettons qu'une frame s'affiche toutes les 100ms exactement (je sais, un monde parfait n'existe pas, mais faites comme si). Le framerate est volontairement bas (10FPS) pour l'exemple. Deux tweens commencant exactement au même moment, et ayant des durées respectives de 820 et 880ms finiront en même temps, sur la frame 9. En effet, sur la frame 8, 800ms se sont écoulées, et le prochain calcul, qui déterminera la fin des deux tweens, se fera à la frame suivante, soit à 900ms.

Quel mode pour quel usage?

Le mode à utiliser est extrêmement propre à l'usage auquel il est destiné. Les moteurs existants utilisent souvent par défault la troisième option (frame/time-based), et proposent assez souvent la première (frame-based). Le deuxième reste la plus marginale, mais est tout de même proposée dans quelques moteurs/classes. Globalement, je suggèrerais:

frame-based: si vous avez le contrôle de votre environnement de déploiement ou un framerate connu et fixe, ce mode ci devrait être le plus performant car travaillant sur des petits nombres et "cachables" (sauf aprés calcul dans l'équation). Egalement bien utile quand on a un besoin de synchronisation très précise (sauf avec les classes de Tween d'Adobe, voire poste précédent) entre différents tweens, ou quand on travaille avec beaucoup d'éléments issus de la timeline (trés fréquent quand on travaille avec un graphiste/animateur flash) avec lesquels vous devez vous caler.
time-based: a priori le moins utilisé (y compris par les TweenEngine). Il est le moins performant car il rajoute du travail au moteur d'affichage du Flash Player. A utiliser si vous avez besoin d'une fluidité constante quel que soit le framerate. S'il vous faut uniquement des interpolations dont la vitesse est indépendante, voir le "frame/time-based".
frame/time-based: utile pour avoir une durée a peu prés constante indépendamment du framerate. Très utilisé avec les vidéos ou les sons par exemple, il se positionne systématiquement au bon endroit selon le temps "réel" écoulé, quel que soit le nombre de calculs déjà effectués. En bref, même si l'appli "rame", votre tween sera plus ou moins synchro. Interessant aussi quand on ignore le framerate qui sera utilisé par l'application et qu'on désire conserver la vitesse des interpolations, si votre anim est chargée par un Loader par exemple (dans un site portail, un CMS, etc...).

Perso, quand je sais que mon SWF va tourner "tout seul", j'utilise beaucoup de frame-based, avec un "stabilisateur" de framerate (type celui d'André Michelle) pour être sur qu'il sera vu de la même manière par tout le monde...

Tweens Flash CS3

-Alexandre LEGOUT aka LAlex- — Tue, 30 Oct 2007 16:50:00 +0100

Je me rend compte carrément tard par rapport au temps depuis lequel j'utilise les Tweens, mais aviez-vous remarqué que la classe fournie par Adobe dans Flash CS3 (fl.transitions.Tween) émettait l'évènement de fin (TweenEvent.MOTION_FINISH) une frame trop tard? La raison est simple, le test effectué pour détecter la fin est strict:

if (t > this.duration) {

Il suffirait d'un '>=' à la place pour modifier cela, mais à ce moment là la fonctionnalité de boucle zapperais une frame avant de boucler...

Les Tweens de Flex et des "tween engines" que j'ai vu en AS3 (TweenLite et Tweener) n'ont pas ce défaut par contre...

Composants Flash CS3 : le meilleur set sera gratuit?

-Alexandre LEGOUT aka LAlex- — Fri, 26 Oct 2007 12:15:00 +0200

Trouver un set de composants de base pour Flash CS3, à part celui développé par Grant Skinner dont tout le monde se plaint, c'est pas facile. Trouver un set de composants faciles à personnaliser, c'est encore moins facile.

Alors quand un "frenchy" s'apprête à proposer les Liquid Components, un set de composants de base qui répond à tous les besoins des graphistes (et des autres utilisateurs de Flash CS3) en terme de personnalisation, et qu'en plus on sait qu'il les mettra à disposition gratuitement, obligé d'en parler!

Les Liquid Components partent d'un principe de base: comment un graphiste qui crée des RIAs simples peut-il intégrer des composants à un visuel fin et travaillé sans que ca jure, et sans demander de connaissances de codeur? En utilisant un systême de skins Bitmap. Pensé par Didier Brun (Foxy) depuis maintenant bien 5 ans, l'AS3 et l'arrivée de BitmapData lui ont enfin permi de mettre au point un système analogue au 9-slices grid, mais dédié au bitmap, dotant les Liquid Components d'un système de skining révolutionnaire pour Flash: un composant = un bitmap. En gros, c'est la première fois qu'on peut faire du vrai skinning sur des composants (optimisé de surcroit grace à l'utilisation des bitmaps), à opposer au styling (système de personnalisation des couleurs, polices et autres paramètres prédéfinis).

Et comme si ça ne suffisait pas, les Liquid Components proposent également:

du live skinning: chargement de skins bitmap à la volée (runtime).
un inspecteur de composant propriétaire, qui change la vie (fini les tableaux de 20 éléments sur une seule ligne, ou le parcours de la bibliothèque pour retrouver un identifiant de liaison)
un composant de base pour faire du 9-slices grid sur des images bitmaps
la gestion du livepreview concernant les tailles, polices, etc...
la possibilité d'associer une icone bitmap à n'importe quel texte, et donc d'avoir des icônes pour un label, un élément de liste, un élément de combobox, etc...
pour les codeurs, un accés facile à tous les éléments d'un composant grâce à la composition.
des possibilités de styling à double entrée: myComponent.setStyle("font", "Arial") pour l'utilisation dynamique (styling via XML par exemple) / myComponent.font = "Arial" pour un accés typé aux propriétés de styling

Bon, et histoire de faire le beau un peu, je précise juste que j'ai suivi le projet de prés: j'avais même implémenté la première version de la grille servant au skinning (AS2 à l'époque), que Didier brillamment amélioré et porté en AS3. Je suis content de voir que mes conseils et avis ont aidé le projet à avancer, et espère bien continuer à y contribuer.

En fait, pour toutes les infos, il suffit d'aller sur la page officielle de ByteArray.org.