Les Events

Ici nous avons seulement un unique Event pour ce projet. C’est assez rare, le projet est vraiment petit.

[as3]
package controller.events
{
import model.vo.Entry;

import flash.events.Event;

public class DiaporamaEvent extends Event
{
// événements concernant l’application
public static const STARTUP : String = ‘startup’;
public static const CONFIG_COMPLETE : String = ‘configComplete’;
public static const NEXT : String = ‘next’;
public static const PREVIOUS : String = ‘previous’;

// événements concernant la View
public static const REFRESH : String = ‘refresh’;
public static const LOAD_COMPLETE : String = ‘loadComplete’;

public var entry : Entry;

public function DiaporamaEvent( type : String,
bubbles : Boolean = false,
cancelable : Boolean = false,
entry : Entry = null )
{
super(type, bubbles, cancelable);

this.entry = entry;
}

public override function clone():Event
{
return new DiaporamaEvent( type, bubbles, cancelable, entry );
}

public override function toString():String
{
return formatToString(« DiaporamaEvent », « type », « bubbles », « cancelable », « eventPhase »);
}

}

}
[/as3]

On distingue 2 catégories d’Event.TYPE dans cette classe. On a vu plus haut que REFRESH ne concerne qu’un Mediator, c’est la même chose pour LOAD_COMPLETE. J’ai donc bien distingué ces deux catégories dans mes commentaires.

En effet, si tous les Event donnant lieu à une Command sont listés dans mon Context, les handlers présents dans les Mediators sont moins facilement repérables. Cela m’aidera à me relire que de le préciser dans ma classe DiaporamaEvent.

Les Commands

Les Commands contiennent la logique de l’application, ici nos seules fonctionnalités sont les clics sur suivant et précédent. On retrouve donc ces 2 Commands, prenons-en une sur les 2, elles sont très semblables :

[as3]
package controller.commands
{
import model.DiaporamaData;

import org.robotlegs.mvcs.Command;

public class NextCommand extends Command
{
[Inject]
public var diaporamaData : DiaporamaData;

override public function execute() : void
{
diaporamaData.next();
}

}

}
[/as3]

Lorsque l’événement DiaporamaEvent.NEXT survient, la Command est éxecutée, le Model est injecté, et on agit sur le Model par un appel de méthode publique. Voilà qui colle plutôt bien à la définition du Controller qu’on a donnée plus tôt, et à notre petit schéma.

Dans une Command, on agit sur le Model.

Si on relis DiaporamaContext, on a une StartupCommand, dispatchée au lancement de l’application :

[as3]
package controller.commands
{
import model.DiaporamaData;

import org.robotlegs.mvcs.Command;

public class StartupCommand extends Command
{
[Inject]
public var diaporamaData : DiaporamaData;

override public function execute() : void
{
diaporamaData.load();
}

}

}
[/as3]

Enfin on a une ConfigCompleteCommand, qui est appelée à la fin du chargement du XML. Pour l’instant, nous n’avons rien de visible sur la scène, notre appli est vide!

[as3]
package controller.commands
{
import controller.events.DiaporamaEvent;
import view.components.DiaporamaDisplay;
import view.components.DiaporamaControls;

import org.robotlegs.mvcs.Command;

/**
* appelée à la fin du chargement du .XML
*/
public class ConfigCompleteCommand extends Command
{
// on récupére l’Event déclencheur
[Inject]
public var event : DiaporamaEvent;

override public function execute() : void
{
// on crée la vue
contextView.addChild( new DiaporamaDisplay() );
contextView.addChild( new DiaporamaControls() );

// on force le refresh de la vue, pour afficher la première image
dispatch( new DiaporamaEvent( DiaporamaEvent.REFRESH, false, false, event.entry ) );
}

}

}
[/as3]

C’est donc là qu’est créé la couche visible de notre application! On notera 2 choses très importantes sur cette Command :

• l’injection d’un event : en effet, une Command on l’a compris est une sorte de gros handler d’événement. Pour récupérer les paramètres de l’Event déclencheur (ici entry nous intéresse), on injecte l’event.
• l’appel à contextView : pour récupérer une référence vers la Stage et ajouter des éléments à la DisplayList, RobotLegs fourni une référence nommée contextView vers la variable du même nom déclarée dans DiaporamaContext.

Note :plutôt qu’un appel à contextView, dans certains cas (menu clic-droit custom, resize de stage, curseur custom, multi-fenêtre sous AIR, etc), il est indiqué de créer un StageMediator.

Aller plus loin

Sur ce tutoriel en particulier, les choses suivantes peuvent être effectuées pour s’entraîner :

• séparer correctement DiaporamaEvent en plusieurs événements disctincts.
• ajouter un StageMediator et customiser le menu du clic-droit
• passer l’adresse du XML en FlashVars
• ajouter du son : un indice, un son est une View.

Sur un plan plus général :

• Beaucoup d’exemples ici : http://www.robotlegs.org/examples/
• RobotLegs a le site de support le mieux fichu qui soit : http://knowledge.robotlegs.org/
• Les best-practices sont ici : http://github.com/robotlegs/robotlegs-framework/wiki/Best-Practices

Les composants visuels

Les composants visuels doivent être réutilisables de projet à projet. Ils sont donc agnostiques au projet, et ne doivent contenir aucune référence au framework. On doit littéralement pouvoir les importer dans un projet vide, et les lancer seuls – ils sont autonomes.

Pour ce projet nous aurons deux composants visuels :

• DiaporamaDisplay : c’est un UILoader en plus léger et plus classe. On lui passe une URL et il charge cette image puis l’affiche. Et c’est tout.

[as3]
package view.components
{
import model.vo.Entry;
import controller.events.DiaporamaEvent;

import com.gskinner.motion.GTween;
import com.gskinner.motion.easing.Quadratic;

import flash.display.Sprite;
import flash.events.Event;
import flash.display.Loader;
import flash.display.Bitmap;
import flash.net.URLRequest;
import flash.display.LoaderInfo;

/**
* composant visuel basique,
* un afficheur d’image simple avec une transition animée
*/
public class DiaporamaDisplay extends Sprite
{
private var _front : Sprite;
private var _back : Sprite;

private var _backContent : Bitmap;
private var _frontContent : Bitmap;

private var _current : Sprite;

public function DiaporamaDisplay()
{
_back = new Sprite();
_front = new Sprite();

addChild(_back);
addChild(_front);
}

public function refresh( entry : Entry ) : void
{
var l : Loader = new Loader();
l.contentLoaderInfo.addEventListener( Event.COMPLETE, onLoadComplete );
l.load( new URLRequest(entry.file) );
}

private function onLoadComplete( e : Event ) : void
{
_backContent = (e.target as LoaderInfo).loader.content as Bitmap;
_back.alpha = 0;
_backContent.addEventListener( Event.ADDED_TO_STAGE, onAdded );
_back.addChild(_backContent);
}

private function onAdded(e:Event):void
{
removeEventListener(Event.ADDED_TO_STAGE, onAdded);
new GTween( _back, .5, { alpha: 1 }, { onComplete: onFadeComplete, ease : Quadratic.easeOut } );
new GTween( _front, .5, { alpha: 0 }, { ease : Quadratic.easeIn } );
}

private function onFadeComplete( g : GTween ) : void
{
var frontBuffer : Sprite = _front;
_front = _back;
_back = frontBuffer;

dispatchEvent( new DiaporamaEvent( DiaporamaEvent.LOAD_COMPLETE ) );
}

}

}
[/as3]

• DiaporamaControls : constitué d’une flêche vers la droite (btNext) et d’une flèche vers la gauche (btPrevious). il n’a que 2 méthodes, enable() et disable(), pour freezer les boutons, par exemple le temps d’un chargement.

