La Fabrick » Tutoriels

Object to XML to Object : conversion XSD

Fabien — Mon, 14 Dec 2009 21:38:47 +0000

Utiliser les schéma de déclaration XSD, s’avère souvent fort utile. Plus que l’autocompletion sur vos fichiers XML, l’apport des XSD se trouve avant tout dans le fait de qualifier et de valider vos fichiers. Dans Flex, bien que caché au fin fond du package rpc, la mécanique de lecture et de conversion XSD est bien là. Nous allons voir comment l’utiliser, et convertir vos objets AS3 vers XML (et vice versa), en suivant ces schémas de définition.

Pourquoi utiliser une XSD?

Pour ma part, ces quelques raisons (et pour vous certainement plein d’autres raisons)

Elle valide vos XML : parce que vous définissez en amont la structure de vos fichiers, une définition XSD permet de les valider;
Parce que vous avez besoin de plusieurs écritures différentes d’un même jeu de donnés;
Parce que, comme tout bon dèv, vous êtes fainéant…
…et le fait que le programme valide tout et fait tout, tout seul, en suivant des règles normées ça vous va bien.
Ca fait toujours bien d’avoir des fichiers XSD dans vos sources : ça envoie de la rosette, et vous pouvez vous la péter grave.
…

Dans un usage Flex, l’objectif serait de pouvoir transformer nos objets AS en XML, et l’inverse, via les schémas de définitions. Ça tombe bien ! C’est ce qu’on va faire.

Où tu te caches XSD ?!

Dans la plupart des langages, nous avons la possibilité de discuter avec notre serveur en utilisant le protocole SOAP, basé sur XML. En utilisant ce protocole, nos objets sont “transformés” en XML, et transmis vers notre serveur. L’opération inverse existe lors de réception de données.
Mais pourquoi je vous parle de ça? Tout simplement parce que tout langage faisant du SOAP (ou du web service), à besoin de valider et de convertir de manière automatique les objets. Et je vous le donne en mille, ce sont les définitions XSD qui entrent en jeux (souvent ).

La mécanique XSD est utilisée, en interne dans Flex, pour l’encodage et le décodage d’objet SOAP ou WSDL. Ces classes, exclues du framework (vous n’y avez pas accès directement avec l’autocomplétion), se trouvent dans le package mx.rpc.xml.*.

Et c’est bien dommage que ces classes soit exclues ! Selon moi, elles seraient bien plus utiles ouvertes, documentées, et dans un package plus global comme flash.xml par exemple (flash.xsd ou flash.xml.xsd… ça pourrait être cool !).

Car vous allez le voir, il est relativement simple d’utiliser cette partie de Flex, pour un usage personnalisé du XML, en dehors du contexte RPC.

Des groupes, des geeks, des bidules

Donc c’est parti pour l’exemple. Je ne me casse pas la tête, et vous propose un biniou qui aura 3 éléments : des groupes, des gens (geek forcement), et des bidules… Je n’étais pas inspiré sur le 3ème éléments, mais il m’en fallait un….

XML et la définition XSD

Nous avons une infinité d’écriture XML possible, comme celle-ci :

Ou celle là :

...

Ou un mélange à votre sauce, vous faites bien comme vous voulez !

Nous allons donc écrire notre XSD, qui va définir le XML définit ci-dessus, celui qui utilise pleins d’attributs. Je prend celui là parce que la sortie XML est moins longue…. et mon article gagnera quelques lignes…. En ce moment mes articles sont un peu trop pépère… Ca doit être l’approche des fêtes.

Bref !

Le but est de réaliser une XSD la plus complète possible, ou toutes les parties sont typées (SimpleType ou ComplexeType). C’est important pour la suite, car chaque type sera “mappé” avec la classe ActionScript qui lui correspond.

Dans notre exemple, nous avons 3 collections (groups geeks, stuffs) et 3 éléments (group, geek, stuff)… D’accord je ne me suis pas foulé les doigts sur ce coup là !

Le schéma XSD n’est finalement qu’un fichier XML standard :

L’élément principale, le noeud “”, est la base de notre schéma. Le type correspondant va s’appeler groupsCollectionType.

La version actionScript de ce type groupsCollectionType serait un Array ou ArrayCollection (ou tout autre type de collection d’objet).
groupsCollectionType est une séquence, un réceptacle de 0 à n éléments de type group (le nombre d’instances minimum et maximun est défini par minOccurs et maxOccurs).

Le type group est composé comme suit :

On retrouve le noeud geeks, unique, mais non obligatoire (minOccurs= »0″ maxOccurs= »1″), qui sera défini dans un type geeksCollectionType de la même manière que groupsCollectionType.
Les attributs du noeud sont placé à la suite de la séquence d’éléments. Ils peuvent être requis ou optionnel, définit par l’attribut use. On peut aussi le définir “prohibited” même si je ne vois pas vraiment l’intérêt…

Et on continue comme cela, en rentrant en profondeur dans nos différent objets. La syntaxe n’est pas compliquée, il suffit de se pencher un peu sur les spécifications de la W3C.

Vous trouverez ici la XSD complète de notre exemple.

Côté ActionScript

Nous avons besoin de 3 objets, qui correspondent aux 3 types d’éléments de notre XML : des groupes de Geek, des Geeks, des Stuffs.

Là, rien de plus basique.

La classe GeekGroup : avec une propriété groupName, et une collection geeks (les geeks membres du groupe)
La classe Geek : avec une propriété firstName, et une collection stuffs (les bidules du geek)
La classe Stuff : avec une propriété name, le nom du bidule

Vous vous rendez compte, tout d’un coup, que je ne vous ai absolument rien appris dans ce paragraphe. Passons à la suite.

Les classes de gestion XSD

Nous avons une XSD et des objets AS prêts à être convertis. Regardons de plus près les classes exclues dont nous avons besoin:

mx.rpc.xml.SchemaTypeRegistry : cette classe est une sorte de dictionnaire, ou l’on référence les différents types du schéma XSD, avec leurs classes actionScript associées.
mx.rpc.xml.XMLDecoder : la classe qui permet de décoder une source XML, en suivant la XSD, vers un object typé actionScript.
mx.rpc.xml.XMLEncoder : la classe qui permet d’encoder un objet AS en un fichier XML, en suivant la définition XSD.
mx.rpc.xml.Schema : la classe contenant le schema XSD chargé.
mx.rpc.xml.SchemaManager : point central du système, cette classe est utilisée par l’encodeur et le décodeur. Elle possède une référence au schéma (elle peut d’ailleurs contenir plusieurs schéma XSD), et utilise les références de classes et de type XSD enregistrés dans mx.rpc.xml.SchemaTypeRegistry.

Votre object en XML, via XSD

Dans un premier temps, il nous faut charger la définition XSD via un URLLoader :

var urlLoader : URLLoader = new URLLoader();
urlLoader.addEventListener( Event.COMPLETE, onLoadXsdComplete );
urlLoader.load( new URLRequest( "geek.xsd" ) );

A la réception de la XSD, nous initialisons la classe Schema et le SchemaManager :

var _schema:Schema = new Schema();
var _schemaManager:SchemaManager = new SchemaManager();

_schema.xml = XML( urlLoader.data );
_schemaManager.addSchema( _schema );

Nous ajoutons la référence du manager de schéma dans nos objets d’encodage/décodage :

var _xmlDecoder:XMLDecoder = new XMLDecoder();
var _xmlEncoder:XMLEncoder = new XMLEncoder();

_xmlDecoder.schemaManager = _schemaManager;
_xmlEncoder.schemaManager = _schemaManager;

Ensuite, nous référençons les types contenus dans la XSD, avec les classes AS correspondantes :

var _schemaTypeRegistry : SchemaTypeRegistry;
_schemaTypeRegistry = SchemaTypeRegistry.getInstance();

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupsCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "groupType"), GeekGroup);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geeksCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "geekType"), Geek);

_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffCollectionType"), ArrayCollection);
_schemaTypeRegistry.registerClass(
    new QName(_schema.targetNamespace.uri, "stuffType"), Stuff);

Enfin, nous récupérons notre XML tout bien valide, image de l’objet targetObject, via l’encodeur XML (il faut préciser le nom du noeud “root” de la XSD) :

var xmlList : XMLList = _xmlEncoder.encode( targetObject,
    new QName( _schema.targetNamespace.uri, "groups") );

Super simple.

D’un XML vers un Object

C’est magique, c’est tout pareil ! au lieu d’utiliser XMLEncoder, on utilise XMLDecoder, et on change la référence de l’objet par notre XML :

var obj : ArrayCollection = _xmlDecoder.decode( myXml,
    new QName( _schema.targetNamespace.uri, "groups") ) as ArrayCollection;

Automatisation

Je vous propose un set de classes pour faire tout ça de manière automatique.

XSDConverter : un convertisseur XML via XSD.
2 méthodes :
- importFromXml( xml : *, xsdUrl : String, schemaTypes : Vector. = null ) : void
- exportToXml( target : Object, xsdUrl : String, schemaTypes : Vector. = null ) : void
En paramètre de ces méthodes :
- la source : Object pour l’exportation, une String, un XML ou un XMLList pour l’importation;
- xsdUrl : l’url de la xsd a charger;
- schemaType : une collection (Vector) d’objet de type XSDType, définissant le mapping entre les types XSD, et les classes référentes AS.
XSDEvent : l’évènement diffusé par XSDConverter (importSuccess, exportSuccess et conversionError (en cas de problème de conversion ou de chargement de la XSD ) ).
XSDType : définition d’un type XSD, avec la classe AS associée.

Un petit exemple est disponible là, avec les sources sous ce lien.

Et donc….

