J’pensais pas faire ça aujourd’hui…, mais bon… moultes skins Spark à tomber : j’ai décidé de me helper myself et de gagner de l’argent ( enfin du temps pour commencer ). Du coup est née la petite commande Fireworks copyMXMLSelectionToClipboard, qui comme son nom l’indique presque, permet de copier une sélection dans Fireworks directement en MXML dans le ClipBoard. Elle est pas belle la vie ?!

En gros :
1. tu dessines tes trucs dans Fireworks, tu fais tes jolies dégradés, tes reflets, tes subtils petits floutés…
2. tu sélectionnes ce que tu veux mettre dans ta skin
3. tu lances la commande ‘UIGFx/SelectionToMXMLClipboard »
4. t’ouvres ta skinClass et pi t’y colle

5. et pi… tu souris !

Cette 1ère version permet d’exporter les Rect, les Path et des Groups ( de Rect et de Paths ! ),
avec leur SolidColor / SolidColorStroke, LinearGradient ou RadialGradient,
et même quelques filtres : Blur / DropShadow / InnerShadow.

Les positions sont recalculées avec un sélection placée à l’origine xy.

Télécharger l’extension Fireworks (CS3 + )

Et c’est déjà çà de fait !

Edit : et je rappelle qu’on peut mapper des raccourcis pour n’importe quel élément de menu… #jdcjdrAutres articles sur le même sujet

• Digimix : un Air de musique…
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]
• Flex4 : skin et primitives
• uigfx project : Flex4 primitives library / Fireworks extension

La gestion des States a été entièrement revue dans Flex 4. Déjà fervent utilisateur des states de flex2/3, j’ai entendu quelques critiques à leur propos, et il est vrai que les AddChild relativeTo et autres setEventHandler n’étaient peut-être pas… « idéaux »… Mais ils étaient utiles, car il est des situations, où au sein d’une application, l’utilisation d’états est bien plus « cohérente », voire performante, qu’une navigation « page à page » classique. Leur subtile utilité et leurs récentes améliorations, méritent de s’y intéresser.

Raison d’états

La principale différence entre les states et la navigation « page à page » ( type « viewStack » dans Flex ), est selon moi, que les states permettent la réutilisation et le « partage » d’éléments : l’affichage de l’application/composant ne doit pas être entièrement recréé à chaque changement.
Et c’est justement une des définitions des RIA. De même qu’un écran ne doit pas être entièrement « rechargé » à chaque chargement de données, il ne doit pas forcément être reconstruit entièrement à chaque changement « d’affichage ». En gros : contrairement à des pages, un même objet peut être facilement inclus/utilisé dans plusieurs états.
L’exemple classique est un panel de login qui « contient » un état « inscription », contenant les mêmes éléments que le state normal, mais qui y ajoute un champ de confirmation du mot de passe ( exemple dans Tour de Flex Online) .

Les states permettent de facilement ajouter/supprimer des éléments au cours « du cycle de vie d’un composant ».

Dans mon exemple, c’est plus globalement l’apparence de l’application entière qui varie en fonction de son état.

Les states permettent de modifier les attributs des différents élements MXML inclus dans le composant ( propriétés publiques, styles, événements et effets d’événements ). Ainsi un composant et ses « enfants » peuvent avoir une taille, une couleur, un comportement différent à chaque état.
Dans la documentation officielle, la définition d’un state est « une collection de changements applicables à une vue ». Avec Flex4, c’est principalement la syntaxe de la définitions de ces changements qui a été simplifiée.

Coups d’états : une nouvelle syntaxe

La nouvelle syntaxe des états s’appuie sur l’évolution du MXML avec sa version 2009 ( MXML 2009 ). Ce dernier intègre pleinement cette notion d’état, en permettant à chaque attribut de composant MXML d’être défini pour un état en particulier.

Déclaration

La première chose à noter est la déclaration, en début de fichier, de la liste des états du composant.

<s:states>
        <s:State name="default"/>
        <s:State name="Register"/>
</s:states>

Les « changements /actions d’états » ne sont donc plus définis de manière hiérarchique au sein du noeud State lui même.

Modification des propriétés de composants

En parcourant le code source de l’exemple, on tombe sur la déclaration du bouton de validation du formulaire :