[as3]
package view.components
{
import controller.events.DiaporamaEvent;

import com.gskinner.motion.GTween;

import flash.display.MovieClip;
import flash.events.MouseEvent;

/**
* composant visuel basique, 2 flêches que l’on peut « geler »
* par exemple le temps d’un chargement
*/
public class DiaporamaControls extends DiaporamaControls_skin
{

public function DiaporamaControls()
{
disable();
}

/**
* rend actif les flêches
*/
public function enable() : void
{
for each( var button : MovieClip in [ btPrevious, btNext ] ) {
if ( button.alpha != 1 )
new GTween( button, .5, { alpha : 1 } );
button.addEventListener( MouseEvent.CLICK, onClick );
button.buttonMode = true;
}
}

/**
* rend inactif les flêches
*/
public function disable() : void
{
for each( var button : MovieClip in [ btPrevious, btNext ] ) {
if ( button.alpha != .5 )
new GTween( button, .5, { alpha : 0 } );
button.removeEventListener( MouseEvent.CLICK, onClick );
button.buttonMode = false;
}
}

/**
* émission d’un Event simple au click
*
* @param e
*/
private function onClick( e : MouseEvent ) : void
{
dispatchEvent( new DiaporamaEvent(
{
btNext : DiaporamaEvent.NEXT,
btPrevious : DiaporamaEvent.PREVIOUS
}[e.currentTarget.name]
) );
}

}

}
[/as3]

Nous avons bien 2 composants agnostiques et autonomes, sans aucune référence à un quelconque objet issu de l’application. Pour être parfait, nous aurions dû utiliser un Event séparé par composant, et faire un .swc par composant + événement attitré.

Les Mediators

Le rôle des Mediators est :

• d’écouter l’application et agir sur leur composant,
• d’écouter leur composant et d’en informer l’application.

Commençons par DisplayControlsMediator, qui va s’occuper de DisplayControls:

[as3]
package view.mediators
{
import controller.events.DiaporamaEvent;
import view.components.DiaporamaControls;

import org.robotlegs.mvcs.Mediator;

/**
* Agit sur diaporamaDisplay en fonction des événements reçus
* du composant ou de l’application
*
*/
public class DiaporamaControlsMediator extends Mediator
{
[Inject]
public var controls : DiaporamaControls;

override public function onRegister() : void
{
// événements issus de l’application
eventMap.mapListener( eventDispatcher, DiaporamaEvent.LOAD_COMPLETE, onLoadComplete );

// événements issus du composant
controls.addEventListener( DiaporamaEvent.NEXT, onClick );
controls.addEventListener( DiaporamaEvent.PREVIOUS, onClick );
}

private function onClick( e : DiaporamaEvent ) : void
{
controls.disable();
dispatch(e);
}

private function onLoadComplete( e : DiaporamaEvent ) : void
{
controls.enable();
}

}

}
[/as3]

On constate que son rôle est d’appeler les méthodes enable() et disable() au bon moment, et forwarder son événement de clic, tout simplement.

Occupons-nous de DiaporamaDisplayMediator, qui s’occupe de DiaporamaDisplay:

[as3]
package view.mediators
{
import controller.events.DiaporamaEvent;
import view.components.DiaporamaDisplay;

import org.robotlegs.mvcs.Mediator;

/**
* Agit sur diaporamaDisplay en fonction des événements reçus
* du composant ou de l’application
*
*/

public class DiaporamaDisplayMediator extends Mediator
{
[Inject]
public var display : DiaporamaDisplay;

override public function onRegister() : void
{
// événements issus de l’application
eventMap.mapListener( eventDispatcher, DiaporamaEvent.REFRESH, onRefresh );

// événements issus du composant
display.addEventListener( DiaporamaEvent.LOAD_COMPLETE, onLoadComplete );
}

private function onRefresh( e : DiaporamaEvent ) : void
{
display.refresh(e.entry);
}

private function onLoadComplete( e : DiaporamaEvent ) : void
{
dispatch(e);
}

}

}
[/as3]

On constate que son rôle est d’appeler la méthode refresh() au bon moment, et forwarder son événement de fin de chargement.

On remarque un DiaporamaEvent.REFRESH, qui n’est pas mappé sur une Command dans DiaporamaContext. En effet, seul ce Mediator est concerné par cet événement, il n’est pas obligatoire d’utiliser une Command.

L’utilité et le rôle d’un Mediator est souvent difficile à cerner pour un débutant. A la relecture de l’integralité du code que nous avons tapé pour l’instant, nous constatons que “c’est là que se font les addEventListener sur la Vue, et les appels de méthodes”. C’est aussi simple que ça.

Note : on voit que l’injecteur est utilisé pour injecter le composant. C’est une très mauvaise idée d’utiliser cet injecteur pour injecter directement dans le Mediator un Model. Cela nuit au découplage en couches. Si un Mediator a besoin d’une donnée, cette donnée doit lui parvenir via un Event reçu, et c’est tout.

Commençons le développement par la couche la plus basse et la plus basse, la couche de Model, qui charge les données et les stocke pour leur usage au sein de l’application. Voici le XML de contenu :

[xml]

[/xml]

On a un seul type de données à stocker dans une structure séquentielle de type liste. Nous allons stocker chaque entrée dans un type personnalisé correspondant à cette structure. C’est un pattern de Value Object, nommons ce type le type Entry.

[as3]
package model.vo
{
public class Entry
{

public var file : String;
public var title : String;

}

}
[/as3]

Construisons maintenant la classe DiaporamaData, dont le rôle sera :

• charger un fichier XML,
• stocker les données : ici dans un Vector.
• passer à l’image suivante : dispatcher le nom du fichier de l’image suivante à charger, et cycler à l’infini
• passer à l’image précédente : dispatcher le nom du fichier de l’image précédente à charger, et cycler à l’infini

[as3]
package model
{
import controller.events.DiaporamaEvent;
import model.vo.Entry;

import org.robotlegs.mvcs.Actor;

import flash.net.URLLoader;
import flash.net.URLRequest;
import flash.events.Event;
import flash.events.IOErrorEvent;

public class DiaporamaData extends Actor
{

private var _entries : Vector.;
private var _current : uint = 0;

public function DiaporamaData()
{
super();
}

public function load( url : String = ‘diaporama-content.xml’ ) : void
{
var content : URLLoader = new URLLoader();
content.addEventListener( Event.COMPLETE, onComplete );
content.addEventListener( IOErrorEvent.IO_ERROR, onIOError );
content.load( new URLRequest(url) );
}

private function onComplete( e : Event ) : void
{
_entries = new Vector.();

var content : XML = new XML((e.target as URLLoader).data);
for each( var entryData : XML in content.entry ) {
var entry : Entry = new Entry();
entry.file = entryData.@file;
entry.title = entryData.title;
_entries.push(entry);
}

eventDispatcher.dispatchEvent( new DiaporamaEvent( DiaporamaEvent.CONFIG_COMPLETE, false, false, _entries[_current] ) );
}

public function next() : void
{
if ( _current + 1 < _entries.length ) {
_current++;
} else {
_current = 0;
}

eventDispatcher.dispatchEvent( new DiaporamaEvent( DiaporamaEvent.REFRESH, false, false, _entries[_current] ) );
}

public function previous() : void
{
if ( _current - 1 >= 0 ) {
_current–;
} else {
_current = _entries.length – 1;
}

eventDispatcher.dispatchEvent( new DiaporamaEvent( DiaporamaEvent.REFRESH, false, false, _entries[_current] ) );
}

private function onIOError( e : IOErrorEvent ) : void
{
throw new Error( ‘content could not be loaded’ );
}

public function get entries() : Vector.
{
return _entries;
}

}

}
[/as3]

C’est là tout ce dont nous avons besoin pour cette application. Le Model est généralement ce qu’il y a de plus facile : on expose quelques méthodes publiques, on émet simplement un/des événements selon l’état du Model.

Robotlegs est disponible sous forme d’un .zip contenant sources, .swc et documentation, à cette adresse : http://www.robotlegs.org/

Commençons par créer un projet AS3 sous FlashDevelop, puis créer la structure de packages que nous allons remplir :

On voit bien les 3 couches à développer :

• controller : il contient les différentes Command qui implémentent cette couche. Un package séparé pour les events qui sont parfois nombreux.
• model : contient les différents Actors, un package est prévu pour les V.O. (“Value Objects”) qui sont des objets de données simples.
• view : un sous-package pour les Mediators, un autre pour les classes graphiques – on a vu plus haut qu’une classe graphique communique toujours par un Mediator.

le Context, coeur de l’application

La structure globale d’une application Robotlegs est définié dans une classe dite “contexte”, qui étend org.robotlegs.mvcs.Context. Cette classe est la façade de l’application, c’est là que sont définis les différents paramètres de l’application.

Au runtime, une application Robotlegs démarre de la manière suivante :

• point d’entrée
• instantiation du Context
• appel de la méthode startup() du Context.

La première classe de notre application sera son point d’entrée de compilation, nommé Diaporama :