… vous pouvez vous dire que “Ahh ! Maintenant que mes données sont automatiquement transformées en XML, je me sens mieux. Et comme j’ai gagné plein de temps, ba du coup je peux lire des articles fort intéressants comme ceux concernant le skinning ou les primitives dans Flex4. De toutes façons y’a trop de monde à la Fnac pour finir mes cadeaux….”

Autres articles sur le même sujet

Flex4 : skin et primitives

Fabien — Fri, 04 Dec 2009 16:52:36 +0000

Dans le dernier article, nous avons fait un petit tour d’horizon du nouveau système de skin de Flex4. J’ai brièvement présenté EazeElement que j’utilise dans l’article. Nous allons maintenant rentrer un peu plus profondément dans les primitives, qui vous permettent de créer vos propres formes et autres éléments graphiques personnalisés.

Retour sur les primitives

Dans Flex4, une Skin est une agglomération d’éléments graphiques, définis avec un type de ligne, de fond, et des filtres. L’objet graphique final est une superposition de rectangles, de lignes, d’ellipses, d’images, de formes complexes.

Intéressons nous à celles qui utilisent directement l’API de dessin : Rect, Ellipse, Line, Path

Comment ça marche?

L’architecture des primitives utilisant l’API de dessin est la suivante :

Les classes de bases :

GraphicElement : la base des primitives. Cette classe définit les tailles et positionnement de l’objet dans l’espace, avec ses contraintes de position. Les getters protégés drawX et drawY, utilisés par toutes les primitives, renvoient la position réelle en x et y de l’objet.
StrokedElement : définit le Stroke (interface mx.graphics.IStroke), l’apparence de la ligne, de la primitive. La base des méthodes de dessin est présente : beginDraw, draw, endDraw. La méthode beginDraw applique le style du Stroke dans l’élément graphique Graphics de la primitive.
FilledElement : définit le Fill (interface mx.graphics.IFill), l’apparence du fond, de la primitives. La méthode beginDraw prépare l’objet graphique en appliquant la ligne Stroke et le fond Fill. A ce niveau, la méthode draw n’effectue aucun tracé.

Les primitives :

Line : (extension de StrokedElement) dessine une ligne, passant par 2 points (xFrom/yFrom et xTo/yTo). Si votre ligne est encadrée dans des contraintes top, bottom, left, right; la ligne dessinée sera une diagonale, respectant les contraintes top/left et bottom/right;
Ellipse : (extension de FilledElement) dessine une ellipse définie par ses contraintes de positionnement;
Rect : (extension de FilledElement) dessine un rectangle défini par ses contraintes de positionnement. Sa particularité est de pouvoir définir des rayons de courbure globaux (radiusX/radiusY), ou localisés aux angles du rectangle (topLeftRadiusX/topLeftRadiusY, bottomLeftRadiusX/bottomLeftRadiusY, …).
Path : (extension de FilledElement) dessine une forme complexe, définie dans une propriété data. Cette source utilise la syntaxe SVG.

Digression : Définition et obtention d’un “data Path”

Le “data source” d’une primitive Path est définit par un code, identique à celui utilisé dans le format vectoriel SVG. Ce code ressemble a celui-ci :
 M 8 4 C 8 4 15 4 15 4 L 15 0 L 27 8 L 15 15 L 15 11 L 8 11 L 8 11 L 8 11 L 0 11 C 0 11 0 11 0 11 C 0 7 3 4 8 4 Z

Il représente une flèche avec un bord arrondi, d’une largeur de 27 pixels, et une hauteur de 15 pixels.

Fonctionnement du code

c’est une succession de commandes (définies par des lettres), et de positions de points (les chiffres) en pixels utilisées par la commande.

Les différentes commandes sont :

M : Move, déplacement de la ligne vers le point définit par le couple de chiffres suivant. Exemple : “M 8 4” déplace le point courant de la ligne à la position x=8 et y=4. C’est toujours la première commande du code.
L : Line, création d’une ligne, avec comme point de destination le couple de chiffres suivant. Exemple “ L 15 11” crée la ligne depuis le point précédent, vers le point x=15 et y 11.
H : Horizontal Line, identique à la commande L, à la différence que seul le point de destination x est nécessaire. Exemple : “H 15” construit une ligne horizontale depuis le point précédent, vers le point x=15.
V : Vertical Line, identique à la commande H, en vertical.
Q : Quadratic Bezier, création d’une ligne courbe, a partir du précédent point, à destination du point définit par le dernier couple x/y, et passant par le point de contrôle définit par le premier couple x/y. exemple : “Q 15 11 20 22” la ligne est créée entre le point précédent et le point x=20, y=22, en passant par le point de contrôle x=15, y=11;
C : Cubic Bezier, identique à la commande Q, à la différence que la ligne passe par un point de contrôle supplémentaire. Exemple : “ C 0 7 3 4 8 4” la ligne est créée entre le point précédent et le point x=8 / y=4, en passant par un premier point de contrôle x=0, y=7, et un second x=3, y=4;
Z : Close, définit la fermeture de la forme. C’est aussi le dernier code du data.

Obtenir un code à partir d’une forme

La meilleur méthode pour obtenir le code de votre forme vectorielle est de passer par Fireworks. Je vous recommande fortement d’utiliser ce logiciel pour vos créations d’interface, car très complet, performant, et beaucoup plus adapté à la création graphique web que Photoshop ou Illustrator.

Fireworks, depuis la CS4, dispose d’une commande d’exportation FXG. Vous pouvez la trouver sous “Commandes” > “Exporter au format FXG”.

Il vous suffit de sélectionner votre forme, (si rien n’est sélectionné, c’est la totalité du document, y compris les calques masqué, qui sera exporté), et de lancer la commande d’exportation.

Vous obtenez un document de ce type :

Copiez le data du noeud , et utilisez le dans votre skin comme dans cette exemple :

Et maintenant?

L’idée serait de pouvoir créer des primitives, spécialisées ou non, utilisables dans un contexte de composants très précis, comme la primitive EazeElement du dernier article; ou dans une perspective plus globale, type librairie… Allons-y

Un trou dans mon Rectangle

Il peut être intéressant dans certains cas d’avoir un “trou” dans un rectangle. Pour créer par exemple une bordure qui pourrait avoir un Stroke ET un Fill. C’est ce que j’ai fais ici.

Pour obtenir un rectangle “troué” avec l’api de dessin, c’est extrêmement simple : il suffit de dessiner 2 rectangles l’un dans l’autre, à la suite : les points de vecteurs faisant partie du même chemin, cela génère l’exclusion du rectangle 2 dans le rectangle 1.

Bon c’est une méthode rapide, mais qui est suffisante pour nos besoin… Nous ne sommes pas en train de coder un outil de Pathfinding !

Dessin de rectangle

Au lieu d’utiliser les méthodes de dessin de rectangle fournies par Flex, j’utilise celle proposée par Philippe Elsass. Performante, elle m’évite de recourir au méthode de base, qui lance des contrôles de positions évitable.
Pour plus d’information sur son fonctionnement, je vous invite à vous rendre sur cette explication.

La méthode utlisée dans la librairie, que j’expose ci-après, derrière ce lien.

La primitive ExclusionRect

Donc nous avons besoin de 2 rectangles. Le premier est celui qui correspond aux contraintes de positionnement de base de la primitive. J’utilise une petite méthode getOutterVectorPoint qui me renvoie le vecteur définissant les points de ce rectangle. Le second rectangle, celui définissant la zone à exclure, à lui besoin de contraintes spécifiques, que j’ai ajouté dans la classe (innerTop, innerRight, innerLeft, innerBottom). la méthode getInnerVectorPoint remplit la même fonction que getOutterVectorPoint. Dans l’override de la méthode draw, celle qui “dessine”, les 2 rectangles sont créés l’un après l‘autre. Cela donne :

/**
 * Return the Vector of Point for the rectangle
 */
protected function getOutterVectorPoint() : Vector.
{
    var vector : Vector. = new Vector.();
    vector.push( new Point( drawX, drawY ) );
    vector.push( new Point( drawX+width, drawY ) );
    vector.push( new Point( drawX+width, drawY+height ) );
    vector.push( new Point( drawX, drawY+height ) );
    return vector;
}
/**
 * Return the Vector of Point for the inner rectangle
 */
protected function getInnerVectorPoint() : Vector.
{
    var vector : Vector. = new Vector.();
    vector.push( new Point( drawX+innerLeft, drawY+innerTop ) );
    vector.push( new Point( drawX+width-innerRight, drawY+innerTop ) );
    vector.push( new Point( drawX+width-innerRight, drawY+height-innerBottom) );
    vector.push( new Point( drawX+innerLeft, drawY+height-innerBottom ) );
    return vector;
}

/**
 * Draw the rectangle
 * @see com.lafabrick.uigfx.utils.UigfxUtils
 */
override protected function draw(g:Graphics) : void
{
    UigfxUtils.drawRoundPath( g, getOutterVectorPoint(), radius, true );

    if( enableExclusion ) {
        UigfxUtils.drawRoundPath( g, getInnerVectorPoint(), innerRadius, true );
    }
}

Utilisation

L’utilisation est très proche de celle de Rect, avec les contraintes et radius intérieur :

La classe complète de la primitive

Dessine moi une forme !

Une primitive qui me manque est celle permettant de dessiner une forme, à la manière de Path, mais en définissant un tableau de points. Quelque chose qui ressemble à ça :

Bien, mais pas suffisant.
Dans ce premier essai, les points sont définis “statiquement”. Une utilisation parfaite pour moi d’une telle primitive serait de pouvoir définir des contraintes de placement sur les points (top, verticalCenter, bottom et left, horizontalCenter, right), par rapport à la primitive.

J’ai donc fait une classe ConstraintPoint.

ConstraintPoint : un point “contraint”