<s:Button id="button1" click="clickHandler(event)"
     label="Login"
     label.Register="Register"
/>

Le label du Button varie en fonction de l’état du composant qui le contient, et une « syntaxe pointée » permet maintenant de préciser la valeur de l’attribut dans l’état « Register ».
Dans la définition d’un attribut MXML, il est maintenant possible de définir si la valeur est « globale » ou liée à un état ( ou même à plusieurs, cf. StateGroups plus bas ). L’id ne peut évidement pas être « state based ».

<s:Button id="bt"
     label.default="login" label.Register="inscription"
     width.default="80" width.Register="120"
     color.default="#000000" color.Register="#0000FF"
     click.default="trace('default»register');currentState = 'Register';"
     click.Register="trace('register»default');currentState = 'default';"
     rollOverEffect.default="{new Blur()}"
     rollOverEffect.Register="{new Glow()}"
     />

FlashBuilder 4 beta 2 intègre déjà une aide à l’édition d’attribut « state based », et d’après ce que j’ai pu lire il y aura encore d’autres fonctionnalités liées dans la release…

De même, il est possible de définir les propriétés d’un composant à l’aide d’un sous noeud plutôt qu’un attribut, et on peut, dans ce cas aussi, préciser à quel état le noeud est associé.
Dans mon exemple, profitant de la nouvelle gestion des Layouts de composants, mon Application peut être « verticale », « horizontale » ou en « tile ». Il suffit de préciser la valeur du layout pour chaque état.

<s:Group id="content" x="10" y="40"
			 >
		<s:layout.vList><s:VerticalLayout /></s:layout.vList>
		<s:layout.hList><s:HorizontalLayout /></s:layout.hList>
		<s:layout.tile><s:TileLayout /></s:layout.tile>
...
</s:Group>

ou encore telle bordure FXG visible uniquement dans l’état ’tile’ :

<s:Group styleName="box" >
			<s:Rect width="80" height="80" >
				<s:fill>
					<s:SolidColor color="#CCCCCC"/>
				</s:fill>
				<s:stroke.tile>
					<s:SolidColorStroke color="#999999" />
				</s:stroke.tile>
			</s:Rect>
			<!--...-->
</s:Group>

A l’heure des applications multi-devices, ce genre de souplesse est certainement bienvenue ( exemple d’application proposant un state « desktop » et un autre « mobile » )…

Inclusion / Exclusion

En plus des évolutions syntaxiques, 2 nouveaux attributs ( des « directives de compilation » en fait ) ont été ajoutées : includeIn et ExcludeFrom, remplacant les mx:AddChild et mx:RemoveChild de Flex 3.

<mx:LinkButton id="registerLink" color="0x336699"
                                   includeIn="default"
                                   label="Need to Register?"
                                   click="currentState='Register'"/>

Ici, le bouton d’inscription n’est visible que dans l’état ‘default’.
Même fonctionnement, résultat inverse pour l’attribut excludeFrom, qui permet comme son nom l’indique de préciser qu’un « enfant » doit être supprimé de la liste d’affichage dans un état… ou dans un groupe d’état…

Les stateGroups : des états unis…

Une nouvelle propriété voit également le jour dans la définition des états : le stateGroups. Cette propriété permet de lier entre eux plusieurs états.
Voici par exemple la définition des états du composant ToggleButton version Spark.

<s:states>
        <s:State name="up" />
        <s:State name="over" stateGroups="overStates" />
        <s:State name="down" stateGroups="downStates" />
        <s:State name="disabled" stateGroups="disabledStates" />
        <s:State name="upAndSelected" stateGroups="selectedStates, selectedUpStates" />
        <s:State name="overAndSelected" stateGroups="overStates, selectedStates" />
        <s:State name="downAndSelected" stateGroups="downStates, selectedStates" />
        <s:State name="disabledAndSelected" stateGroups="selectedUpStates, disabledStates, selectedStates" />
    </s:states>

Des groupes d’états sont ainsi définis, et vont nous permettre d’assigner des valeurs d’attributs non plus pour un, mais pour plusieurs états. Chaque state peut appartenir à un ou plusieurs groupes, et chacun de ces groupes n’est finalement défini que par une chaîne de caractères.