[as3]
package
{
import flash.display.Sprite;

/**
* point d’entrée de l’application
*
*/
public class Diaporama extends Sprite
{
private var c : DiaporamaContext;

public function Diaporama() : void
{
c = new DiaporamaContext(this);
}

}

}
[/as3]

Jusque-là c’est plutôt simple, on instantie DiaporamaContext en lui passant l’objet graphique racine de l’application, en conservant une référence explicite vers l’applicationContext pour éviter d’être supprimé par le ramasse-miette. Voyons maintenant DiaporamaContext :

[as3]
package
{
import org.robotlegs.mvcs.Context;

import flash.display.DisplayObjectContainer;

/**
* Contexte de l’application Diaporama
*
*/
public class DiaporamaContext extends Context
{

public function DiaporamaContext( contextView : DisplayObjectContainer,
autoStartup : Boolean = true )
{
// passage explicite des arguments à la classe mère
super(contextView, autoStartup);
}

override public function startup() : void
{

}

}

}
[/as3]

DiaporamaContext étend Context. il reçoit bien en argument l’objet graphique racine. Il passe cette objet à sa classe mère, puis la méthode startup() est appelée automatiquement puisque nous passons autoStartup = true à la classe mère.

La méthode startup() est vide pour l’instant. C’est là que toute la configuration de l’application va se faire. Commençons par définir notre Controller.

définition du Controller

C’est un diaporama classique, avec 2 boutons “précédent” et “suivant”, une barre de progression du chargement par image, et un XML de contenu.

Commençons par lister l’intégralité des événements générant un changement d’état lors du cycle de vie de l’application :

• DiaporamaEvent.CONFIG_COMPLETE : on charge un XML, on aura donc un événement de fin de chargement.
• DiaporamaEvent.NEXT : on a la possibilité d’un clic sur ce bouton.
• DiaporamaEvent.PREVIOUS : on a la possibilité d’un clic sur ce bouton.

Comme indiqué plus haut, les Events d’implémentation Flash classiques n’ont pas leur place dans le contrôleur s’ils ne concernent pas toute l’application. On notera l’absence des événements du type LOAD_START, LOAD_PROGRESS, LOAD_COMPLETE. Ceux-là ne concernant que le composant d’affichage, ils y restent.

Nous allons mapper comme il se doit chacun de ces événements vers une Command :

[as3]
override public function startup() : void
{
// définition du Controller
commandMap.mapEvent( DiaporamaEvent.STARTUP, StartupCommand );
commandMap.mapEvent( DiaporamaEvent.CONFIG_COMPLETE, ConfigCompleteCommand );
commandMap.mapEvent( DiaporamaEvent.NEXT, NextCommand );
commandMap.mapEvent( DiaporamaEvent.PREVIOUS, PreviousCommand );
}
[/as3]

C’est un peu l’équivalent d’un //addEventListener//, sauf qu’au lieu d’appeler une fonction, on appelle la classe Command adaptée, plus particulièrement sa méthode execute().

définition du Model

Pour cette application nous n’avons qu’un seul type de données à charger, en une seule fois au début du cycle de vie, c’est le XML de configuration.

[xml]

[/xml]

Nous aurons donc une seule classe dans notre Model, appelons-là par exemple DiaporamaData. Modifions DiaporamaContext pour en informer le framework :

[as3]
override public function startup() : void
{
// définition du Controller
commandMap.mapEvent( DiaporamaEvent.STARTUP, StartupCommand );
commandMap.mapEvent( DiaporamaEvent.CONFIG_COMPLETE, ConfigCompleteCommand );
commandMap.mapEvent( DiaporamaEvent.NEXT, NextCommand );
commandMap.mapEvent( DiaporamaEvent.PREVIOUS, PreviousCommand );

// définition du Model
injector.mapSingleton( DiaporamaData );
}
[/as3]

Nous indiquons simplement à l’injecteur que lorsque nous demanderons l’accès à un objet DiaporamaData.

Définition de la View

Pour cette application nous n’avons que 2 composants visuels à l’écran :

• DiaporamaDisplay : C’est simplement le container destiné à afficher l’image chargée. Concrétement, c’est un MovieClip.
• DiaporamaControl : C’est simplement le container des 2 boutons “précédent” et “suivant”.

Modifions DiaporamaContext pour en informer le framework :

[as3]
override public function startup() : void
{
// définition du Controller
commandMap.mapEvent( DiaporamaEvent.STARTUP, StartupCommand );
commandMap.mapEvent( DiaporamaEvent.CONFIG_COMPLETE, ConfigCompleteCommand );
commandMap.mapEvent( DiaporamaEvent.NEXT, NextCommand );
commandMap.mapEvent( DiaporamaEvent.PREVIOUS, PreviousCommand );

// définition du Model
injector.mapSingleton( DiaporamaData );

// définition de la View
mediatorMap.mapView( DiaporamaDisplay, DiaporamaDisplayMediator );
mediatorMap.mapView( DiaporamaControls, DiaporamaControlsMediator );
}
[/as3]

On a vu plus haut q’un composant = un Mediator. Ici nous mappons simplement un composant vers son Mediator. Robotlegs écoute l’événement ADDED_TO_STAGE en permanence, quand il détectera l’ajout d’un composant DiaporamaDisplay, il créera automatiquement son pendant DiaporamaDisplayMediator.

Récapitulatif

[as3]
package
{
import controller.events.*;
import controller.commands.*;
import view.mediators.*;
import view.components.*;
import model.*;

import org.robotlegs.mvcs.Context;

import flash.display.DisplayObjectContainer;

/**
* Contexte de l’application Diaporama
*
*/
public class DiaporamaContext extends Context
{

public function DiaporamaContext( contextView : DisplayObjectContainer,
autoStartup : Boolean = true )
{
super(contextView, autoStartup);
}

override public function startup() : void
{
// définition du Controller
commandMap.mapEvent( DiaporamaEvent.STARTUP, StartupCommand );
commandMap.mapEvent( DiaporamaEvent.CONFIG_COMPLETE, ConfigCompleteCommand );
commandMap.mapEvent( DiaporamaEvent.NEXT, NextCommand );
commandMap.mapEvent( DiaporamaEvent.PREVIOUS, PreviousCommand );

// définition du Model
injector.mapSingleton( DiaporamaData );

// définition de la View
mediatorMap.mapView( DiaporamaDisplay, DiaporamaDisplayMediator );
mediatorMap.mapView( DiaporamaControls, DiaporamaControlsMediator );

// démarrage de l’application
dispatchEvent( new DiaporamaEvent( DiaporamaEvent.STARTUP ) );
}

}

}
[/as3]

Voilà la classe DiaporamaContext qui définit l’intégralité des acteurs en jeu dans notre application, ainsi que leurs relations. On constate que c’est très simple d’ajouter des fonctionnalités et des états complémentaires à cette application, voire un chargement d’autres données, une nouvelle vue, etc.

On y a ajouté une dernière ligne qui dispatche l’événement de départ STARTUP.

Retour sur les fondamentaux de l’architecture logicielle orienté objet.

Les applications Flash ou Flex sont constituées d’objets, qui communiquent entre eux par des événements. Le paradigme orienté-objet existant depuis les temps immémoriaux du langage Smalltalk, certaines structures de classes récurrentes répondant à des problèmes précis ont émergées au fil des années. Ces structures récurrentes ont été listées dans l’ouvrage “Design Patterns” du GoF, en voici quelques-uns biens connus :

• Factory : encapsule la création d’un objet complexe de classe A dans une autre classe B.
• Adapter : encapsule un objet A dotée d’une interface inadaptée au projet dans une classe B.
• Command : encapsule une méthode dans une classe indépendante A, dont le rôle est d’agir sur des classes B,C,D.

Les design-patterns ne sont pas un code-source unique et précis. Ils sont indépendants du langage, un design-pattern est une pratique. Il y a autant d’implémentation que de langages de programmation, et plusieurs implémentations possibles au sein d’un même langage.

On trouve des design-patterns simples, répondant à une tâche précise (Factory, Adapter; Command, …) et des design-patterns composés, répondant à des problèmes plus vastes et plus complexes en réunissant plusieurs patterns. Par exemple, pour structurer une application qui affiche des données via une IHM permettant de filtrer/modifier les données, on utilise le plus souvent le pattern Model-View-Controller (dit “MVC”).