Cette classe toute simple, extension de Point, dispose de propriétés de placement, en getter/setter : top, left, bottom, right, horizontalCenter, verticalCenter. Une méthode getConstraintPoint() renvoie un point x/y, calculer par rapport à une cible GraphicElement, en tenant compte des contraintes de placement. J’ai préféré avoir ce type de fonctionnement, plutôt que d’avoir le couple x/y directement modifié lors du set des différentes propriétés de contraintes.

Une primitive se dessine par rapport à son positionnement global. GraphicElement fournit les propriétés protégés drawX et drawY, qui donne les positions x/y de la primitive de manière global, par rapport à l’application.

La méthode getConstraintPoint() doit donc renvoyer le point par rapport à l’application. GraphicElement fournit tout la mécanique de calcul nécessaire, notamment l’objet postLayoutTransformOffsets, qui contient la position globale de la primitive.

La méthode en question :

public function getConstraintPoint( graphicElement : GraphicElement ) : Point
{
    var px : Number = 0;
    var py : Number = 0;

    var xOffset : Number;
    var yOffset : Number;

    if (graphicElement.displayObjectSharingMode ==
                        DisplayObjectSharingMode.OWNS_UNSHARED_OBJECT) {
        xOffset = 0;
        yOffset = 0;
    }
    else {
        xOffset = graphicElement.postLayoutTransformOffsets ?
                        graphicElement.x + graphicElement.postLayoutTransformOffsets.x : graphicElement.x;
        yOffset = graphicElement.postLayoutTransformOffsets ?
                        graphicElement.y + graphicElement.postLayoutTransformOffsets.y : graphicElement.y;
    }

    // Calcutates y position
    if( !isNaN( top ) ) {
        py = yOffset + top;
    }
    else if( !isNaN( bottom ) ) {
        py = yOffset + graphicElement.height - bottom;
    }
    else if( !isNaN( verticalCenter ) ) {
        py = ( yOffset + graphicElement.height ) / 2 + verticalCenter;
    }
    else {
        py = yOffset + y;
    }

    // Calcutates x position
    if( !isNaN( left ) ) {
        px = xOffset + left;
    }
    else if( !isNaN( right ) ) {
        px = xOffset + graphicElement.width - right;
    }
    else if( !isNaN( horizontalCenter ) ) {
        px = ( xOffset + graphicElement.width ) / 2 + horizontalCenter;
    }
    else {
        px = xOffset + x;
    }

    return new Point( px, py );
}

La classe complète ce trouve derrière ce lien.

Intéressons nous maintenant à la primitive.

Primitive PointsPath

J’utilise toujours la méthode de dessin drawRoundPath, contenu dans ma classe static UigfxUtils.

Ici, la classe étend FilledElement. Une propriété points, définit les différents points de type ConstraintPoint de la primitive. J’utilise ici un vecteur comme conteneur des points : Vector.. Le “set” de cette propriété appelle invalidateDisplayList(), afin de lancer le processus de dessin de la forme.

La méthode draw parcour le vecteur de points ConstraintPoint, appelle pour chacun sa méthode getConstraintPoint, et pousse le point dans un vecteur. C’est ce vecteur qui est utilisé par drawRoundPath.

Le code de cette mécanique :

public function get points():Vector.
{
    return _points;
}

/**
 * @private
 */
public function set points(value:Vector.):void
{
    _points = value;
    invalidateDisplayList();
}

/**
 * Draw the path
 * Drawing method is static, in UiGfxUtils
 * @see com.lafabrick.uigfx.utils.UiGfxUtils
 */
override protected function draw(g:Graphics) : void
{
    // replace points from local to global position
    var vectorPoint : Vector. = new Vector.();
    for each( var point : ConstraintPoint in points ) {
        vectorPoint.push( point.getConstraintPoint( this ) );
    }
    // launch drawing method
    UigfxUtils.drawRoundPath( g, vectorPoint, radius, true );
}

La classe PointsPath en entier

Utilisation

Reprenons l’exemple, avec cette primitive et les contraintes de placement :

La forme respecte les contraintes de placement, en fonction de l’évolution de la taille de la primitive. Amazing !
L’exemple complet (les sources au clic droit), ce cache sous ce lien.

Librairie Uigfx

Tout ce que je viens d’exposer fait partie d’une librairie nommée par Erick « uigfx ».
Cette petite librairie, sera bientôt disponible publiquement sur le svn lafabrick. Vous pouvez d’ores et déjà télécharger le projet (format .fxpl), dans la version proposée dans cette article. La documentation ( en anglais… pas parfait ! ) est disponible là.

[UPDATE]
Le projet uigfx a maintenant sa page sur google code. Pour plus d’information, la présentation de ce projet.
[/UPDATE]

Je vous laisse la place sur le fil de commentaire !

Autres articles sur le même sujet

Flex4 : composant personnalisé et skinning

Fabien — Fri, 27 Nov 2009 16:49:45 +0000

Je vous propose un petit tour d’horizon de la création de compo personnalisés avec Flex4 et le skinning. Vous allez voir ! Comme moi, vous ne voudrez plus jamais faire de Flex3. Moi ça fait 5 mois… et j’en suis bien content !

Alors voila. Nous allons voir comment faire un composant personnalisé avec le SDK4, de la conception actionScript, au skinning.
Il me fallait une idée de départ… Ceux qui me suivent sur Twitter aurons vu/lu qu’en ce moment je m’éclate avec Eaze, la librairie d’animation de Philippe Elsass. Super légère, facile d’utilisation et performante (Nicoptère a réalisé quelques “petites” démos sur le sujet). Je ne saurais que trop vous la conseiller.
Et bien on va se faire un petit compo de visualisation de ces fonctions d’animations

Première étapes : la primitive étendue

Avant de partir sur le composant, nous allons d’abord faire une extension de StrokedElement, qui va se charger de dessiner les courbes d’animations.

La classe StrokedElement est, dans Flex4, la classe de base pour tous les éléments graphiques ayant à dessiner une ligne. FilledElement, extensions de StrokedElement, s’occupe du remplissage. Les classes Line, Rect, Ellipse, Path… sont elles mêmes des extensions de FilledElement.

Nous allons donc créer une classe EazeElement, qui étend StrokedElement.
L’idée ici n’est pas d’afficher la “vraie” courbe d’accélération, mais plutôt d’avoir une “information visuelle” qui nous donne une idée sur l’évolution de l’animation, avec un point de départ et d’arrivé identique… Le voir en vrai c’est plus simple qu’à expliquer…

Nous allons associer à cette primitive 2 propriétés : eazeFunction : la fonction d’animation a tracer, et step la “précision” de la ligne.

Ensuite, il suffit d’overrider la méthode draw, et de faire ce que l’on veut dedans.
En gros nous allons boucler sur la largeur de l’élément, en se décalant à chaque passe de la valeur step, et calculer la position x, y de notre ligne en fonction de eazeFunction…. Vous pouvez voir en vrai la classe sous ce lien.

Aller hop on test tout ça ! Pour l’apparence, nous ajoutons à notre élément un “IStroke”. Cela peut être, , , … Y’en à d’autres : à vous de tester !

Rhooo ! C’est jouli !

C’est parti pour le composant

Notre composant va étendre SkinnableContainer, base pour la création de composant.

package com.lafabrick.components
{
    public class SimpleEazeViewer extends SkinnableContainer
    ...

Nous voulons utiliser notre primitive EazeElement dans ce compo. Il pourra aussi être redimensionnable, via une “ancre”. Nous devons donc définir ces différents objets de contrôles, dans la définition de notre composant. Nous utilisons ici les SkinPart.

SkinPart

Une skinPart définit un objet, visuel ou non, devant être présent (de manière obligatoire ou non) dans la skin. Ajoutons nos parties :

public class SimpleEazeViewer extends SkinnableContainer
{
    [SkinPart(required="false")]
    public var anchor : Group;

    [SkinPart(required="true")]
    public var eazeElement : EazeElement;

ici, eazeElement est requis et obligatoire. anchor, l’ancre pour redimensionner le composant, par contre est optionnel.

Nous verrons plus bas comment les utiliser dans le composant. Occupons nous des états de ce composant.

SkinState

SkinnableContainer définit 2 états de base : “normal” et “disabled”. Ces états devront être présents dans la skin. Nous allons ajouter un état “selected” : lorsque l’utilisateur déplacera l’ancre, le composant passera en état “selected”. Pour ajouter un état personnalisé, dans l’en-tête de classe, ajoutons le tag suivant :

[SkinState(name="selected")]

Nous allons également créer une propriété selected, qui définira si le composant est sélectionné…

dans le setter, nous allons appeler la fonction invalidateSkinState(), qui va déclencher le processus de changement d’état. Pour relier la propriété selected à l’état sélectionner, nous devons overrider la fonction protégée getCurrentSkinState().

private var _selected : Boolean = false;

public function get selected():Boolean
{
    return _selected;
}

public function set selected(value:Boolean):void
{
    _selected = value;
    invalidateSkinState();
}

override protected function getCurrentSkinState() : String
{
    return selected ? "selected" : "normal";
}

Ajoutons enfin la dernière propriété eazeFonction : Function qui va nous permettre de définir la fonction à tracer par la primitive.

Overridons un brin

Il est temps de passer à la gestion de tout ça. Ce que l’on a besoin, c’est de savoir quand les différents éléments définit dans les SkinPart sont ajoutés, pour leur pousser les propriétés et autres écouteurs qui vont bien. Pour cela, nous devons overrider la méthode partAdded de la manière suivante.

override protected function partAdded(partName:String, instance:Object) : void
{
    super.partAdded( partName, instance );

    if( instance == eazeElement ) {
        eazeElement.eazeFunction = eazeFunction;
    }

    if( instance == anchor ) {
        anchor.addEventListener(MouseEvent.MOUSE_DOWN, onAnchorMouseDown );
        systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_UP, onMouseUp );
        systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_MOVE, onMouseMove );
    }
}