<s:Rect id="highlight" left="1" right="1" top="1" bottom="1" radiusX="2">
        <s:fill>
            <s:LinearGradient rotation="90">
                <s:GradientEntry color="0xFFFFFF"
                                 ratio="0.0"
                                 alpha="0.33"
                                 alpha.selectedUpStates="0.22"
                                 alpha.overStates="0.22"
                                 alpha.downStates="0.12"/>
                <s:GradientEntry color="0xFFFFFF"
                                 ratio="0.48"
                                 alpha="0.33"
                                 alpha.selectedUpStates="0.22"
                                 alpha.overStates="0.22"
                                 alpha.downStates="0.12"/>
                <s:GradientEntry color="0xFFFFFF"
                                 ratio="0.48001"
                                 alpha="0" />
            </s:LinearGradient>
        </s:fill>
    </s:Rect>

Dans le ToggleButton, l’alpha du dégradé clair varie ici en fonction du groupe d’appartenance de l’état en cours.

En complément des groupes, la classe State propose toujours l’attribut basedOn, permettant à un état d’hériter de toutes les modifications définies pour un autre, et d’en ajouter.

Event d’états…

À l’instar des states Flex 3, des événements sont émis à chaque changement :

• enterState
• exitState ( attention : si l’état B est « basedOn » l’état A, l’event exitState n’est pas émis au passage de A à B. )

Toutefois, étant donné la séparation entre « logique » et « graphique » conseillée avec Spark, l’intérêt d’écouter ces événements « côté skin » devient à mon avis plus rare.

Des états stylés…

Les états ne sont pas les seuls à avoir connu une intéressante évolution dans Flex 4 : la gestion des styles CSS a également été considérablement enrichie. Cela pourrait constituer un article à part entière, mais je n’aborderais ici que les évolutions liées à notre sujet du jour.
Grâce à des pseudo-selecteurs CSS, il est maintenant possible de définir des styles basés sur l’état d’un composant.

<fx:Style>
		@namespace "library://ns.adobe.com/flex/spark";
		@namespace mx "library://ns.adobe.com/flex/halo";

		Application:hList Label
		{
			color:#0CF;
		}

</fx:Style>

ici, la feuille de style définit que le texte des composants Label de l’application en état hList doivent être bleus.

Et puis quoi encore ?

Code source de l’exemple du layout « state based »

Il y aurait encore pas mal de choses à aborder à propos de cette nouvelle gestion de states : gestion des transitions, « ré-adoption parentale » ( Reparent ), « régles d’instanciation »…
Mais je vais finir aujourd’hui par une petite interlude musicale…

Bon weekend…

Autres articles sur le même sujet

• Flex4 : composant personnalisé et skinning
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark
• Primitive DashedLine : une petite ligne bien utile
• UIGFX practice : a CircularSlider component

Vous le savez surement, la beta de Flash Player 10.1 nous permet maintenant à nous aussi, practiciens de la flash platform, d’entrer dans l’ère de l’expérience tactile. « Pretty exciting »! pourrait-on s’exclamer, mais puisque l’air du temps est plutôt à l’identitaire national, faisons un effort et parlons « franc » : le multi-toucher, çà envoie bien du cervelas en croûte !!!

Bon alors par contre pour profiter dès aujourd’hui du jouet, il est nécessaire de valider une des conditions suivantes :
- posséder un macbook (pro) récent sous snow leopard ( 10.6 ) (je sais pas trop si ca marche avec les magic mouse)
- posséder un pc sous windows 7… avec écran multitouch
- ou encore plus rare, faire partie des betatesteurs du prochain flash CS(x)… et d’une licence de dev iphone… et d’un iphone… ( d’ici quelques mois, les possesseurs de la plupart téléphones/tablettes tactiles et du prochain flash CS(x) pourront eux aussi jouer ).

Installation

Si tu as passé la 1ère épreuve, il te reste l’épreuve pratique : l’installation du SDK et du runtime AIR 2.0 ( beta1 ou beta2 )