Dans le cas précis du développement Flash, ce dernier type d’applications est évidemment le plus courant, la nature même de Flash étant le développement de RIA. Pour structurer ce type d’applications, plusieurs angles d’attaques existent :

• ne pas utiliser de MVC : pour une petite application, on code tout rapidement dans une classe.
• le framework “maison” : on produit une implémentation personnelle de MVC, qu’on réutilise ensuite.
• le framework Cairngorm : développé par Adobe, c’est l’implémentation de référence censée être utilisée et connue, en particulier par tous les développeurs Flex.
• les frameworks MVC alternatifs : issus de la communauté, les plus courants sont Robotlegs, PureMVC, Parsley.
• les frameworks non-MVC alternatifs : basés sur d’autres patterns, comme Swiz et Mate.

Ce tutoriel aborde Robotlegs. Ses points forts par rapport aux autres frameworks sont son utilisation astucieuse de l’injection de dépendances, sa simplicité d’utilisation et sa légèreté (c’est une micro-architecture plus qu’un framework).

Le MVC et son implémentation par Robotlegs

Vue générale

Attardons-nous maintenant sur le pattern MVC, et son implémentation particulière au sein de Robotlegs. MVC scinde l’application en 3 couches :

• la couche Model : regroupe l’ensemble des classes chargeant et stockant les données. Une classe du Model émet des événements en direction des autres couches, et est pilotée par des méthodes publiques.
• la couche Controller : écoute la couche Model et la couche View, et agit sur l’un ou l’autre en appelant des méthodes publiques, en fonction des actions de l’utilisateur, ou de l’évolution des données.
• la couche View : affiche les données du Model, et émet des événements lors des actions utilisateurs.

Ce schéma donne une vue globale de l’implémentation du MVC par Robotlegs.
On remarque deux types de flèches bien distincts :

• les flèches pointillées : ce sont des événements.
• les flèches pleines : ce sont des appels de méthodes publiques – par exemple : applicationModel.load(‘content.xml’); ou applicationView.refresh();

Si le Controller est capable de passer ce type d’appel, on en déduit que le Controller possède une référence vers les classes de la View, et les classes du Model. Or, c’est assez négatif, puisque cela sous-entend d’avoir “en dur” dans le Controller des variables pointant vers toutes les instances existantes des classes du Model et de la View. Ce qui constituerait une “dépendance” du Controller envers la View et le Model. Comment supprimer cette dépendance ?

L’injection de dépendance

Robotlegs, et c’est là son principal point positif, utilise “l’injection de dépendance”. Lorsqu’un appel d’une méthode publique de la View et du Model est nécessaire, la dépendance est injectée dans la partie du Controller qui en a besoin. Elle n’existe que le temps nécessaire, puis disparaît.

Au niveau code, cela se présente ainsi, au sein du Controller ici :

[as3]
public class LoadConfigurationCommand extends Command
{
// l’injection de dépendances a lieu ici
[Inject]
public var applicationData : ApplicationData;

override public function execute() : void
{
// applicationData est peuplée! pourtant elle est simplement déclarée plus haut
// c’est l’injecteur qui a injecté cette classe !
applicationData.load(‘swf/slideshow-conf.xml’);
}

}
[/as3]

On note l’usage très astucieux du meta-tag [Inject]. En effet, il est tout à fait possible pour un développeur de créer de nouveaux meta-tags. Et ce meta-tag particulier à Robotlegs va en fait déclencher en arrière-plan l’injection de la dépendance. La variable publique va automatiquement être peuplée par Robotlegs.

Derrière ce tag custom se cache en réalité toute une couche d’injection dénommée SwiftSuspenders, qui est indépendante de Robotlegs et peut parfaitement être utilisée sur des projets non-Robotlegs, il suffit d’en récupérer le .swc sur le site du projet SwiftSuspenders.

L’implémentation Robotlegs du MVC

On l’a vu plus haut, le MVC est un pattern composé. On connaît maintenant la structure générale de Robotlegs et sa manière particulière de conserver un couplage lâche via l’injection de dépendances. Examinons maintenant les différents patterns constituants son implémentation de MVC :

• la couche Model : elle est implémentée via un pattern Actor. Pattern qui n’en est pas vraiment un, en réalité, c’est simplement une classe capable d’émettre un événement.
• la couche Controller : elle est implémentée via un pattern Command. Chaque événement de l’application est mappé sur une Command. La Command est déclenchée quand l’événement survient. Au sein de la Command sont injectés les classes Model et View à modifier.
• la couche View : elle est implémentée via un pattern Mediator. Pour chaque composant visuel important, une classe Mediator est créée. Cette classe écoute le framework et agit sur la View, et écoute la View et émet vers le framework.

Actor et Mediator émettent des événements, la couche Controller en écoute. Par souci de clarté, il est important voire capital de bien assimiler que les événements du framework ne doivent pas cohabiter avec les événements issus de la View : le moindre MouseEvent.ROLL_OVER n’a pas forcément vocation à remonter jusqu’au coeur du framework!

Tout ça est très compliqué. Heureusement il reste l’exemple pratique en 4 parties.

Une production Entre Midi et Deux – tous droits réservés Sorry Baby Studio.

La Flash Platform est un outil formidable lorsqu’il s’agit d’animation interactive sur le Web, et de développer des applications desktop via AIR. La plate-forme Flash offre d’autres possibilités peu connues. La simplicité du langage et la richesse de sa couche graphique en fait un outil idéal pour développer rapidement des applications visuelles, ce qui a commencé il y a quelques années à intéresser des artistes contemporains : installations interactives, objets intelligents, pilotage de robots, etc. La simplicité du langage AS3 a rendu accessible le développement d’oeuvres réagissant à leur environnement, ou agissant sur leur environnement : c’est le physical computing.

Pour interagir avec l’environnement, nous avons besoin d’une interface physique, comportant des entrées (pour percevoir), et de sorties (pour agir). Notre interface sera :

• une puce électronique, le PIC en lui-même, alimenté en 5v,
• dotée simplement d’entrées et de sorties,
• ces entrées et ces sorties peuvent être analogiques ou numériques : soit elles renvoient/reçoivent une valeur (généralement de 0 à 255), soit un trigger (0 ou 1, noté HIGH ou LOW),
• sur la puce, un espace de mémoire flash contient un programme. Ce programme détermine les interactions entre entrées/sorties, envoie certaines données vers le port série de la carte, les traite parfois, etc. L’espace est très restreint, mais permet pas mal de choses. Le programme est développé et compilé sur PC, puis flashé sur la puce, via un port série ou USB
• un port USB, pour communiquer avec le PC, pour envoyer les données et en recevoir, pour flasher le code sur la puce, et aussi pour l’alimenter en énergie.

Il existe des milliers de modèles différents de PIC. Certains se programment en C, en Assembleur, en Basic, ils sont vendus nus, ou parfois intégré à une carte facilitant leur usage. Des développeurs open-source ont élaboré une plate-forme matérielle et logicielle complète pour faciliter leur usage à destination des mortels : c’est la plate-forme Arduino.

Une Arduino est une carte doté d’un connecteur USB, d’un PIC ATMega168, de fiches d’entrées/sorties, et d’un quartz permettant de faire tourner tout ça. Vous pouvez soit récupérer les plans et construire votre carte vous-mêmes, soit acheter directement une carte prête à l’emploi : l’Arduino Duemilanove, pour la somme modique de 22€, auprès de l’initiateur du projet.

Côté hardware :

Une carte Arduino ça ressemble à ça :

Vous aurez aussi besoin de quelques composants :

• une résistance photo-sensible et une résistance de 10KOhms (les couleurs sur la résistance servent à indiquer sa valeur). Vous pouvez vous procurez ça dans tous les magasins d’électronique, à 0,10€ pièce.
• une platine d’expérimentation et les fils qui vont bien. A acheter sur eBay aux usines chinoises pour 9€, ou en magasin pour 30€.
• de la lumière

Côté software :

• les drivers Arduino et l’IDE de développement
• Flash/Flex SDK selon vos habitudes,
• la librairie AS3Glue, qui permet à Flash de communiquer avec l’Arduino,
• j’ai utilisé Arthropod comme debugger,
• j’ai utilisé Away3D comme moteur 3D,

Installation

Commençons par installer l’environnement logiciel nécessaire à l’Arduino.