Dans le sens inverse, il faut overrider partRemoved pour, entre autre chose, enlever les écouteurs sur les éléments.

override protected function partRemoved(partName:String, instance:Object) : void
{
    super.partRemoved( partName, instance );

    if( instance == anchor ) {
        anchor.removeEventListener(MouseEvent.MOUSE_DOWN, onAnchorMouseDown );
        systemManager.getSandboxRoot().removeEventListener(MouseEvent.MOUSE_UP, onMouseUp );
        systemManager.getSandboxRoot().removeEventListener(MouseEvent.MOUSE_MOVE, onMouseMove );
    }
}

Plus qu’à mettre la mécanique dans les fonctions qui vont bien.

La classe complète ici

plutôt super simple ce fonctionnement !

Côté skin

Skin ou SparkSkin ?

Vous avez 2 possibilités : partir de Skin ou SparkSkin, la dernière étant une extension de la première. La différence est que SparkSkin ajoute une mécanique spéciale pour exclure des éléments de la mécanique de skinning. Dans Flex4 vous pouvez injecter des couleurs de base à vos skin, avec la propriété baseColor. L’exclusion permet d’éviter de coloriser les éléments sélectionnés. Je vous invite a faire un saut dans les classes Skin des boutons (ex: spark.skins.spark.ToggleButtonSkin ) pour voir à quoi cela ressemble.

Nous allons choisir Skin.

Pointer sur le composant cible

En premier lieu, nous devons spécifier quel est le composant cible de cette skin. Cela se passe dans le tag metadata :


    [HostComponent("com.lafabrick.components.SimpleEazeViewer")]

Les états

Nous devons aussi retrouver les états définit dans le composants : normal, disabled et selected :

Plus qu’a ajouter vos éléments définit dans les skinPart (un Group avec l’id “anchor” et un EazeElement avec l’id “eazeElement” ). Et puis vous amusez a faire de la déco à grand coup de Rect, Ellipse, Line, Path, …. La grande classe !
Tout ces éléments se calibrent avec les contraintes top, left, bottom, right. Les possibilités sont infinies.

Pimp my State! inclusion, exclusion, groupage….

Voyons comment gérer notre skin en fonction de ses états.
Le nouveau système de gestion d’états est bien loin de celui proposé dans Flex3. Plus simple et bien plus logique, il vous permet un contrôle total de votre skin.
Admettons que vous ayez un composant avec les états suivants :

Un rectangle est définit dans la skin, et doit être inclus dans les états « up », « down », « over ». La déclaration de l’inclusion, et des différentes couleurs en fonction des états devra se faire suivant cette exemple :

Vous pouvez voir ici que l’attribution de valeur en fonction des états fonctionne aussi bien sur des couleurs que sur n’importe quelle autre propriété, comme sur le filtre.

Les états proposent une mécanique de groupage par nom, qui vous permet de pousser encore plus loin la gestion de la skin. Un état peut faire partie de plusieurs groupes :

Les états down et over, en vue « normal » et « sélectionné » font partie d’un même groupe « mouseOn ». De même, les états sélectionnés sont regroupés dans un groupe « selected ».

Nous pouvons alors modifier la skin de notre rectangle. Au lieu de définir dans quel état le rectangle est présent, nous allons plutôt lui définir dans quels groupes d’états il est exclu :

De même, la définition des couleurs et des propriétés du filtre peut être affectée globalement en fonction du groupe d’état :

Le rectangle est exclu des états sélectionnés, et les couleurs sont attribuées en fonction du groupe définissant une interaction de l’utilisateur « mouseOn ».

Sympa non?

Je veux mon composant !

Vous pouvez bien sur accéder a votre composant via hostComponent : si par exemple vous définissez un texte dans votre composant, vous avez possibilité de l’affecter directement dans votre skin comme ceci :

Bon a savoir : le contentGroup

SkinnableContainer définit un Group optionnel, contentGroup, qui, comme son nom l’indique est le groupe du contenu Ce groupe est le réceptacle des différents éléments que vous pouvez ajouter a votre compo. Par exemple un Panel dispose de ce contentGroup. Sinon on met rien dedans et ce ne serait plus un Panel…. Bon nous n’en avons pas besoin ici, mais si jamais vous avez besoin d’un composant qui peut être aussi un réceptacle de composants, n’oublier pas le contentGroup !

Retournons à notre compo…

… et regardons la skin complète.

Un peu plus loin…

Imaginons maintenant que vous ne vouliez plus afficher une courbe mais plusieurs à la suite, définit dans un tableau. Vous n’aurez donc plus un eazeElement, mais un Group qui contiendra vos primitives.
Le problème alors est de pouvoir skinner le trait de vos primitives. Vous devrez donc définir un IStroke. Ce qui est intéressant dans ce nouveau système de skin, c’est qu’il est aussi possible de définir ce Stroke, pourtant élément non visuel, dans une SkinPart.

[SkinPart(required="false")]
public var anchor : Group;

[SkinPart(required="true")]
public var eazeGroup : Group;

[SkinPart(required="true")]
public var eazeStroke : IStroke;

La déclaration côté Skin ce fera a l’intérieur des balises déclaration :


    [HostComponent("com.lafabrick.components.MultipleEazeViewer")]

La nouvelle classe, se cache derrière ce lien, et la skin associée derrière celui-ci.

La démo finale ( les sources )
J’espère que comme moi vous tomberez sous le charme. C’est fou comme une évolution peut vous montrer à quel point c’était tout nul avant !Autres articles sur le même sujet

Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

Erick — Sat, 31 Jan 2009 21:48:24 +0000