Pour une installation « optimale » :
- Flash Builder Beta2 : http://labs.adobe.com/technologies/flashbuilder4/
- une version stable récente du SDK Flex : 4.0.0.13875 datée du 29.01.2010 http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4 ( pas mal de choses ont évoluées depuis la version 4.0.0.10485 distribuées avec Flash Builder beta 2 )
- placez le contenu du SDK téléchargé dans : Dossier Flash Builder Beta2/sdks/
- Installez le runtime et téléchargez le SDK AIR 2 beta 2 cf. guide d’installation du SDK
- Dans les préférences de FlashBuilder/Eclipse : Flash Builder / installed Flex SDKs / , ajoutez le SDK modifié pour AIR 2.

Et maintenant, la création du projet :
Nouveau projet Flex : Application Type : Desktop / AIR, SDK version : 4.0 ( celle avec mise à jour du SDK AIR 2 )

AS3 et le multi-toucher, comment çà marche ?

Premièrement, on trouve maintenant dans le package flash.ui une nouvelle classe Multitouch.
Elle permet de tester les compatibilités de l’environnement ( nombre de pressions/doigts gérés, combinaisons tactiles gérés… ) , et de définir le « mode tactile » : Gesture ou TouchPoint.
Ce dernier précise si l’on veut capter les « combinaisons tactiles » classiques : Rotation, Glisser, Zoom et « Grand coup » ( NDLR = Swipe, déplacement de trois pression/doigts ) ou le détail de chaque pression/doigts. Dans la beta actuelle, seul Windows 7 permet la gestion du mode « TouchPoint », les utilisateurs de OSX devront se « contenter » des combinaisons classiques.

trace( 'max touch : ' , Multitouch.maxTouchPoints );
trace( 'supportsGestureEvents : ' , Multitouch. supportsGestureEvents );
trace( 'supportsTouchEvents : ' , Multitouch. supportsTouchEvents );
trace( 'supportedGestures : ' , Multitouch. supportedGestures );
if( Multitouch. supportsTouchEvents )
     Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
// par défaut = MultitouchInputMode.GESTURE

Ensuite c’est l’autoroute :ajout des écouteurs d’événements qui vont bien, et c’est bon… tu peux caresser ton flex. Chaque transformGestureEvent contient, en fonction de son type, un offSetX/offSetY ( pan & swipe ), un scaleX/scaleY ( zoom ) ou une rotation.

// gestures prises en charge par OSX 10.6 avec FP 10.1 b2
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_PAN, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_SWIPE, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_ROTATE, onGesture );
interactiveObject.addEventListener( TransformGestureEvent.GESTURE_ZOOM, onGesture );

public function onGesture( e:TransformGestureEvent ):void
{
     // phase = GesturePhase.BEGIN, GesturePhase.UPDATE ou GesturePhase.END
     trace( 'Gesture :', e.type, ' phase :', e.phase );

     // tu fais des trucs en fonctions du types de toucher
     switch( e.type )
     {
           case TransformGestureEvent.GESTURE_PAN:
                  interactiveObject.x += e.offsetX;
                  interactiveObject.y += e.offsetY;
           break;

           case TransformGestureEvent.GESTURE_SWIPE: // déplace de 50 pixels
                  interactiveObject.x += e.offsetX * 50;
                  interactiveObject.y += e.offsetY * 50;
           break;

           case TransformGestureEvent.GESTURE_ZOOM:
                  interactiveObject.scaleX +=  e.scaleX - 1 ;
                  interactiveObject.scaleY +=  e.scaleY - 1 ;
           break;

           case TransformGestureEvent.GESTURE_ROTATE:
                  interactiveObject.rotation += e.rotation;
           break;
     }
}

Plutôt simple, mais plein de potentiel…

Avec ces 4 gestures on peut quand même « gérer » 8 + 4 + 2 + 2 soit 16 combinaisons si on prend en compte les directions de chaque gesture. Exemple : SWIPE horizontal = 1 fonction, SWIPE vertical = 1 autre, PAN horizontal = 1 fonction…
L’exemple du magazine interactif pourrait par exemple parfaitement bénéficier de ces différentes combinaisons. À ce niveau tout un vocabulaire tactile reste à imaginer/compléter.

Bref, moi je suis bien content de pouvoir me caresser le flex !!!

GestureTracker

Par contre, en vrai novice de la programmation orientée caresse, mes premières touches furent, comment dire… hésitantes; du coup je me suis créé un petit assistant pour m’aider à la tâche, ou à la touche : le GestureTracker, un petit système de notification de gestures. Le but : calculer et visualiser les gestures en cours, leur valeurs et les transformations globales appliquées.