• la carte n’est pas branchée au PC.
• on télécharge le .zip, on le dézippe proprement, dans C:\tools\arduino par exemple.
• on connecte la carte sur un port USB : Windows démarre la recherche de nouveau matériel une première fois, on clique sur …(utilisateurs expérimentés)
  
• on sélectionne C:\tools\arduino\drivers\FTDI USB drivers dans la fenêtre suivante
• une fois cliqué sur Terminé, re-belote, 2ème recherche de drivers, on refait la même chose.
• Les 2 drivers que nous avons installés servent à faire apparaître le port USB de la carte comme un port série. En effet, nous pouvons maintenant vérifier notre installation :
• Le port COM3 correspond maintenant à notre carte. Toute donnée entrante/sortante sur ce port série sera en réalité vers/depuis le PIC par le port USB physique. Le port USB émule un port série.
• Lançons maintenant l’IDE, C:\tools\arduino\arduino.exe
• Lors de votre première utilisation, vous devez au préalable configurer l’IDE pour le modèle de votre carte :
• Et configurer le bon port série :
• We’re done!

Un premier test

La plate-forme Arduino n’utilise pas le C ou l’Assembleur pour programmer le PIC, mais un langage très simple, proche de Processing, nommé Wiring. Nous allons développer notre première appli Wiring pour tester notre install, la flasher sur la carte et tester si tout se passe correctement.

La carte comporte une toute petite LED, nous n’avons pas besoin d’en connecter une. Cette LED est pilotée par le connecteur n°13, en envoyant HIGH/LOW à intervalles réguliers, elle devrait clignoter. Voici le code-source :

[c]
#define LED 13

void setup()
{
pinMode( LED, OUTPUT );
}

void loop()
{
digitalWrite( LED, HIGH );
delay(1000);
digitalWrite( LED, LOW );
delay(1000);
}[/c]

On compile le code en cliquant sur le bouton de l’IDE. Tout se passe bien. Maintenant nous uploadons l’éxecutable sur la carte en cliquant sur « Upload ». Les diodes de la carte RX et TX clignotent, confirmant le flashage, puis la diode L commence à clignoter tous les 1000ms.

Création du circuit électronique du capteur

a) Partie hardware

Nous allons maintenant construire notre capteur pour l’application définitive. Le but du montage est le suivant :

• la photo-résistance a une résistance variable selon la lumière.
• le micro-contrôleur va lire cette valeur en continu
• et la transmettre au PC via l’USB, sous forme d’une valeur numérique exploitable par notre client Flash.

ATTENTION : nous allons maintenant réaliser le montage électronique nécessaire. nous allons donc jouer avec l’électricité. L’Arduino fonctionne en 5V, il n’y a aucun danger pour vous. Prenez vos précautions en réalisant le montage, ne branchez pas le GND sans avoir vérifié plusieurs fois qu’il est bien fidèle à la photo. Même si l’Arduino possède un fusible, une erreur mineure peut provoquer un court-circuit et détruire un de vos composants, soyez attentifs à ce que vous faites – faites particulièrement attention aux fils qui trainent en cours de branchement et peuvent se toucher. Si vous provoquez un court-circuit, débranchez le GND, puis débranchez et rebranchez la carte du connecteur USB, le fusible se remettra en place.

Réalisez le montage électronique suivant sur votre platine :

Le circuit est plutôt simple :

• le +5V de la carte est utilisé,
• il passe au travers de la résistance variable, suivant la lumière qu’elle capte, sa résistance varie,
• elle est protégée par une résistance 10KOhms,
• l’entrée analogique 0 lit la valeur de tension dans le circuit,
• le circuit se finit sur le pôle négatif (GND = « ground ») de la carte.

b) Partie software

Voilà le code source :

[c]

#define SENSOR 0 // la photo-résistance sera branchée sur ce port

int lightValue = 0;

void setup()
{
    // on démarre le port série, à 9600 Bauds
    Serial.begin(9600);
}

void loop()
{
    // on lit la valeur analogique sur le pin 0
    lightValue = analogRead(SENSOR);

    // on l'envoie dans le port série
    Serial.println(lightValue);

    // on ralentit 100ms, sinon le port va saturer
    // la carte tourne en effet à la vitesse de son quartz,
    // soit 20MHz
    delay(100);
}

[/c]

On compile, on uploade.

Dans l’IDE, vous pouvez contrôler les infos envoyées par la carte sur la port série par la fenêtre de monitoring, lancez-la :

La valeur oscille entre 0 et 1023 en théorie, en pratique les photos-résistances sont tellement sensibles que ça dépend de la lumière ambiante.

Oh yeah, ça marche, il ne reste plus qu’à rendre ça lisible par Flash!

c) Développement du client Flash

Voici le schéma de ce que nous allons réaliser :

Nous avons précédemment écrit en Wiring notre partie logicielle, puis l’avons flashée sur le PIC. Ce n’est pas très flexible : on doit flasher à chaque fois, apprendre un nouveau langage, et nous sommes limités à la toute petite mémoire de 8Ko du PIC, c’est pas génial.

Dans ce but, la communauté open-source a développé Firmata. C’est un firmware standardisé, qui va nous permettre de contrôler le PIC depuis l’extérieur. Au lieu de flasher des instructions, on va envoyer ces instructions au firmware par le port série, qui les interprétera en temps réel.

Installer Firmata est très simple, il est fourni dans les exemples de l’IDE Arduino :

On clique sur « Upload », notre précédent programme est effacé, remplacé par le firmware.

Flash ne peut pas lire directement les données du port série, ou du port USB. Mais il peut communiquer via un serveur socket. Nous allons donc utiliser un petit utilitaire qui va mapper les données du port série vers un socket, il s’agit de serproxy. Celui-ci est directement inclus dans le package AS3Glue, dans le dossier \applications\Serproxy-0.1.3-3.

Il y a un peu de configuration à faire – éditez le fichier config.cfg pour rfléter votre configuration, avec l’Arduino sur le port COM3, voilà la configuration à suivre :

newlines_to_nils=false
comm_ports=3
comm_baud=57600
comm_databits=8
comm_stopbits=1
comm_parity=none
timeout=300
net_port3=5331

Pour vérifier la configuration de serproxy, utilisez sous Windows la commande telnet (Démarrer > Exécuter > telnet), après avoir lancé serproxy.exe :

Microsoft Telnet> o 127.0.0.1 5331

Le serveur doit afficher :

server(3) : thread started

En cas d’erreur de ce type :

unable to open comm port

vérifiez votre port COM dans le fichier serproxy.cfg, et fermez le SerialMonitor : une seule application à la fois peut utiliser un port COM sous Windows.

Notre PIC est maintenant muni du firmware Firmata 2.0. Il reste à le piloter, as3glue est un projet open-source qui implémente la norme Firmata aussi. Rien de plus simple donc :

[as3]
package
{
import com.carlcalderon.arthropod.Debug;

import flash.display.Sprite;
import flash.events.Event;

import net.eriksjodin.arduino.Arduino;
import net.eriksjodin.arduino.events.ArduinoEvent;
/**
* …
* @author
*/
public class Application extends Sprite
{
private var _arduino : Arduino;

public function Application() : void
{
Debug.clear();
_arduino = new Arduino( ’127.0.0.1′, 5331 );
_arduino.addEventListener( Event.CONNECT, onSocketConnect );
_arduino.addEventListener( ArduinoEvent.FIRMWARE_VERSION, onReceiveFirmwareVersion );
_arduino.addEventListener( ArduinoEvent.ANALOG_DATA, onReceiveAnalogData );
}

private function onSocketConnect( e : Event ) : void
{
Debug.log(‘onSocketConnect’);
_arduino.requestFirmwareVersion();
}

private function onReceiveFirmwareVersion( e : ArduinoEvent ) : void
{
// on contrôle ainsi si Firmata 2.0 est bien présent
Debug.log( ‘firmware version : ‘ + e.value );

// strictement équivalent à notre programme Wiring :
// Serial.println(analogRead(0));
_arduino.setAnalogPinReporting( 0, Arduino.ON );
}

private function onReceiveAnalogData( e : ArduinoEvent ) : void
{
// on affiche la valeur,
// qui doit être équivalente à celle affichée par notre programme Wiring
Debug.log( e.value );
}
}
}
[/as3]

Si vous avez bien suivi les étapes, votre débuggeur vous affiche la valeur de lumière ambiante, voilà les erreurs possibles :