[ 5 mars 2009 : Mise à jour de l'article : ~~Cocomo~~ devient AFCS et passe en version 0.9.1, corrigeant quelques bugs ]

Dans ce 1er exemple d’application ~~Cocomo~~ Adobe Flash Collaboration Services aka A.F.C.S, nous allons développer, à vrai dire « assembler », une application de visioconférence intégrant un tchat, des notes partagées et un gestionnaire de partage de fichiers. Pour cela nous allons utiliser des pods, les composants de plus haut-niveau fournis dans ~~cocomo~~ AFCS .

L’un des principaux composants d’une application ~~cocomo~~ AFCS est le gestionnaire de session. C’est lui qui sera chargé de la communication avec les serveurs ~~cocomo~~ AFCS , et donc de l’identification des utilisateurs, de la gestion de leur connexion, de la synchronisation des données… et plus encore…

Deux composants peuvent jouer ce rôle : ConnectSessionContainer et ConnectSession ( tous deux implémentent com.adobe.rtc.session.IConnectSession ).

Hello AFCS ( bye Cocomo )

Pour commencer :

- créer un nouveau projet Flex,
- copier le SWC ~~Cocomo~~ AFCS (depuis CocomoSDK_0.9/lib/player 9 ou 10/afcs.swc) et collez-le dans votre répertoire /libs/

Il s’agit d’un composant basé sur la classe Canvas, et intégrant toute la « mécanique » nécessaire à la communication avec les serveurs ~~cocomo~~ AFCS .

Il est à noter que le ConnectSessionContainer, et donc ses « composants-enfants », resteront invisibles tant que la communication avec salon ne sera pas établie. C’est pour cette raison que nous allons lui intégrer nos pods ( WebCamera, SimpleChat, Notes et FileShare ).Tant que la connexion ne sera pas établie, aucun des composants ne sera visible.

Pour débuter une session, nous devrons renseigner deux propriétés du container de session :

l’adresse du salon: roomURL ( exemple : http://connectnow.acrobat.com/votreCompte/nomSalon )
les identifiants de connexion : authenticator

La transmission des identifiants se fait par l’intermédiaire de la classe AdobeHSAuthenticator.Elle a pour fonction d’encapsuler les informations relatives à l’identification( userName, password ). Plusieurs modes d’authentification sont possibles, nous nous y interresserons plus tard.

Dans un premier temps nous nous contenterons d’inscrire nos identifiants « en dur » dans notre application.

On peut noter que les composants liés à AFCS se référent au namespace ‘AfcsNameSpace’ ( anciennement ‘CocomoNameSpace’ dans version 0.9 )

À ce stade, l’application peut déjà se connecter. Par défaut, dès que le connectSessionContainer est créé, il tente d’initier la communication avec les serveurs. Dans cet exemple, j’ai ajouté une couleur de fond pour le container, de manière à pouvoir observer lorsque la connexion au salon est réussie.

Si vous publiez le projet en mode debug vous verrez les logs relatifs aux communications client/serveur.

Pour vérifier si l’authentification est correcte, nous pouvons déclarer des écouteurs d’événements AuthenticationEvent.AUTHENTICATION_FAILURE et AuthenticationEvent.AUTHENTICATION_SUCCESS sur AdobeHSAuthenticator.

Pour capter le moment où notre application est connectée et synchronisée, nous pouvons ajouter un écouteur d’événement SessionEvent.SYNCHRONIZATION_CHANGE sur le container, et surveiller sa propriété ‘isSynchronized‘. Nous reviendrons prochainement sur les différents aspects et acteurs en jeu lors de cette synchronisation.

Maintenant que notre connexion parvient à se connecter au salon, nous allons pouvoir intégrer les pods.

Utilisation des pods

Les pods sont des composants collaboratifs « prêt à l’emploi« . Lorsque vous utilisez un ConnectSessionContainer, il suffit d’insérer vos pods à l’intérieur pour qu’ils puissent repérer la connexion établie et l’utiliser.

À ce jour, les pods disponibles sont :

SimpleChat : composant de « clavardage » permettant l’envoi de messages publics et privés
WebCamera : composant de visioconférences
FileShare : composant de partage de fichier ( upload / download )
Note : composant de partage de notes
Roster et HorizontalRoster : composant de gestion d’utilisateurs
SharedWhiteBoard : tableau blanc partagé

Nous allons maintenant insérer les pods souhaités :

Les pods intégrent des mécanismes de gestion de droits. Nous y reviendrons …

Toujours est-il que voilà, vous avez créé votre première application ~~cocomo~~ AFCS , ou devrais je dire votre première application de « communication en temps réelle ». Mais comment faisait-on avant ???…

Identification et gestion de la connexion aux serveurs

Bon il manque encore quelque chose peut être… Pour un seul utilisateur çà irait presque… mais c’est pas le but :s…Comment fera-t-on si un jour on trouve des amis et qu’on veut collaborer avec eux ??? Tout le monde va se connecter avec le compte « d’admin » ??? Et n’importe quel décompileur AS3 va pouvoir récupérer les identifiants ? Pas très sécure… Heureusement ~~cocomo~~ AFCS nous permet de gérer facilement tous ces aspects.

Les serveurs ~~cocomo~~ AFCS permettent plusieurs types d’identification, notamment une connexion en tant que hôte, basée sur le compte ~~cocomo~~ AFCS Developper, et une connexion en tant qu’invité, ne nécessitant qu’un nom de participant.

Nous allons donc supprimer les attributs userName et password de l’AdobeHSAuthenticator, et ajouter un formulaire d’authentification à notre application. Ce formulaire permettra de choisir le type d’identification ( hôte ou invité ) :

La définition des rôles des utilisateurs est basée sur des valeurs numériques, définies dans des constantes de la classe UserRoles.

Les principaux rôles sont Owner ( hôte / propriétaire du salon ), Publisher ( participant autorisé à publier sur un ou plusieurs pods ) et Viewer ( invité seulement autorisé à utiliser le tchat ). Normallement, les invités ne peuvent utiliser un salon que si l’hôte est présent. Il est possible de modifier la configuration initiale des salons ( droit de publication automatique, persistence des données, entrée libre… ), ainsi que les rôles et les droits des utilisateurs connectés, pour cela nous pourrons utiliser l’application ~~CocomoDevConsole~~ AFCSDevConsole ou l’API directement. Mais c’est déjà une autre histoire…

Pour le moment, nous allons permettre à l’utilisateur de s’identifier à l’aide du formulaire. Pour cela nous devons désactiver la connexion automatique du gestionnaire de session en déclarant sa propriété autoLogin= »false ».

Pour finir, nous allons ajouter une méthode login() qui sera chargée de renseigner le AdobeHSAuthenticator, et de lancer la connexion du gestionnaire de session :


private function login ( login:String, password:String ):void
{
   identificator.userName = login;
	//if password is set : log as host
	//else log as guest
   identificator.password = password ;

	// run sessionManager connection
   sessionManager.login();
}

Nous allons ensuite rajouter un bouton et une fonction de déconnexion.


// disconnection
// in actual 0.9 beta, mostly pods, can't be re-connected after a disconnection

private function logout():void
{
    sessionManager.logout();

	// close() is supposed to disconnect et remove all childNodes, but seems not work yet
    //sessionManager.close();
}

Dès que l’application sera connectée, nous supprimerons le formulaire, et en cas de déconnexion le gestionnaire de session sera supprimé :


// for each synchronization event
// : connection, disconnection , state's change, ...
private function onSynchro( e:SessionEvent ):void
{

	// once application is successfully connected / synchronized
    if ( sessionManager.isSynchronized && ! isConnected )
    {
        Alert.show("Application connectée");

        isConnected = true ;

        removeChild( logPanel );

    } else if ( ! sessionManager.isSynchronized && isConnected ){
    // if disconnected
    isConnected = false ;

   /* remove the connectSessionContainer
   *  » in this version disconnected pods can't re-connect
   *
   *  » For re-connect, you can :
   *     - reload html page
   *     - dynamically re-create connectSession and pods
   */
   removeChild( sessionManager );

   // display logout message
   Alert.show( 'vous avez quitté la réunion, recharger la page pour entrer à nouveau');
   }
}

La gestion des déconnexions / reconnexions semblent pour le moment un peu instables. Mais bon on est prévenu, c’est une béta. Après quelques tests, je crois que le meilleur moyen de revenir dans un salon après s’être déconnecté, est de recharger la page.

Accéder aux sources complétes

Voilà la fin de ce premier exemple d’utilisation de ~~cocomo~~ AFCS , et il est bien entendu possible d’aller beaucoup plus loin. La prochaine fois nous nous intéresserons de plus près aux différents mécanismes articulés au sein de ~~cocomo~~ AFCS , et plus globalement à l’architecture du service. Nous utiliserons également la ~~CocomoDevConsole~~AFCSDevConsole et le LocalConnectionServer, les deux outils AIR proposés dans le SDK.

D’ici là bonne collaboration !!!

Autres articles sur le même sujet

Developing with AFCS a.k.a Cocomo – Introduction

Hervé — Tue, 20 Jan 2009 23:38:28 +0000

[ 05.03.2009 : Update : Cocomo is now called Adobe Flash Collaboration Services / AFCS and 0.9.1 was released with some bug fixes and a new namespace ]

Hey there!
Here is, as a first English article, an introduction to ~~Adobe Cocomo~~ AFCS.
(Translated from French tutorial on FlashXPress )

Cocomo is an abbreviation of «COmmon COllaboration MOdel», which was the first name given by Adobe to its new online service dedicated to collaborative application development. The final commercial name is Adobe Flash Collaboration Services a.k.a AFCS

This name both references :

a SDK that includes a Flex components library and tools dedicated to multi-users applications development. Just so you know, those components are used by Adobe for developing ConnectNow, a video conference application part of the Acrobat.com platform.
a free online service (with some limitations), enabling creation and deployment of collaborative applications on FMS servers hosted and maintained by Adobe.

In short, ~~Cocomo~~ AFCS will allow us to develop applications that will use real-time communications capabilities of FMS servers, without taking care of those servers… cooool !!!

But what are the «real-time communications capabilities of those FMS servers» ???

In fact, the ~~Cocomo~~ AFCS servers will allow us to:

exchange audio and video data flows, useful to create visioconference application for example,
synchronize different types of data between multiple client applications. It allows you to add a chat to an existing application, to develop a co-navigation system, a document co-edition functionnality, some multi-users game…
share files
manage user rights regarding their role

This schema describes the interaction between a room, hosted on a developer account of a cocomo server, and some Flex clients : the host user (owner), an active guest (publisher), and a passive guest. The host send his webcam output, and both host and publisher can update notes on the server, these data are broadcasted to the other clients.

The library contains «high-level» graphical components, known as pods, but also some more «low-level» classes that a developer can use to create his own components (SharedModel, CollectionNode).

This schema shows an example of pods (Tchat, Notes, User management, Webcam and File sharing)

The pods are collaborative «plug’n’play» components, that we will use to create our first ~~Cocomo~~ AFCS applications without having to write a single line of code (Tchat, Webcam, Notes…). The lower level classes will help us to go deeper and create components that will fit more specific needs.

But, first things first : let’s create a «~~Cocomo~~ AFCS Developer» account…

Cocomo AFCS Developer account creation

To create an account :

Go to the ~~Cocomo~~ AFCS portal (https://cocomo.acrobat.com),
Create a new account (you can also use your existing Adobe account)
Choose a ~~Cocomo~~ AFCS account identifier («account name», room access URLs will be based on that identifier)
1. The Account URL situation in the screen
2. The Room instances panel (click the « Add » button)
3. The « Download SDK » button

This capture represents the ~~Cocomo~~ AFCS home page. It mainly illustrates the three steps to follow:

Once your account has been created, make sure to note your Account URL
In the « Room instances » panel, create a new room. A room represents a « virtual meeting point » where several client application will be able to exchange audio / video flows, files or messages. Your account will allow you to create several rooms, with a single configuration for each room. A room is also identified by a URL that looks like http://connectnow.acrobat.com/yourAccount/roomName.
Once your room has been created, download the SDK.

You’ll find within the downloaded ZIP:

documentation
application examples
Air utilities: ~~CocomoDevConsole~~ AFCSDevConsole for your accounts and rooms management, and LocalConnectionServer, a local ~~Cocomo~~ AFCS server emulation that will allow you to test some of your applications features without having to connect to a « real » ~~Cocomo~~ AFCS server (mainly messaging)
library sources
library SWC for Flash Player 9 and Flash Player 10

Cocomo AFCS installation

For this version (0.9), installation will reside in including ~~Cocomo~~ AFCS library documentation at Eclipse’s one. To do so:

create a ‘com.adobe.afcs‘ folder in the ‘plugins‘ folder of your Flex Builder installation
Windows: C:\Program Files\Adobe\Flex Builder 3\plugins\com.adobe.afcs
Macintosh: /Applications/Adobe Flex Builder 3/plugins/com.adobe.afcs
Copy the content of the downloaded file into that folder
(Re)Launch Flex Builder and open the help contents (Help / Help Contents)

You should now find the ~~Cocomo~~ AFCS API documentation

This schema is a screen capture of the cocomo documentation opened within the Flex Builder environment.

And noooow… let’s collaborate !!!
>> Next : My first ~~Cocomo~~ AFCS ApplicationAutres articles sur le même sujet

Développer une application iPhone – XCode et Interface Builder passés au crible

Hervé — Thu, 15 Jan 2009 22:00:38 +0000

Cet article suit la description des concepts de base permettant d’appréhender le développement d’une application pour iPhone.
Il présente les outils de développement utilisés pour faire une application pour iPhone en analysant rapidement un projet de base proposé avec le SDK iPhone.
Il ne parle pas de la syntaxe de développement Objective-C.

Je vous suggère vivement si vous n’avez pas lu l’article ou si vous ne connaissez pas encore grand chose au développement sous iPhone de vous y intéresser pour mieux aborder cette suite…

Une dernière chose avant de démarrer : massez-vous les tempes, faites-vous un petit café…
Prêt ?

Installer le SDK iPhone

A l’heure ou j’écris ces lignes, Apple en est à la version 2.2 du SDK iPhone.
L’installation vous mettra à disposition tous les outils dont je vais parler ici.

Ouvrir un projet d’exemple pour se familiariser avec la structure d’un projet iPhone

Je considère à présent que vous avez déjà un Mac (bah oui…), et le SDK iPhone installé dessus.

Ouvrez XCode.
Faites Fichier > Nouveau projet…
Choisissez « View-Based Application »
Entrez le nom de projet « LaFabrick » puis choisissez un emplacement, vous arrivez alors sur l’interface principale d’Xcode.

Voyons maintenant les fichiers que nous avons :

Nous sommes en Objective-C, donc pour chaque classe, vous trouverez un fichier .h définissant l’interface et un fichier .m contenant l’implémentation (amis du C bonjour !).
Ouvrons « LaFabrickAppDelegate.h »

On constate dans cette interface les déclarations d’un objet fenêtre (objet de base utilisé pour l’affichage) et le contrôleur LaFabrickViewController que nous étudierons rapidement après.
L’implémentation est simple :

Lorsque l’application vient d’être démarrée applicationDidFinishLaunching, on demande l’affichage de la vue contrôlée par notre LaFabrickViewController dans la fenêtre [window addSubview:viewController.view];.
Notez enfin la notation à crochet pour appeler une méthode d’un objet : oui oui, c’est relou.

Jetons maintenant un oeil à LaFabrickViewController (.h et .m) : il est quasiment vide ! C’est effectivement là qu’on doit travailler un peu…
Quelques questions se posent :

Où est la vue ?
Comment est-elle associée au contrôleur ?

Nous allons voir cela avec l’interface builder.

Utilisation de l’Interface Builder pour gérer la vue

Première réponse : notre vue est ici créée à partir d’un fichier de description d’interface géré par l’interface builder : LaFabrickViewController.xib. Double-cliquez dessus, l’interface suivante s’affiche alors :

On constate notamment dans la fenêtre centrale, les éléments suivants :

File’s owner : LaFabrickViewController
View : UIView

OK, donc le .xib permet de dire que la vue est associée au contrôleur LaFabrickViewController, voilà la deuxième réponse !

Sélectionnez à présent la ligne View : UIView puis sélectionnez le second onglet dans la fenêtre de droite.
Note : si cette fenêtre n’est pas visible, faites Tools > Identity Inspector

Vous pouvez visualiser l’association entre la vue View et la propriété view du contrôleur LaFabrickViewController.

Cette partie est primordiale pour que l’affichage de la vue soit effectif : souvenez-vous que dans LaFabrickAppDelegate, on charge la propriété « view » de LaFabrickViewController, aussi sans l’association effectuée dans l’Interface Builder, il serait impossible d’afficher quoi que ce soit !

D’une manière générale, chaque élément ajouté depuis l’Interface Builder devra être lié à une propriété du contrôleur (ou d’un délégué) via l’Interface Builder afin que vous puissez interagir avec depuis le code.
La propriété en question est alors nommée « Outlet » côté Interface Builder, soit « Sortie » si l’on traduit litéralement : c’est effectivement un paramètre de sortie de votre interface.

Personnaliser un peu l’interface

Depuis l’Interface Builder, ajoutez deux champs texte, deux labels et un bouton histoire d’obtenir à peu près ça :

Si vous faites Tools > Reveal in Document Window… vous verrez l’arborescence de contrôles de la vue mise à jour.

Il est maintenant temps de contrôler ces éléments depuis notre LaFabrickViewController.
Pour cela deux méthodes :

Directement depuis Interface Builder (cf. vidéo de démonstration)
- Sélectionnez LaFabrickViewController depuis le Document Window
- Dans « l’Inspector » (fenêtre de droite) choisissez le dernier onglet (i) puis ajoutez les propriétés via la section « Class Outlets »
- Ceci fait vous devez enregistrer les modifications dans le fichier LaFabrickViewController.m. Pour cela, vous devez utiliser la fonction File > Write class files…
- Faites alors « Save »
- L’outil vous demande si vous souhaitez fusionner ou écraser : choisissez Merge (fusionner)
- Le fichier .m n’est pas modifié, vous pouvez le fermer, en revanche vous constaterez que le .h peut être modifié comme suit :
  
  sous réserve que vous choisissiez l’action « Choose left » depuis le menu déroulant du bas
- Sauvegardez (enfin) votre fichier fusionné
Mix XCode et Interface Builder
- Déclarez manuellement les propriétés correspondant aux contrôles que vous souhaitez manipuler dans l’interface (LaFabrickViewController.h) :IBOutlet UITextField *lastNameField; IBOutlet UITextField *nameField; IBOutlet UIButton *validateButton;
- Compilez le projet
- Rouvrez l’Interface Builder pour faire les liens

Note : la première méthode a le mauvais goût d’ouvrir l’outil de fusion de fichiers pour que vous validiez que rien n’est écrasé ou ajouté sans votre accord.
J’avoue que, malgré la nécessité de la fusion, je trouve ça très peu pratique voire franchement lourdingue, je m’attendais à mieux venant d’un monstre de l’ergonomie. Mais c’est le prix à payer pour avoir deux outils quasiment indépendants, et enfin, si vous connaissez une meilleure méthode, n’hésitez pas à poster !

– ca se voit tant que ça que je préfère la méthode à l’ancienne ? –

Ce n’est pas encore tout à fait terminé ! (si si je vous jure, c’est long)
Il reste à faire les fameux liens entre les contrôles de la vue et les propriétés que nous avons créé dans LaFabrickViewController. Pour cela, rien ne vaut l’image (et en plein écran tant qu’à faire) :

Voilà ! Vous avez lié les contrôles de votre vue à des propriétés de votre contrôleur.
Nous utiliserons désormais la technique décrite ci-dessus pour gérer nos association vue-contrôleur.

Reprenons Interface Builder pour créer un handler gérant le clic sur le bouton. Pour cela :

Sélectionnez LaFabrickViewController depuis la Document Window
Dans le dernier onglet de l’Inspector, cliquez sur le bouton + de la section Class Actions en entrez buttonClick:. Laissez le Type sur id
Sauvegardez, faites Write class files…, fusionnez les sources et enregistrez
Faites un lien entre l’événement Touch up Inside de votre bouton et LaFabrickViewController, l’éditeur vous propose alors votre fonction buttonClick:

Maintenant que votre événement est lié à votre contrôleur, ajoutons un bout de code bateau juste pour valider que l’ensemble fonctionne bien :

Retournez sous XCode, et ouvrez LaFabrickViewController.m
Modifiez le code pour avoir la méthode buttonClick: sous la forme suivante :
- (IBAction)buttonClick:(id)sender { [firstNameField setText:[lastNameField text]]; }

Le principe étant simplement de modifier le texte du prénom avec le texte du nom (je vous avais prévenu, c’est un bout de code bateau)
Faites Build and Go et testez !

Bien, il ne reste plus qu’à apprendre Objective-C. Pour cela, rien ne vaut quelques ressources dédiée au sujet :

Voilà, vous avez à présent les bases nécessaires pour démarrer le développement d’une application iPhone.
A bientôt !Autres articles sur le même sujet

Reflex #2 : vous reprendrez bien un peu de IOC ?

Fabien — Wed, 14 Jan 2009 22:16:49 +0000

Reflex intègre un système d’Injection de contenu, qui est l’une des représentations de l’IOC.
Nous allons voir ici à quoi cela sert, et comment le mettre en œuvre dans Reflex.

Si ce n’est déjà fait, je vous laisse jeter un œil sur la première partie de cette architecture, et de récupérer le swc avant de lire la suite.

A quoi ça sert l’IOC ?

L’IOC ( Inversion Of Control ) est un patron d’architecture, possédant plusieurs représentations ( inversion de contrôle, injection de dépendance, …). Je ne vais pas faire un cours sur l’Injection de contenu : je vous laisse voir ici pour plus d’informations.

Dans Reflex, le but du package IOC est de décentraliser les objets de configurations de l’application. En gros, mettre les services d’accès aux données dans un fichier de configuration XML au lieu de les coder en dur dans l’application Flex.

Certains spécialistes me diront certainement que l’Injection de contenu n’est pas forcement une représentation de l’IOC, et donc un abus de langage pour Reflex : je répondrais par “traduisez ici IOC par Injection Of Content, et laissons tomber les patrons d’architecture !”.

Au commencement, le ServicesLocator

Nous avons vu dans la première partie comment réaliser simplement un appel à une méthode distante. Avoir un point d’accès global aux différents services est pratique lorsque l’on commence à avoir plusieurs services, ou si des vues différentes utilisent un service identique. Voyons comment procéder avec le premier exemple.

Reprenons l’exemple du tuto #1 : il faut charger les services dans le ServicesLocator. Nous allons donc modifier notre vue :

À la création de l’application ( creationComplete ), nous déclenchons la fonction init();.
Nous ajoutons les services RemoteObject dans le ServicesLocator. La signature de cette méthode est la suivante :
```
ServicesLocator.addService( serviceName:String, serviceObject:AbstractService )
```
-     serviceName:String est le nom de référence utilisé pour indexer, et plus tard retrouver le bon service.
- serviceObject:AbstractService est l’identifiant (id) de l’object service (le RemoteObject). 
Nous supprimons la propriété service dans la déclaration mxml de UserController, pour la déclarer en ActionScript dans la fonction init().   ServicesLocator.getService( serviceName:String ) renvoie l’instance du service défini par serviceName, référencée dans le locator.

Note : Au niveau de l’appel du service, nous pourrions appeler la méthode getController de ControllerLocator.

userControl.login(login.text, password.text);

devient :

( ControllerLocator.getController( MonApplication.SERVICE_USER )
	as UserController ).login(login.text, password.text);

Dans ce cas, nous devons « caster » le retour de getController(…) en UserController ( sinon erreur ! Flex ne connaîtrait pas la méthode login )

Un composant pour la vue

Histoire de mettre en pratique un peu plus l’utilisation des “locators” de Reflex, nous allons créer un composant MXML étendant Canvas, qui va contenir la représentation visuelle de notre application. Nous allons utiliser ControllerLocator dans ce fichier pour récupérer le UserController.

Pour que le “Binding” fonctionne correctement entre la vue et le modèle, nous devons utiliser des pointeurs vers les modèles à utiliser.

Le fichier de configuration XML (IOC)

Nous venons de voir comment utiliser le ServiceLocator. Intégrons maintenant le système IOC pour ne plus avoir à le gérer !

Ce fichier vous permet de décrire des objets, pour ensuite les récupérer et les instancier dans votre application ( via ApplicationContext ). Ce fichier s’inspire fortement des fichiers de configuration de Spring, un framework puissant pour Java.

Ci-dessous le fichier représentant 2 services RemoteObject :




	
		javaFacadeUser
		true
	

	
		javaFacadeOther
		true

Le tag englobe les différents objets définis dans le fichier. Il est défini par :
Un objet est défini par :
- un identifiant id. Cet id est celui que nous utiliserons plus tard dans l’application Flex pour retrouver et instancier l’objet.
- un nom de classe className : la classe de référence.
Les propriétés des objets sont définies par :
- leur nom name
- leur classe className de référence.

Ici, un RemoteObject a besoin de 2 propriétés : la destination du type String, et éventuellement showBusyCursor du type Boolean.

Régler le problème d’inclusion de classe

Le “petit” problème de ce système est que la déclaration externe des objets fait que les classes ne sont pas intégrées dans le projet Flex. Le compilateur Flex ne trouve pas de référence aux classes, et ne les intègre donc pas dans la compilation. Un façon très simple de régler ce problème est de créer un petit fichier actionScript, et d’ajouter des objets bidons du même type que ceux définis dans votre fichier de config.

Exemple avec les services : (fichier includeService.as)

import mx.rpc.http.mxml.HTTPService;
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.soap.mxml.WebService;

private var ser1:RemoteObject;
private var ser2:HTTPService;
private var ser3:WebService;

Ce fichier sera intégré dans votre application.

Chargement et gestion du contexte XML

Vous allez voir : simple comme bonjour !
Nous allons ajouter le chargement du fichier via ApplicationContext. ApplicationContext permet de charger automatiquement le contexte cible, et de retrouver, instancier, et enregistrer automatiquement tous les services qui se trouvent dans votre fichier de configuration XML dans le ServicesLocator.

Votre application finale :

Nous continuons à utiliser le “creationComplete” pour déclencher la fonction init() qui chargera le fichier de configuration.
Il ne faut pas oublier d’inclure au besoin les classes contenues dans notre fichier de config !
```
include "includeService.as"
```
Dans la fonction init(), nous ajoutons un écouteur sur ApplicationContext (ContextEvent.CONTEXT_LOADED), qui déclenchera la fonction onLoaded quand le fichier de configuration sera chargé. Puis nous lançons le chargement du fichier de config ( ioc/application-config.xml ).
… Et nous incluons la vue LoginView.

Modification de notre UserController

Dans un soucis de clarté, nous allons créer 2 classes contenants les constantes référençants les noms des services (contenus dans le fichier de configuration), et les noms des méthodes de ces services.

MethodConstant (dans notre exemple uniquement la méthode login)

package service
{
	public class MethodConstant
	{
		public static const LOGIN:String = "login";
	}
}

ServiceConstant (les identifiants des objets contenus dans le fichier de configuration)

package service
{
	public class ServiceConstant
	{
		public static const SERVICE_USER:String = "remotingUser";
		public static const SERVICE_OTHER:String = "remotingOther";
	}
}

Nous venons de charger notre fichier de configuration au niveau de notre Application. Nous devons maintenant modifier notre contrôleur pour qu’il écoute le chargement du fichier (événement ContextEvent.CONTEXT_LOADED), et mette à jour sa propriété service.

package controller
{
	import com.lafabrick.reflex.controller.BaseController;
	import com.lafabrick.reflex.ioc.ApplicationContext;
	import com.lafabrick.reflex.ioc.event.ContextEvent;
	import com.lafabrick.reflex.model.ModelLocator;
	import com.lafabrick.reflex.service.ServicesLocator;

	import dataObject.UserDo;

	import model.UserModel;

	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	import service.MethodConstant;
	import service.ServiceConstant;

	public class UserController extends BaseController
	{

		public function UserController() : void
		{
			ApplicationContext.addEventListener(ContextEvent.CONTEXT_LOADED, onLoaded);
		}

		private function onLoaded( event:ContextEvent ) :void
		{
			// Contexte chargé
			this.service = ServicesLocator.getService( ServiceConstant.SERVICE_USER );
		}

		public function login( log:String, pass:String ) : void
		{
			executeMethod(MethodConstant.LOGIN, onLoginResult, onLoginFault, log, pass);
		}

		public function onLoginResult( event:ResultEvent ) : void
		{
			(ModelLocator.getModel( UserModel ) as UserModel).userLogged =
				event.result as UserDo;

			trace((ModelLocator.getModel( UserModel ) as UserModel).userLogged.name);
		}
		public function onLoginFault( event:FaultEvent ) : void
		{
			trace("resultat pourri ..."+event.fault);
		}

	}
}

Les sources de cette exemple

Et voilà ! Je vais préparer d’autres articles, notemment l’intégration de Reflex dans un projet Gumbo/Flex4. N’hésitez pas à poster vos retours, c’est en flexant qu’on devient flexeron.Autres articles sur le même sujet

Reflex #1: une micro-architecture pour Flex… simple !

Fabien — Mon, 12 Jan 2009 23:05:01 +0000

Après un temps de test, de mise en place et re-factorisation en tout genre, j’ai décidé de partager la petite micro-architecture que j’ai mis en place à l’université, et que j’utilise dans mes projets.

Let’s gamble !

Encore un MVC ?

Oui.
Plus sérieusement, l’écriture de cette micro-architecture est partie d’un besoin de simplicité et de robustesse.

Souvent dans le monde de Flex, les équipes ne sont pas forcement homogènes. Certains sont habitués à la rigueur de Java, d’autres sont plus “devsigners freestyle” venant du monde Flash. Les premiers aiment les grosses mécaniques comme PureMVC, ou Prana Framework “Spring like”. Les seconds connaissent au mieux Cairngorm, au pire confondent MVC et VMC – ce qui n’a rien a voir, sauf si vous faites une application riche sur le thème de la ventilation.
Il fallait donc trouver la solution la plus efficace pour avoir un flux de production le plus optimal.

Bon vous me direz “ba Cairngorm c’est pas mal” ! Oui mais voilà. Cairngorm est plus une ligne de conduite qu’une micro-architecture. Il suffit en gros de suivre les interfaces et d’écrire son MVC. C’est simple, mais pourquoi diable utiliser ces #?~! d’événements synchrones pour déclencher des commandes ! Et il devient assez pénible de dupliquer le travail déjà fait côté serveur… sans compter le temps de compilation à rallonge. C’est rigolo pour se faire les dents, mais au bout d’un moment faut être sérieux.

Donc Reflex.

Le MVC en 2 mots

MVC, pour Model View Controller, est le design pattern le plus connu. Le but de ce pattern est de décomposer la représentation graphique (la vue), la couche métier et le modèle de données.

Le modèle MVC de Reflex peut se visualiser comme suit :

La vue demande au contrôleur la récupération de données.
Le contrôleur lance la méthode avec les arguments associés, et capte les retours du serveur.
À la réception des données, le contrôleur met à jour le modèle de données.
Le modèle notifie à la vue son changement et la met à jour.

Préparation de votre projet d’exemple

Une page de ressources pour Reflex est disponible sur le Blog.

Commencez par récupérer le swc reflex.
Les sources, et la documentation sont aussi disponibles en lignes.

Pour cette exemple, nous allons utiliser un petit service Java. Je vous laisse télécharger le projet d’exemple “reflexTuto1”, et regarder :

le répertoire “java” : les sources Java ( UserDo : l’object de donnée, UserDs : la couche métier ).
Les fichiers de configuration dans le répertoire WebContent/WEB-INF/flex/remoting-config.xml : la configuration des services distants.

Pour cette exemple vous aurez besoin d’un environnement Flex avec les WTP installés ainsi qu’un serveur Tomcat (pour lancer les exemples).

Petit rappel :

Pour installer les WPT ( qui vous donne accès à la perspective J2EE et à la vue server) :
- Ouvrez le menu Help > Software updates > Find and install…
- Faites “Search new features to install”
- Dans la fenêtre qui apparaît, cochez “Europa Discovery Site”
- Cliquez sur “Finish”
- La recherche de plugins commence. Vous devrez choisir votre miroir. La fenêtre de résultats s’affiche. Déployez “Europa Update Site” et cochez “Web and J2EE Development”
- Cliquez sur le bouton “Select Required”
- Faites “Next”
- Cochez “I accept…”
- Faites “Next” de nouveau
- Faites “Finish”
Pour installer un serveur TOMCAT
- Téléchargez un Tomcat 6
- Décompressez l’archive dans le répertoire de votre choix
- Vous devez configurer votre serveur dans Flex à partir de la vue Server : « Windows > Other View… » puis « Servers«
- Un fois configuré (clic droit dans la vue servers et « New…« ), n’oubliez pas d’ajouter votre projet sur votre serveur ! (clic droit dans la vue servers et « Add and remove projects…« )

Au départ : un service et un objet de données

Tout d’abord nous devons représenter l’objet de données du serveur dans votre projet.

L’objectif est d’avoir une image identique des données côté serveur et côté Flex, afin que les 2 parties “parlent la même langue” : cette classe contient une référence vers son “image” côté serveur.

package dataObject
{

	[Bindable]
	[RemoteClass(alias="User.UserDo")]
	public class UserDo
	{
		public function UserDo()
		{
		}

		public var login:String;
		public var name:String;

	}
}

Nous voulons discuter avec la couche server : nous allons donc utiliser un service de type RemoteObject, faisant référence à notre couche serveur, défini dans le fichier remoting-config.xml.

Le Modèle

Le modèle est notre réceptacle de données.
Cette classe étend BaseModel, qui permet l’enregistrement automatique du modèle dans le ModelLocator.
C’est lui qui sera mis à jour par le contrôleur, et qui, via le tag [Bindable], mettra a jour là vue. Dans notre exemple nous allons stocker le UserDo, résultant de la requête serveur login().

package model
{
	import com.lafabrick.reflex.model.BaseModel;

	import dataObject.UserDo;

	public class UserModel extends BaseModel
	{
		[Bindable]
		public var userLogged:UserDo;

	}
}

Le Contrôleur

C’est l’intelligence du système. C’est lui qui invoque le service, récupère et met à jour les données.

package controller
{
	import com.lafabrick.reflex.controller.BaseController;
	import com.lafabrick.reflex.model.ModelLocator;

	import dataObject.UserDo;

	import model.UserModel;

	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	public class UserController extends BaseController
	{

		public function login( log:String, pass:String ) : void
		{
			executeMethod( "login", onLoginResult, onLoginFault, log, pass);
		}

		public function onLoginResult( event:ResultEvent ) : void
		{
			(ModelLocator.getModel( UserModel ) as UserModel).userLogged =
				event.result as UserDo;
		}

		public function onLoginFault( event:FaultEvent ) : void
		{
			trace("Bad result ..."+event.fault);
		}
	}
}

Cette classe étend BaseController, qui permet l’enregistrement automatique du contrôleur dans le ControllerLocator.
La méthode login() contient la mécanique de déclenchement du service (méthode de BaseController). La méthode executeMethod est définie par les propriétés suivantes :
- method:String : le nom de la méthode ( “login” ),
- resultFunction:Function : la fonction déclenchée lorsque le serveur renvoie un résultat (onLoginResult)
- faultFunction:Function = null : la fonction déclenchée lorsque le serveur renvoie une faute (onLoginFault)
- … args : tous les arguments à passer à la méthode distante…
Le modèle est mis à jour dans le fonction de résultat. Pour récupérer l’instance du modèle, il suffit d’utiliser le ModelLocator :
```
// Renvoie l'instance UserModel enregistré dans ModelLocator
trace( ( ModelLocator.getModel( UserModel ) as UserModel ) );
```

NOTE : les “locator” ModelLocator et ControllerLocator n’enregistrent qu’une et une seul instance d’un même modèle / contrôleur. Si deux instances d’un même modèle / contrôleur sont déclarées, une erreur ReflexError est levée. Les classes étendant BaseController et BaseModel sont automatiquement référencées dans ModelLocator et ControllerLocator.

La Vue

Construisons maintenant notre vue.

Nous créons une instance RemoteObject permettant de pointer sur le service côté serveur. La propriété destination est l’identifiant du service dans le fichier remoting-config.xml.
Nous créons une instance de UserController, avec comme propriété service l’identifiant du RemoteObject “remoteUser”.
De la même manière, nous créons l’instance du modèle UserModel.
Au final, la vue appel la méthode login() du contrôleur, qui se charge d’envoyer et de réceptionner les données au serveur. Au retour, le contrôleur met à jour le modèle, en “poussant” le UserDo provenant du serveur. La vue est automatiquement mise à jour via le principe de Binding des données.

Les sources de cette exemple

Conclusion

Reflex n’a pas la prétention de concurrencer des architectures reconnues comme PureMVC ou MATE. L’objectif, vous l’aurez compris, est d’aller à l’essentiel, sans se perdre dans la forêt des Design Pattern, pour une productivité la plus efficace possible. A vous d’implémenter cette architecture selon vos besoins.

Le prochain tutoriel ira un peu plus loin dans cette micro-architecture : comment mieux découper son projet, et comment associer un fichier de configuration XML externe (package IOC).

J’attends vos retours !Autres articles sur le même sujet

Développer une application iPhone – Introduction aux concepts de base

Hervé — Sun, 11 Jan 2009 23:33:28 +0000

Introduction

Il est des petits appareils qui font envie de nos jours : l’iPhone fait certainement partie des premiers de cette liste.

Voilà donc un tutoriel d’approche d’une technologie nouvelle pour des personnes n’ayant aucune notion de développement dans ce domaine.

Je parlerai donc ici :

Des principaux concepts à maîtriser absolument pour bien démarrer un développement pour iPhone
De quelques exemples permettant d’illustrer les concepts

Je ne parlerai pas :

Des différences entre un développement pour Mac par rapport à un développement pour iPhone
De quelconques « best practices » de développement

Il s’agit plutôt d’un retour d’expérience qui permettra peut-être à d’autres personnes d’appréhender un développement pour iPhone sans trop se casser les dents.

Pour la suite, la documentation fournie par Apple est très complète et peut vous donner de quoi satisfaire vos nuits blanches pour un bon moment !

Pour bien démarrer

Comprendre l’environnement nécessaire au développement d’une application iPhone
1. Les principaux concepts
2. Les outils
Ouvrir quelques projets d’exemple pour se familiariser avec la syntaxe Objective-C
Créer son premier projet

Ce premier article présente les concepts et introduit la liste des outils nécessaires au développement.

Note aux pressés (j’en fais généralement partie)

Si vous grillez les deux premières étapes, vous risquez rapidement de vous rendre compte qu’elles vous manquent et perdrez certainement beaucoup plus de temps que si vous y consacrez une petite journée.

Comprendre l’environnement nécessaire au développement d’une application iPhone

Les principaux concepts

Pour commencer, il est indispensable de maîtriser quelques bases de fonctionnement d’un programme iPhone.

Une application iPhone est une application MVC dans sa plus pure forme. Vous concevez des vues, manipulées par des contrôleurs en faisant transiter des données d’un modèle.

Application delegate

Il s’agit de la classe en charge du lancement de l’application et de l’affichage de la fenêtre principale.
Vous pouvez vous en servir pour initialiser des éléments particuliers communs à l’ensemble des éléments de votre application :

connexion à une base de données,
configuration générale,
…

View controller

Classe gérant la vue et pouvant recevoir les événements propres aux composants de la vue gérée.

View

Une vue, chargée d’afficher des contrôles.

Il faut savoir qu’une vue peut être créée par programme ou en utilisant des fichiers de ressources définis à l’aide de l’interface builder.

Ce sont deux moyens différents qui présentent leurs avantages et inconvénients… A vous de voir lequel convient le mieux à telle ou telle situation.

Delegate

C’est un terme souvent employé dans un programme.

Un délégué est un objet prenant en charge un certain nombre de méthodes remplissant des fonctions propres à un émetteur.

En pratique, un view controller est, dans la plupart des cas, désigné comme délégué des composants de la vue et va implémenter les méthodes répondant aux événements que chacun d’entre eux déclenche.

Par exemple, un composant table view (tableau) va appeler différentes méthodes de son délégué pour pouvoir s’afficher convenablement :

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
Doit renvoyer le nombre de sections dans le tableau

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
Doit renvoyer le nombre de lignes du tableau à afficher pour la section dont le numéro est passé en paramètre

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath
Doit initialiser une cellule du tableau pour le numéro de section et de ligne passé en paramètre

Ce mode de fonctionnement permet notamment que n’importe que objet soit désigné comme délégué. On peut donc très bien imaginer avoir les deux possibilités suivantes :

Le schéma A montre l’exemple le plus courant : une seule classe faisant office de ViewController et de Delegate pour l’ensemble des contrôles de la vue.
Le schéma B montre une alternative intéressante lors de gestion de vues complexes : une classe Delegate par contrôle et un ViewController standard.

La différence entre ces deux solutions, c’est que le premier ViewController contiendra l’ensemble du code de BoutonDelegate, Tableau1Delegate et Tableau2Delegate, le rendant peut-être plus complexe à lire et à comprendre.

Ceci étant dit passons aux outils.

Les outils

Vous avez trois outils à votre disposition :

XCode : l’environnement de développement en charge de coder, compiler et lancer la deuxième application
Le simulateur iPhone : une application simulant à quelques restrictions près un iPhone et vous permettant de tester unitairement vos fonctionnalités
Interface Builder : l’outil de création d’interfaces (écrans, vues…)

XCode est un peu l’application maître et lance ses 2 gentils larbins pour faciliter le développement.

Dans le prochain article, passage aux choses sérieuses : nous ouvrirons XCode pour voir comment cette théorie se traduit en pratique, histoire d’illustrer un peu ces jolis concepts.

A la prochaine !
Autres articles sur le même sujet

Cocomo ? Kezako ?

Erick — Mon, 22 Dec 2008 15:58:49 +0000

LaFabrick invitée sur FlashXpress » votre première application collaborative en 15mn ! Mais pourquoi diable se priver !!???

Autres articles sur le même sujet