Pour le moment c’est pour les projets AIR 2 sous Flex 4, la version AS3 à suivre…

C’est tout pour le moment, v’là pour l’exemple air ( AIR Runtime 2.0 beta 2 est requis) , le swc du SparkGestureTracker et les sources.

Pour plus d’infos :
Un tuto sur le multitouch , une partie des réponses aux nombreuses interrogations sur les compatibilités actuelles et à venir.

Autres articles sur le même sujet

• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Interfaces tangibles : le futur du multitouch
• MAX 09 – Le multitouch
• RollingFileTarget pour AIR 2.0 : let’s roll !

Bien le bonsoir,
on avait imaginé une cinquième édition des Serious Drink complétement serious pour le coup… annoncée plusieurs semaines à l’avance… avec un videoproj, des beaux thèmes PowerPoint, des chips, des olives, et quelques rythmes neojazzy en interlude entre chaque présentations… la sseuclaaa !
mais bon le temps a passé, tout était bien parti… sauf les « invitations »… toujours pas parties elles… tanpis , on a quand même soif !!!
Du coup on a une petite salle réservée, mais trève de sérieux, on garde le thème classique :

Soirée Bière et fleeex donc au 1er étage du Café Cousu Jeudi le 23 d’avril à partir de 19h30 !!!
Viendez y !!!

Passage Thiaffait
19,rue René Leynaud
69001 Lyon
Tel: 04 72 98 83 38

Voir où que c’est sur une carteAutres articles sur le même sujet

• Climatus et lafabrick sur le petit écran….
• 3 minutes pour sauver vos futurs présentations…
• L’université Lyon1 cherche (aussi) 2 stagiaires
• Serious Drink 0.09.01.08…

Vous venez de créer votre douzième workspace Eclipse/Flex Builder ??? Et vous en avez marre de recréer vos perspectives, et autres vues… à chaque fois ???

Mais pourquoi diable n’utilisez vous pas les « fameux » ‘working sets’ ?

Et puisque quelques pixels valent pleins de mots…

Les working sets ( prononcez ‘setss’ )… tout simplement la solution moderne aux problèmes de congestion de projets dans Eclipse & Flex Builder !Autres articles sur le même sujet

• WTP – Flex Buider : résoudre les problèmes de mémoire
• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Flex Builder 3 et le PHP ( PDT ) : installation
• Flex et les warnings inutiles…

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 )

<?xml version="1.0" encoding="utf-8" ?>
<mx:Application layout="absolute"
 xmlns:mx="http://www.adobe.com/2006/mxml"
 xmlns:rtc="AfcsNameSpace"
 >
<rtc:ConnectSessionContainer id="sessionManager" width="500" height="400"
 roomURL="http://connectnow.acrobat.com/yourAccount/roomName"
 authenticator="{identificator}"
 backgroundColor="#FFFFFF"
/>
<rtc:AdobeHSAuthenticator id="identificator"
 userName="votreLogin" password="VotreMotDePasse"
/>
</mx:Application>

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

<?xml version="1.0" encoding="utf-8" ?>
<mx:Application layout="absolute"
    xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:rtc="AfcsNameSpace"
>
     <mx:Script>
         <![CDATA[
             import mx.controls.Alert;
             import com.adobe.rtc.events.SessionEvent;

             // session's state
             private var isConnected:Boolean = false;

			// when a "server synchronization" event is dispatched
             public function onSynchro( e:SessionEvent ):void
             {
                 if ( sessionManager.isSynchronized &&  ! isConnected )
                 {
                     Alert.show("Application connectée");
                     isConnected = true ;
                 }
             }
     ]]>
 </mx:Script>
<rtc:ConnectSessionContainer id="sessionManager"
    width="100%" height="100%" backgroundColor="#FFFFFF"
    authenticator="{identificator}"
    roomURL="http://connectnow.acrobat.com/regartdemo/meetingzone"
    synchronizationChange="onSynchro( event )"
/>
<!-- Authentication component -->
 <rtc:AdobeHSAuthenticator id="identificator"
   userName="YourUserName" password="YourPassword"
   authenticationSuccess="Alert.show('authentication success')"
   authenticationFailure="Alert.show('authentication failed')"/>