• unable to open comm port affiché dans la fenêtre de serproxy : fermez toutes vos applications, recommencez – une de vos applications monopolise le port COM3.
• Le débuggueur reste bloqué à onSocketConnect : Firmata 2.0 n’est pas correctement flashé sur la carte. On la débranche de l’USB, on rebranche, on reflashe depuis l’IDE Arduino. Si ça ne suffit pas, vérifiez la vitesse en bauds définie dans serproxy.cfg, Firmata nécessite 57600.
• ma carte a l’air morte : le fusible est déclenché, votre circuit est mal monté. On refait le circuit, on débranche, on rebranche.
]]> http://www.entremidietdeux.com/interagir-avec-un-micro-controleur-via-usb-en-as3/feed/ 0 http://www.entremidietdeux.com/remplacer-l%e2%80%99eventdispatcher-par-les-signals/ http://www.entremidietdeux.com/remplacer-l%e2%80%99eventdispatcher-par-les-signals/#comments Sun, 07 Nov 2010 16:15:50 +0000 fh http://www.entremidietdeux.com/?p=29 Continuer la lecture →]]> Cet article vous présente la librairie Signals de Robert Penner, qui a vocation à remplacer la couche événementielle de Flash.

1) l’EventDispatcher d’Adobe

Actuellement, les applications AS3 se structurent en objets, qui communiquent par des événements (aka. “events”). On utilise les objets par défaut de l’API Flash (MovieClip, Sprite, etc), on en ajoute parfois selon le projet, et on fait communiquer tout ça par des events personnalisés toujours selon le projet. Développons donc tout ceci dans un petit rappel.

a) Le cas des composants visuels

Soit un type Foo, héritant de MovieClip, défini par la classe Foo suivante :

[as3]
package components
{
import events.FooEvent;

import flash.display.MovieClip;
import flash.events.MouseEvent;

public class Foo extends MovieClip
{
public function Foo()
{
graphics.beginFill(0×000000, 1);
graphics.drawCircle(0, 0, 5);
graphics.endFill();

addEventListener( MouseEvent.CLICK, onClick );
}

private function onClick( e : MouseEvent ) : void
{
dispatchEvent( new FooEvent(FooEvent.FOO) );
}
}
}
[/as3]

J’ai ici un composant visuel héritant de MovieClip, dispatchant un événement FooEvent au clic (ce qui est rigoureusement inutile). Si ce composant est capable de dispatcher via la méthode dispatchEvent, c’est que cette méthode est le résultat de la longue chaîne d’héritage suivante :

Foo < MovieClip < Sprite < DisplayObjectContainer < InteractiveObject < DisplayObject < EventDispatcher

On a défini à côté, dans une classe FooEvent clairement séparée, notre événement personnalisé :

[as3]
package events
{
import flash.events.Event;

public class FooEvent extends Event
{
public static const FOO : String = ‘foo’;

public function FooEvent( type : String,
bubbles : Boolean = false,
cancelable : Boolean = false )
{
super(type, bubbles, cancelable);
}
}
}
[/as3]
On en conclut donc que les composants visuels sont capables de dispatcher des événements grâce au fait qu’ils héritent indirectement de la classe EventDispatcher.

b) Le cas des composants non-visuels

Soit cette fois-ci un type Bar, défini par la classe suivante :

[as3]
package components
{
import events.FooEvent;

import flash.events.EventDispatcher;

public class Bar extends EventDispatcher
{
public function Bar()
{

}

public function emitFooEvent() : void
{
dispatchEvent( new FooEvent(FooEvent.FOO) );
}
}
}
[/as3]

On voit que pour pouvoir émettre un événement, on est obligé d’hériter directement cette fois-ci de l’EventDispatcher. En effet, notre objet n’héritant de personne, on ne peut profiter d’un héritage indirect, donc on amène explicitement cette héritage.

c) Le cas des écouteurs

Les objets écoutant Foo ou Bar, utilisent une syntaxe de ce type :

[as3]
// notez l’import de FooEvent
import components.Bar;
import events.FooEvent

var bar : Bar = new Bar();
bar.addEventListener( FooEvent.FOO, onFoo );

// notez l’argument typé FooEvent du handler onFoo
function onFoo( e : FooEvent ) : void
{
// …
}
[/as3]

2) Critique du modèle actuel

Le modèle actuel est plutôt propre à la lecture, respecte les standards actuels et reste relativement simple. Mais on peut faire mieux, puisque avec un peu de recul, des failles assez gênantes apparaissent :

• “composition vs. héritage” : on voit que les fonctionnalités événementielles sont systèmatiquement héritées, or l’héritage est à éviter en P.O.O.
• les événements n’apparaissent pas dans l’interface de la classe : en P.O.O., une classe est toujours définie par une interface. On code « contre une interface et non contre une implémentation ». Hors avec le système d’EventDispatcher, à aucun moment les Events dispatchés par une classe n’apparaissent en clair – on ne peut avoir que des dispatchEvent() noyés dans le code d’implémentation.
• “boiler-plate code” : la syntaxe est longue, et pourtant une des plus courantes à taper sur un projet, même de petite taille
• nécessite la définition d’une classe FooEvent : on est obligé de définir, allouer de la mémoire, et instancier cette classe héritant d’Event pour pouvoir bosser proprement.

3) AS3 Signals, une alternative réussie

Sur ces bases, Robert Penner a développé une alternative open-source à l’EventDispatcher, la librairie AS3 Signals. Il avait deux objectifs : la performance, et la beauté du code. Il a donc fait l’inverse d’Adobe :

• utilisable par composition,
• syntaxe claire et concise,
• pas de classe Event à définir.

AS3 Signals se télécharge ici, sous forme de .SWC en cliquant sur “downloads”, ou sous forme de sources via Git.

a) syntaxe générale

Adaptons notre classe Bar pour qu’elle utilise, non pas l’EventDispatcher, mais un Signal, et analysons la syntaxe :

[as3]
package components
{
import org.osflash.signals.Signal;

public class Bar
{
public var foo : Signal;

public function Bar()
{
foo = new Signal();
}

public function emitFooSignal() : void
{
foo.dispatch();
}
}
}
[/as3]

On constate que la classe Bar n’hérite plus de personne, et ça c’est bien. On constate aussi le dispatch est réduit à sa plus simple expression, et ça c’est encore mieux.

Jetons un oeil du côté d’un objet écoutant une instance de Bar via un Signal :

[as3]
import components.Bar;

var bar : Bar = new Bar();
bar.foo.add( onFoo );

function onFoo() : void
{
// …
}
[/as3]

Pour le retrait des écouteurs, la syntaxe est toute aussi simple :

[as3]
bar.foo.remove( onFoo );
[/as3]

On peut même, et c’est un atout majeur, retirer l’ensemble des écouteurs en une instruction :

[as3]
bar.foo.removeAll();
[/as3]

Enfin, un peu de « syntactic sugar », pour les écouteurs à usage unique, le retrait peut être automatisé par :

[as3]
bar.foo.addOnce(onFoo);
[/as3]

b) passage de valeurs via un Signal

Nous allons maintenant passer des données entre Bar et son écouteur via un Signal. Avec le modèle classique de l’EventDispatcher, ça nous obligerait à éditer FooEvent, pour lui rajouter une propriété fooEvent.baz. Essayons d’arriver à un résultat similaire via un Signal :

[as3]
package components
{
import org.osflash.signals.Signal;

public class Bar
{
public var foo : Signal;

public function Bar()
{
foo = new Signal();
}

public function emitFooSignal() : void
{
foo.dispatch(‘baz’, ‘quux’);
}
}
}
[/as3]

La méthode Signal.dispatch accepte un nombre N d’arguments, quel que soit leur type. Il suffit de passer directement la/les valeurs, pour qu’elles soient accessibles côté écouteur, dont nous modifions le code en ce sens :

[as3]
import components.Bar;

var bar : Bar = new Bar();
bar.foo.add( onFoo );

function onFoo( baz : String, quux : String ) : void
{
// …
}
[/as3]

On notera que le type des arguments baz et quux est préservé, assurant la sécurité habituelle à la compilation.

L’EventDispatcher passe lui systématiquement une instance « complète » d’Event, avec notamment la propriété Event.target, particulièrement utilisée sous sa forme MouseEvent.currentTarget pour de la détection d’interaction utilisateur. Ce passage d’un Event est implicite et systématique. Sous Signals, il est explicite, c’est au développeur de passer ce dont il a besoin – car chaque Event.target inutilisé, c’est un peu de mémoire occupée… Par exemple :