</mx:Application>

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 :

<rtc:ConnectSessionContainer id="sessionManager" width="100%" height="100%" backgroundColor="#FFFFFF"
   authenticator="{identificator}"
   roomURL="http://connectnow.acrobat.com/votreCompte/nomSalon"
   synchronizationChange="onSynchro( event )"
   >

   <!-- PODS -->
   <mx:VBox width="50%" height="100%" horizontalAlign="center">

      <rtc:WebCamera id="webcam" width="300" />

      <rtc:SimpleChat id="chat" width="100%" height="100%" />

   </mx:VBox>

   <mx:VBox width="50%" height="100%"  right="0">

     <rtc:FileShare id="fileManager" width="100%" height="50%" />

      <rtc:Note id="notes" width="100%" height="50%" />
   </mx:VBox>
</rtc:ConnectSessionContainer>

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é ) :

<mx:Panel id="logPanel" >
   <mx:Form>

      <mx:FormItem label="Login">
         <mx:TextInput id="chp_login" />
      </mx:FormItem>

      <mx:FormItem label="your role :" direction="horizontal" >

         <mx:RadioButtonGroup id="userRole" />

         <mx:RadioButton id="isGuest" groupName="userRole"
            label="Guest" value="{UserRoles.VIEWER}"  selected="true"
         />
         <mx:RadioButton id="isOwner" groupName="userRole"
            label="Host" value="{UserRoles.OWNER}"
         />
      </mx:FormItem>

      <mx:FormItem label="Password"  enabled="{ userRole.selectedValue == UserRoles.OWNER }">
         <mx:TextInput id="field_password" displayAsPassword="true"  />
      </mx:FormItem>

      <mx:FormItem >
         <mx:Button label="Enter"
            click="login(chp_login.text , userRole.selectedValue == UserRoles.OWNER ? field_password.text : null  )"
          />
      </mx:FormItem>

   </mx:Form>
</mx:Panel>

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();
}

<mx:VBox width="50%" height="100%" horizontalAlign="center" right="0">
    <mx:Button label="Logout" click="logout()" />

    <rtc:FileShare id="fileManager" width="100%" height="50%" />

    <rtc:Note id="notes" width="100%" height="50%" />
</mx:VBox>

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 CocomoDevConsoleAFCSDevConsole et le LocalConnectionServer, les deux outils AIR proposés dans le SDK.

D’ici là bonne collaboration !!!

Autres articles sur le même sujet

• Cocomo est là et personne me prévient ??!!
• Cocomo ? Kezako ?
• Utiliser le DragManager de Flex ( 1ère partie )
• Developing with AFCS a.k.a Cocomo – Introduction

On dirait que les rotations 3D de FP10 arrivent à point… ;-p

Et vous ? vous z’en connaissez des exemples d’interfaces « utilement » en 3D ???

Plus d’info sur BeeDocs

Autres articles sur le même sujet

• Flex Active Desktop : le webGadgetOS qui fait de l’effet !
• TileUI : un bureau « réaliste » en AS3
• Le design déclaratif à un nom : Degrafa
• JavaFX et Open Screen Project, ou la naissance des applications universelles…

Autres articles sur le même sujet

• Cocomo est là et personne me prévient ??!!
• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Developing with AFCS a.k.a Cocomo – Introduction
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

Alors pour les plus sages, je ne saurais que trop conseiller cette énorme rechute en enfance :

Quelques legos, une brique programmable ( un cerveau ), 3 moteurs, des capteurs ( sons, lumière, bouton … ) : régression garantie !!! De quoi créer toutes sortes de Fantastic Contraptions,  … mais en vrai

Par contre pour les absentéistes et les chahuteurs chroniques du dernier rang : pas de cadeaux !!! Des devoirs de vacances …
 

Preuve que  j’ai vraiment été très sage cette année :p. Du coup j’ai commandé le gros jouet !!! Et comme Noël c’est quand même plus simple quand on est grand, j’ai commandé direct au fournisseur du Père Nöel… pratique ! Et puis vu que j’avais pas de sapin où le planquer, je l’ai posé au milieu du salon… et puis vu que je suis pas une moitié d’enfulte, le premier matin des « vacances » je me suis jeté dessus . Et depuis 36h maintenant… j’ai 10 ans !!!