[as3]
// au sein de mon composant visuel FooComponent
backToHomeClick.dispatch( this );
[/as3]

[as3]
// côté écouteur, on reçoit bien l’émetteur, typé correctement,
private function onClickDetected( target : FooComponent ) : void
{
trace(target.name);
}
[/as3]

On notera qu’il n’est pas nécessaire de caster target vers son type original, contrairement à l’EventDispatcher (var _target : FooComponent = e.target as FooComponent).

c) cas d’événements multiples

Dans le cas d’une classe diffusant plusieurs événements de types différents, on créera plusieurs Signals distincts, prenons l’exemple d’une classe plus complexe, par exemple une couche d’abstraction pour l’API Facebook AS3 :

[as3]
package components
{
import org.osflash.signals.Signal;

public class FacebookService
{
public var authenticationComplete : Signal;
public var authenticationFail : Signal;
public var friendsListComplete : Signal;
public var friendsListPhotosComplete : Signal;

public function FacebookService()
{
// …;
}

public function authenticate(…) : void
{
// …;
}

// …
}
}
[/as3]

Les Signals sont ensuite écoutés séparément, de la même manière que décrit ci-dessus, via la méthode publique Signal.add();

[as3]
fbService.authenticationComplete.add( onAuth );
fbService.authenticationFail.add( onAuthFail );
fbService.listFriendsComplete.add( onFriends );
fbService.listFriendsPhotos.add( onFriendsPhotos );
[/as3]

4) Pour finir

Au-delà du gain en terme de syntaxe, la suppression de l’héritage, de la classe Event personnalisé induit évidemment un gain en terme de performance. Et ce gain est énorme : http://alecmce.com/as3/events-and-signals-performance-tests

Vu le gain de perfs, et de confort pour le développeur, Signals s’est imposé outre-Atlantique en quelques mois. On trouve maintenant par exemple un add-on Signals pour Robotlegs, transformant ce micro-framework déjà véloce en bête de course.

]]> http://www.entremidietdeux.com/remplacer-l%e2%80%99eventdispatcher-par-les-signals/feed/ 6 http://www.entremidietdeux.com/creer-une-application-multi-utilisateurs-avec-as3-et-node-js/ http://www.entremidietdeux.com/creer-une-application-multi-utilisateurs-avec-as3-et-node-js/#comments Sun, 07 Nov 2010 12:45:11 +0000 fh http://www.entremidietdeux.com/?p=10 Continuer la lecture →]]> Amusons-nous un peu avec node.js, le plus trendy des projets open-source. Traditionnellement, les serveurs utilisés par les applications multi-utilisateurs temps-réel sont soit des solutions commerciales ou open-source (SmartFox, ElectroServer, Flash Media Server, Red5, etc), soit des développements propriétaires, réalisés dans des langages susceptibles de supporter des charges importantes (Java, C++, Python Stackless pour Eve Online, Erlang pour le chat Facebook). Les serveurs sont généralement multi-threadés et synchrones : un thread est alloué par client connecté, avec un segment de pile dédié, le tout reste en mémoire pendant la durée de connexion du client au serveur – à l’exception d’Erlang et de Stackless justement.

Pourquoi node.js ?

Node.js est un projet open-source basé sur l’interpréteur Javascript V8 de Google. C’est un interpréteur Javascript côté serveur, auquel a été ajoutée une API réseau de bas niveau dotée par exemple des fonctionnalités HTTP, sockets, UDP. C’est donc un toolkit destiné à concevoir des serveurs. Il utilise Javascript comme langage de script, un langage simple, proche de l’AS3, et donc rapide à assimiler pour le développeur Flash de base. Tout le monde connait quelques bouts de Javascript.

Node.js possède deux caractèristiques supplémentaires qui font tout son intérêt :

• la programmation évènementielle : 100% basé sur les gestionnaires d’évènements, en node.js “tout est évènement”. Hors de la durée de vie d’un évènement, le serveur « dort ».
• son architecture interne : comme le serveur Web nginx, il n’utilise pas une thread par client, donc il gère très bien les problèmes de concurrence, ce qui en fait l’outil idéal pour les problématiques de serveurs multi-utilisateurs temps-réel. Chose à savoir, Nginx s’est hissé en un an au 3ème rang des serveurs Web les plus déployés. Le micro-threading, c’est l’avenir.

Quelques liens complémentaires :

• Le site officiel comporte un Hello World assez simple : Hello World.
• Un excellent article de vulgarisation en français : le blog d’Inovia.
• Les sources d’un serveur de chat complet par l’auteur de node.js, qui m’ont servies de base de travail : node_chat sur GitHub.
• La documentation complète de l’API comporte d’autres exemples de serveurs.

Installation de node.js

Les pré-requis pour pouvoir installer node.js sont les suivants :

• node.js ne tourne que sous Linux,
• gcc et make doivent être installés
  sudo apt-get install gcc
• pas de proxy sur le(s) port(s) utilisé(s),
• le(s) port(s) utilisés doivent être ouverts côté routeur/firewall et redirigés vers le serveur.
• si vous ne disposez pas encore d’un serveur : un PC sous Ubuntu suffit. Il n’est PAS nécessaire d’installer Apache/MySQL/PHP, seul les packages git-core, open-ssh, make et gcc sont nécessaires.

Commençons par récupérer les sources via Git :

$ mkdir ~/temp
$ git clone git://github.com/ry/node.git
$ cd node


Nous voilà munis des dernières sources. On compile ces sources via la manière traditionnelle :

$./configure


L’absence d’OpenSSL provoque un warning, mais n’est pas bloquante.

$ make


La compilation dure 5-10 minutes sur un Core Quad, puisque V8 est inclus dans les sources.

$ sudo make install


Nous pouvons maintenant vérifier que tout fonctionne correctement :

$ node -v
v0.1.103


Node et ses dépendances sont installés dans /usr/local/bin.

Prise en main de node.js : servir proprement le policy file

Depuis Flash Player 9, toutes les applications requérant par la suite un accès vers un socket distant initie l’échange client-serveur en interrogeant le serveur sur le port 843, en attendant en retour un fichier de sécurité autorisant ou non l’accès.

Typiquement, ce genre de chose est intégré aux serveurs commerciaux, ou alors il est requis d’installer le serveur de policy file proposé par Adobe. Commençons par développer notre propre serveur de Policy File, histoire de tâter un peu le terrain.

Voici la source Javascript du serveur :

[javascript]
// importation des modules nécessaires
var net = require(‘net’),
path = require(‘path’),
fs = require(‘fs’);

// création du serveur
net.createServer( function (socket) {

// réglage de l’encodage sur UTF-8
socket.setEncoding(« utf8″);

// on forge le path complet de notre fichier .xml
var securityFileName = path.join( process.cwd(), ‘policy.xml’ );

// s’il existe
path.exists( securityFileName, function(exists) {

fs.readFile( securityFileName, « binary », function( err, file ) {

// on l’envoie au client par le socket sur le port 843
socket.write( file, « binary » );

// on ferme le socket
socket.end();

});

});

}).listen( 843 );
[/javascript]

On sauve ça dans un fichier .js, par exemple node-security.js. On crée ensuite dans le même dossier, le fichier policy.xml qui contient notre policy d’accès, ici on autorise uniquement le port 8888, sur lequel tournera notre serveur de jeu :

Puis on lance le serveur en tâche de fond :

$ sudo node node-security.js &
[1] 2740


On peut maintenant interroger le serveur depuis une autre machine à travers Internet, en utilisant l’utilitaire de bas-niveau Telnet, par exemple sous Windows, Démarrer > Exécuter > telnet :

Microsoft Telnet> o 88.12.xx.xx 843


On voit s’afficher notre policy file, puis le socket se fermer : notre .swf est maintenant autorisé à continuer.

Pour stopper le serveur, on tue le process par son PID :

$ sudo kill 2740


Ce serveur de policy file devra tourner en tâche de fond durant tout le reste du tutoriel.

Dans la pratique : une application de chat

1) côté serveur

Nous voilà prêts désormais pour développer un serveur de chat basique. Pour l’instant, nous pouvons ouvrir un socket par client, puis y envoyer des données :

[javascript]
net.createServer( function (socket) {
socket.write(‘foo’);
});
[/javascript]

Nous allons avoir besoin de recevoir des données : le principe d’un serveur de chat est le suivant :

• le serveur reçoit une donnée d’un client,
• il renvoie cette donnée vers tous les clients connectés.

[javascript]
net.createServer( function (socket) {

socket.write(‘foo’);
socket.on( « data », function (data) {

// traitement des données lues

});

});
[/javascript]

On constate ici la similitude avec l’Actionscript : on traite un évenement par un handler on( , ).

Nous aurons ici 2 types de messages : /join à la connexion, /msg lorsque c’est un message à afficher. Le tout est véhiculé sous forme de chaîne UTF-8.

[javascript]
net.createServer( function (socket) {

socket.setEncoding(‘utf8′);
socket.on( « data », function (data) {

if( data.substring( 0, 5 ) == ‘/join’ ) {

// connexion d’un nouvel utilisateur
// …

}

if( data.substring( 0, 5 ) == ‘/msg’ ) {

// message à renvoyer à tous les utilisateurs
// …

}

});

});
[/javascript]

Il nous reste à garder une liste des sockets ouverts, afin de pouvoir leur dispatcher les messages reçus. On utilisera un simple Object {…}, qui fonctionne de la même manière en JS et en AS.

Voici le code complet du serveur, sauvons-le sous node-chat-server.js

[javascript]
// importation des modules necessaires
var net = require(‘net’);
var sessions = {};

// creation du serveur
var server = net.createServer( function (socket) {

socket.setEncoding(‘utf8′);

// handler de données entrantes
socket.on( « data », function (data) {

// l’utilisateur rejoint pour la 1ère fois
if( data.substring( 0, 5 ) == ‘/join’ ) {

// on loggue côté serveur
console.log(‘[join] ‘ + data.substring( 6, data.length ) );

// on stocke une référence vers le socket dans l’objet
var session = { socket: socket,
nick: data.substring( 6, data.length ) };
sessions[ Math.floor( Math.random() * 99999999999 ).toString() ] = session;
console.log(sessions);

}

// l’utilisateur envoie un message
if( data.substring( 0, 4 ) == ‘/msg’ ) {

// on loggue côté serveur
console.log(‘[msg] ‘ + data.substring( 5, data.length ) );

// on parcourt l’objet à la recherche du nickname correspondant
for ( var i in sessions ) {
var session = sessions[i];
if ( session.socket === socket ) {
var nick = session.nick;
}
}

// on parcourt l’objet et envoie le msg à tous les sockets
for ( var i in sessions ) {
sessions[i].socket.write( nick + ‘ : ‘ + data.substring( 5, data.length ) );
}
}
});

// handler de déconnexion
socket.on(« end », function () {

// on supprime la référence vers le socket dans l’objet
for ( var i in sessions ) {
var session = sessions[i];
if ( session.socket === socket ) {
socket.end();
delete sessions[i];
}
}

});

}).listen( 8888 );
[/javascript]

2) côté client

Il nous reste à développer un petit client de chat en AS3, qui aura un rôle très limité :

• Envoyer /join dans le socket à la connexion de l’utilisateur,
• Envoyer /msg dans le socket au clic sur le bouton ,
• Afficher dans une zone de texte les messages reçus du serveur.

Commençons par instancier un Socket :

[as3]
// creation du socket
_socket = new Socket();
_socket.addEventListener( Event.CONNECT, onConnect );
_socket.addEventListener( ProgressEvent.SOCKET_DATA, onData );
…
[/as3]

Nous écoutons principalement 2 évenements :

• onConnect : émis lorsque la connexion au serveur a été initiée sans encombre.
• onData : émis à la réception d’une donnée depuis le serveur.

2.a) l’envoi de données

[as3]
_socket.writeUTFBytes( ‘/msg ‘ + _msgInput.text );
_socket.flush();
[/as3]
La première méthode est assez claire d’elle-même, on écrit dans le socket une chaîne UTF-8. Attention à bien appeler la méthode Socket.flush(), qui force l’envoi effectif des données (sinon, il ne se passera rien).

2.b) la réception de données

[as3]
var read : String = _socket.readUTFBytes(_socket.bytesAvailable);
[/as3]
C’est cette méthode qui permet de lire des  bytes depuis un Socket, et les converti en String à la volée

2.c) la source compléte du client Flash

[as3]
package
{
import com.carlcalderon.arthropod.Debug;

import com.bit101.components.TextArea;
import com.bit101.components.InputText;
import com.bit101.components.Text;
import com.bit101.components.PushButton;
import com.bit101.components.Label;

import flash.display.Sprite;
import flash.net.Socket;
import flash.events.Event;
import flash.events.IOErrorEvent;
import flash.events.SecurityErrorEvent;
import flash.events.ProgressEvent;
import flash.events.MouseEvent;

/**
* …
* @author
*/
public class Application extends Sprite
{
private var _loginInput : InputText;
private var _loginButton : PushButton;
private var _sendButton : PushButton;
private var _msgInput : InputText;
private var _msgWindow : TextArea;

private var _login : String;

private var _socket : Socket;

public function Application() : void
{
Debug.clear();

// creation de l’U.I.
_loginInput = new InputText( this, 150, 250, « guest » + Math.floor( Math.random() * 10000 ) );
_loginButton = new PushButton( this, 350, 250, « connexion », onLogin );

// creation du socket
_socket = new Socket();

_socket.addEventListener( Event.CLOSE, onClose );
_socket.addEventListener( Event.CONNECT, onConnect );
_socket.addEventListener( IOErrorEvent.IO_ERROR, onError );
_socket.addEventListener( SecurityErrorEvent.SECURITY_ERROR, onSecurityError );
_socket.addEventListener( ProgressEvent.SOCKET_DATA, onData );
}

private function onLogin( e : MouseEvent ) : void
{
// suppression de l’U.I. de login
removeChild(_loginInput);
removeChild(_loginButton);

_login = _loginInput.text;

_loginInput = null;
_loginButton = null;

// creation de l’U.I. du chat
_msgWindow = new TextArea( this, 5, 5 );
_msgWindow.width = 780;
_msgWindow.height = 550;
_msgInput = new InputText( this, 5, 570, « taper un message ici » );
_msgInput.width = 670;
_sendButton = new PushButton( this, 680, 570, « envoyer », onSend );

// connexion au serveur
_socket.connect( ‘xxx.xxx.109.181′, 8888 );
}

// envoi d’un message suite à un clic utilisateur
private function onSend( e : MouseEvent) : void
{
_socket.writeUTFBytes( ‘/msg ‘ + _msgInput.text );
_socket.flush();
_msgInput.text =  »;
}

private function onClose( e : Event ) : void
{
Debug.log( ‘onClose’ );
}

// connexion au socket effectuée
private function onConnect( e : Event ) : void
{
Debug.log( ‘onConnect’ );

_socket.writeUTFBytes( ‘/join ‘ + _login );
_socket.flush();
}

private function onError( e : IOErrorEvent ) : void
{
Debug.error( ‘onError’ );
}

private function onSecurityError( e : SecurityErrorEvent ) : void
{
Debug.error( ‘onSecurityError’ );
}

// réception de données depuis le socket
private function onData( e : ProgressEvent ) : void
{
Debug.log( ‘onData’ );
_msgWindow.text += _socket.readUTFBytes(_socket.bytesAvailable) + « \n »;
}

}

}
[/as3]

Conclusion

On lance maintenant le serveur via les commandes habituelles :

$ node node-chat-server.js &


On lance ensuite le client Flash depuis une autre machine, et voilà, ça marche.

En à peine quelques lignes de code Javascript simple et basique, voilà un serveur de chat rapide et efficace. A partir de cette base, voici quelques améliorations possibles et pistes à creuser :

• Les sources d’un serveur de chat complet par l’auteur de node.js sont une mine d’or : node_chat sur GitHub.

• les messages sont encodés sous forme de chaînes UTF-8. C’est lourd et lent. Pour un jeu online, il serait préférable d’utiliser un format binaire. En supprimant la ligne socket.setEncoding(‘utf8′);, l’argument data reçu ne sera plus une chaîne mais un objet Buffer, particulier à node.js.

• un serveur de jeu online doit pouvoir communiquer avec une base de données. Sachant que MySQL tourne sur socket (mysql.sock), il est relativement simple de communiquer avec.

]]> http://www.entremidietdeux.com/creer-une-application-multi-utilisateurs-avec-as3-et-node-js/feed/ 2