Et je vous présente r.CØ, notre nouveau copain d’aventures…

Joyeuses fêtes !!!Autres articles sur le même sujet

• Introducing r.CØ … First « Cocomo ready » Air Wiibot…
• Flex Builder 3 et le PHP ( PDT ) : installation
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]
• Thanks Adobe, U certified me !!!

La classe DragManager permet quant à elle de définir des comportements de drag’n'drop avec n’importe quel composant graphique Flex.

Certains composants propose des propriétés dragEnabled ou dropEnabled permettant de gérer les transferts depuis et vers eux :

<dataGrid dragEnabled= "true"   dragMoveEnabled = "true" dropEnabled="true" />

La classe DragManager va nous permettre de créer notre propre mécanisme de glisser / déposer. Voyons un exemple d’utilisation de cette classe à travers la création d’un jeu de « mot dans le désordre ».

Exemple  / Source

Fonctionnement 

Une opération de « glisser / déposer » se fait en 3 étapes :

1. le clic sur l’élément à déplacer 

2. Le déplacement de l’élément

3. Le dépot de l’élément

La classe DragManager va nous permettre de gérer  : 

- la copie et le transfert des données

- la création d’une « image proxy » ( représentant l’objet pendant le déplacement )

- la vérification des droits de dépôt de l’élément

Durant les trois étapes, nous aurons à écouter les événements de la classe DragEvent émis à la fois par le composant déplacé et par les « composants cibles potentiels » ( les composants survolés ).

Nous utiliserons également :

- les méthodes statiques de la classe DragManager pour initier le déplacement ( doDrag( … ) ) et vérifier le droit de dépot ( acceptDragDrop(…) )

-  un objet DragSource pour transférer les données.

1. Le déplacement

1.1  Capter l’évenement mouseDown

Pour permettre le déplacement d’un composant graphique Flex,, il faut créer un écouteur d’événement MouseEvent.MOUSE_DOWN sur les objets pouvant être déplacés :

<mx:Label id="l"

fontSize="32" text="{rpSrc.currentItem.lettre}"

horizontalCenter="0" verticalCenter="0"

mouseDown="drag( event )"

/>

1.2  Stocker les données déplacées et initier le déplacement

A chaque émission de cet événement, nous allons:

- créer une instance de DragSource et y rajouter les données à déplacer

-  appeler  la méthode statique DragManager.doDrag(…) pour initier le déplacement

private function drag( e:MouseEvent):void

{

var dgData:DragSource = new DragSource();
var dgText:String = (e.target.parent as Label).text ;
dgData.addData( dgText  , "lettre" );

dgData.addData( getLetterPosition(dgText) , "position" );

DragManager.doDrag( UIComponent(e.target.parent) , dgData, e );

}

Pour stocker les données dans l’objet DragSource, on peut utiliser  la méthode addData( donnée:Object , nomPropriété:String ) 

Les données peuvent être utilisées pour vérifier les « droits de dépots » sur un composant cible.

La méthode doDrag( … ) du composant DragManager nécessite quant à elle plusieurs paramètres :

 - le dragInitiator  : IUIComponent ( obligatoire ) : le composant ayant initié le déplacement, généralement l’objet déplacé

 - la dragSource : DragSource ( obligatoire ) : instance de DragSource contenant les données devant être déplacées

- le mouseEvent : MouseEvent ( obligatoire ) : événement à l’origine du déplacement ( MouseEvent.MOUSE_DOWN )

- la dragImage : IFlexDisplayObject ( optionnel / default = null ) : « Image proxy » utilisée pour représenter le composant déplacé durant le déplacement. Si aucune image n’est défini, un rectangle gris est dessiné par défaut.

- le xOffSet : Number ( optionnel / default = 0) : position horizontale de l’image proxy par rapport au curseur.

- le yOffSet : Number ( optionnel / default = 0 ) : position verticale de l’image proxy par rapport au curseur 

- l’ imageAlpha : Number ( optionnel / default = 0.5 ) : opacité de l’image proxy

- allowMove : Boolean ( optionnel / defaut = true ) : les données peuvent être transférées ( couper / glisser / coller ) sur un objet cible.

Le composant n’est pas lui réellement déplacé avant le drop. DragManager crée une dragImage qui représente le composant déplacé. Une fois le dépôt effectué, si il est autorisé par le composant cible, les données peuvent être  transférées de « l’objet source » à « l’objet cible ».

2. Survol des cibles

Lorsque le composant déplacé survole des composants potentiellement « cibles », ces derniers émettent des événements DragEvent.DRAG_ENTER.

<local:DropableCanvas width="60" height="80"

    dragEnter="isDropable(event)"

>

Nous allons pouvoir écouter ces événements afin de tester si l’objet peut être déposé sur l’objet survolé.

Le plus simple est de vérifier si le dragSource contenu dans le DragEvent.DRAG_ENTER contient certaines propriétés.

A chaque dragEnter, la méthode isDropable() est appelée.

Si la/les proprieté(s) recherchée(s) sont bien présente(s) dans le dragSource , on peut appeler la méthode  DragManager.acceptDragDrop( target : IUIComponent ) où target est le composant pouvant accepter le dépot des données.

private function isDropable( e:DragEvent ):void

{

    var dgData:DragSource = e.dragSource ;

    // référence du champ texte du Canvas Cible

    var cibleText:Label = Container(e.target).getChildAt(0) as Label ;

   // si le champ cible est différent du champ source et que le champ cible est vide : autoriser le drop

   if ( e.dragInitiator != cibleText && cibleText.text == "" )

       if ( dgData.hasFormat("lettre") && dgData.hasFormat("position") )

         DragManager.acceptDragDrop( UIComponent( e.target ) );

}

Si ce n’est pas le cas, l’objet déplacé sera signalé comme « non autorisé » à être déposé dans le composant cible courant ( curseur « interdit » ).

3. Dépot des données

Pour capter le dépot, on peut écouter :

- l’événement DragEvent.dragDrop sur l’objet « cible ».

<local:DropableCanvas width="60" height="80"

 backgroundColor="#EFEFEF" borderColor="#CCCCCC" borderStyle="solid"

 dragEnter="isDropable(event)"

 dropData="{lettres[rpCibles.currentIndex]}"

 dragDrop="addLettre( event )"

>

La méthode addLettre() est ici appelée lors d’un DragEvent.dragDrop. Cette méthode va nous permettre d’effectuer le transfert de données ( ici la lettre et sa position ).

private function addLettre( e:DragEvent ):void

{

 // récupération des données

 var dropLetter:String = String( e.dragSource.dataForFormat("lettre") );

 var dropPosition:uint = uint( e.dragSource.dataForFormat("position") );

 

 // référence du champ texte du Canvas Cible

 var cibleText:Label = Container(e.target).getChildAt(0) as Label ;

 

 // remplit le champ texte cible

 cibleText.text = dropLetter ;

 

 // si la lettre est déposé dans un Canvas cible : test si elle est déposé à la bonne position

 if ( e.target is DropableCanvas )

    if ( DropableCanvas(e.target).dropData.position == dropPosition )

      cibleText.setStyle( "color" , 0x00FF00 );

}

Dans cet exemple, j’ai ajouté un classe DropableCanvas. Cette classe possède un propriété publique dropData, qui permet de stocker les réponses correctes de chaque « composant de dépôt ». Au moment du drop, cela nous permet de tester si la lettre est bien posée au bon endroit.

- l’évenement DragEvent.dragComplete sur le composant « émetteur ».

Lorsque les données sont « lachées », et quelque soit le résultat du drag’n'drop, l’objet émetteur émet un dragComplete.

<mx:Label id="cibleLabel" fontSize="32"

    horizontalCenter="0" verticalCenter="0"

    mouseDown="drag( event )"

    dragComplete="onDragComplete( event )"

/>

Grâce à la propriété action de l’événement nous pouvons savoir le résultat du drop. ( move, link, none ou copy )

private function onDragComplete( e:DragEvent ):void

{

    if ( e.action == DragManager.MOVE )

       Label( e.target ).text = "";

}

Voir les sources

Dans un prochain tutoriel nous verrons comment personnaliser graphiquement cette opération.Autres articles sur le même sujet

• Petit cours sur l’API de dessin
• Utiliser Cairngorm dans un projet Flex / AMFPHP
• Google AJAX Language API… et ton Flex devient polyglotte !
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs