Nous l’avons vu dans l’exemple précédent, le principal composant d’une application Cocomo est le “gestionnaire de session” ( ConnectSession ou ConnectSessionContainer » implements IConnectionSession cf Documentation ). C’est lui qui permet à l’application de se connecter à un salon ( serveurs Cocomo/ConnectNow ), d’identifier les utilisateurs, et de “synchroniser des données en temps-réel” entre les différentes applications connectées.

Nous allons maintenant nous intéresser plus en détail à ces salons ( les “rooms”) et à leur fonctionnement.

Les salons Cocomo sont des “points de rencontre virtuels” à travers lesquels des applications clientes peuvent synchroniser des données, échanger des flux audio/vidéo et partager des fichiers. Pour permettre cette synchronisation, les salons stockent les données et transmettent les mises à jour aux différents clients “abonnés”.

Les informations stockées et partagées peuvent être de différents types ( cf. SharedModel ), mais fonctionnent tous sur le principe de “modèle de donnée partagé”.

Modèle partagé de donnée ( SharedModels )

Un modèle partagé est une classe dont les données sont en quelque sorte “stockées à distance” ( ici dans un salon Cocomo ). Pour assurer que tous les clients seront bien synchronisés, les mises à jour du modèle ne sont pas directement effectuées côté client. Lorsqu’un client veut effectuer une modification sur modèle ( exemple : envoi d’un message sur le tchat ), la mise à jour est d’abord demandée au salon, côté serveur. Le client envoie en fait un message contenant la modification voulue au salon, et c’est ce dernier qui transmet les nouvelles informations mises à jour à chaque client. De cette manière le nouveau message s’affichera ( quasiment ) en même temps chez l’émetteur et les destinataires du message. C’est ce mécanisme qui assure que les différents clients connectés partagent en permanence les mêmes données.

Cocomo ( les composants et les salons ) intégre un mécanisme de vérification des droits, par conséquent, lors de chaque “demande de modification”, le salon va vérifier si l’utilisateur à l’origine de la “publication” est autorisé à l’effectuer. Par défaut, les droits sont distribués “en cascade” pour chaque modèle en fonction du rôle de l’utilisateur dans le salon. La modification des modèles partagés et des droits n’est autorisée qu’au propriétaire du salon ( cf. UserRoles.OWNER ).

Nous verrons prochainement qu’il est possible de créer ses propres modèles de données partagés, mais nous allons commencer par nous intéresser aux modèles “natifs” de Cocomo, ceux créés durant chaque session.

SharedManagers

Par défaut, les applications Cocomo gérent quatres “modèles de données partagés” de base, il s’agit en quelque sorte des informations minimales devant être synchronisées entre les clients pour permettre leur collaboration. Pour gérer ces modèles partagés “natifs”, un gestionnaire de session dispose de quatre classes “SharedManagers“, chargées de se synchroniser avec les données “stockées” sur le serveur :

• l’état du salon : RoomManager
• les utilisateurs connectés : UserManager
• les flux audio/video échangés : StreamManager
• les fichiers partagés dans le salon : FileManager

À l’ouverture d’une session sur un client ( connexion et identification réussie ), le gestionnaire initialise et abonne ces quatre managers. Ces managers sont alors chargés d’échanger les données nécessaires avec le salon pour maintenir la synchronisation des différents clients.

( les UserModel, FileModel… représentés dans le schéma n’existent pas “réellement” sous ces noms, mais cela permet de donner une idée du mécanisme global )

RoomManager

C’est la classe chargée de synchroniser et de gérer l’état du salon :

• nom du salon : roomName
• url du salon : roomURL
• bande passante : bandwidth
• statut du salon ( session terminée, pas commencée, en pause … ) : roomState
• rôle par défaut des nouveaux participants : autoPromote
• entrée libre : guestHaveToKnock
• …

UserManager

Cette classe est chargée de synchroniser et de gérer la liste des utilisateurs connectés, ainsi que leur rôles / droits respectifs

• liste des utilisateurs connectés et liste par rôles ( owner, publisher, viewer ou lobby cf.UserRoles)
• rôle, ID de l’utilsateur en cours

StreamManager

Cette classe est chargée de la synchronisation et de la gestion des flux en cours d’émissions. Elle vous permettra par exemple de créer, de mettre en pause ou de stopper un flux.

FileManager

Cette classe est chargée de la synchronisation et de la gestion des fichiers partagés dans le salon. Elle vous permettra par exemple d’envoyer un fichier, de suivre l’avancement de l’envoi, ou encore de lister les fichiers stockés.

SharedManagers et gestion des droits

Initialement, le rôle et les droits de chaque utilisateur découlent de son rôle au niveau du salon, mais il est à noter que chaque SharedManager permet de gérer les autorisations sur son modèle respectif ( SharedManager.setUserRole(…) ). Vous pourrez ainsi définir, par exemple, que pour le partage de fichiers, l’utilisateur B aura le droit de publication, alors qu’il ne l’aura pas pour les autres modéles

CocomoDevConsole

Le SDK de Cocomo contient une application nommée CococomDevConsole. Il s’agit d’une application AIR permettant d’observer et de gérer en temps réel l’état de ses salons, et donc de ses modèles de données partagés.

Une fois connecté et entré dans un salon, dans l’onglet “Manage”, nous avons accès à :

• A. la configuration du salon
• B. les utilisateurs connectés
• C. les flux diffusés
• D. les fichiers partagés

Cette application peut s’avérer utile, mais nous allons voir qu’il est assez simple d’incorporer ces informations dans sa propre application.

Utiliser les SharedManagers

Voici un exemple d’application qui permet de voir comment récupérer ces informations directement sur les SharedManagers.

Voilà pour aujourd’hui…
La prochaine fois nous verrons comment utiliser les sharedManagers pour créer de nouveaux composant, avant de voir finallement comment créer nos propres modèles de données partagées.

A l’année prochaine ;)…

le jeudi 8 janvier 2009

Le centre de formation REGART.NET vous invite à sa journée “Portes ouvertes Creative Suite 4“,

Vous assisterez à plusieurs ateliers et présentations par nos formateurs.

Entrée libre, sur inscription en ligne : http://regart.eventbrite.com

A cette occasion, Regart.net fêtera avec vous la sortie de la Creative suite Adobe 4 ainsi que ses nouveaux locaux.  Avec la présence des Designers interactifs et d’Adobe France.

Au programme,

16h                        : Accueil.

16h30-17h30   : “Flash CS4, nouveautés AS3″, par Thibault Imbert.
16h30-17h30   : “Flash CS4, nouveautés”, par Nicolas Gans.

17h30-18h30   : “Flex/AIR et les méthodes agiles”, par David Deraedt.

17h30-18h00   : “Dreamweaver CS4, nouveautés”, par Bertrand Gac.

18h00-18h30   : “Dreamweaver CS4, nouveautés”, par Bertrand Gac.

18h30-19h30   : “AIR & Adobe Stratus”, par Vincent Maitray.

19h00-20h00   : “Flash CS4, nouveautés AS3″, par Thibault Imbert et Nicolas Gans.

19h30-20h15     : Présentation des Designers interactifs.
19h30-20h15     : Contribution et Flashxpress.

20h                         : Pot d’au revoir et tirage au sort.

Un tirage au sort aura lieu en fin de journée, l’un des participants gagnera une Creative suite 4 Web Premium !

Entrée libre, sur inscription en ligne

Le nombre de places étant limité, merci de vous désinscrire en cas de désistement, une liste d’attente étant mise en place

Pour commencer :

• créer un nouveau Flex
• copiez le fichier SWC de cocomo ( CocomoSDK_0.9/lib/player 9 ou 10/cocomo.swc ) dans le dossier /libs de votre projet.

Hello Cocomo

L’un des principaux composants d’une application Cocomo est le gestionnaire de session. C’est lui qui sera chargé de la communication avec les serveurs Cocomo, 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 ).

Commençons avec le ConnectSessionContainer :

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.

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, aucuns 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 :

<?xml version="1.0" encoding="utf-8" ?>
<mx:Application layout="absolute"
 xmlns:mx="http://www.adobe.com/2006/mxml"
 xmlns:rtc="CocomoNameSpace"
 >
<rtc:ConnectSessionContainer id="sessionManager" width="500" height="400"
 roomURL="http://connectnow.acrobat.com/votreCompte/nomSalon" 
 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="CocomoNameSpace"
>
     <mx:Script>
         <![CDATA[
             import mx.controls.Alert;
             import com.adobe.rtc.events.SessionEvent;
 
             // état de la session
             private var isConnected:Boolean = false;
 
             // à chaque évenement de synchronisation de la session
             public function onSynchro( e:SessionEvent ):void
             {
                 if ( sessionManager.isSynchronized && ! isConnected )
                 {
                     Alert.show("Application connectée");
                     isSessionOpen = 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 )"
/>
<!-- composant d'identification -->
 <rtc:AdobeHSAuthenticator id="identificator"
   userName="votreLogin" password="VotreMotDePasse"
   authenticationSuccess="Alert.show('identification réussie')"
   authenticationFailure="Alert.show('erreur d' identification')"/>
</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, 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 nous permet de gérer facilement tout ces aspects.

Les serveurs Cocomo permettent plusieurs types d’identification, notamment une connexion en tant que hôte, basée sur le compte Cocomo 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="Identifiant">
         <mx:TextInput id="chp_login" />
      </mx:FormItem>
 
      <mx:FormItem label="Se connecter en tant que :" direction="horizontal" >
 
         <mx:RadioButtonGroup id="userRole" />
 
         <mx:RadioButton id="isGuest" groupName="userRole"
            label="Invité" value="{UserRoles.VIEWER}"  selected="true"
         />
         <mx:RadioButton id="isOwner" groupName="userRole"
            label="Hôte" value="{UserRoles.OWNER}"
         />
      </mx:FormItem>
 
      <mx:FormItem label="Mot de passe"  enabled="{ userRole.selectedValue == UserRoles.OWNER }">
         <mx:TextInput id="chp_password" displayAsPassword="true"  />
      </mx:FormItem>
 
      <mx:FormItem >
         <mx:Button label="Entrer"
            click="login(chp_login.text , userRole.selectedValue == UserRoles.OWNER ? chp_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 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;
   // si le mot de passe est renseigné : connexion en tant que hôte ,
   // sinon connexion en tant    qu'invité
   identificator.password = password ;
   // lance la connexion du gestionnaire de session
   sessionManager.login();
}

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

// deconnexion
// il semble qu'avec cette version (0.9), la plupart des pods, une fois déconnectés, ne peuvent être reconnectés.
private function logout():void
{
    sessionManager.logout();
 
    // close() est censé provoquer une déconnexion et la suppression de tous les noeuds enfants, mais ne semble pas encore marcher...
    //sessionManager.close();
}

<mx:VBox width="50%" height="100%" horizontalAlign="center" right="0">
    <mx:Button label="Déconnexion" 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é :

// à chaque évenement de synchronisation de la session
// connexion, deconnexion, changement d'état de salon, ...
private function onSynchro( e:SessionEvent ):void
{
    // une fois que l'application parvient à se connecter / synchroniser
 
    if ( sessionManager.isSynchronized && !isConnected )
    {
        Alert.show("Application connectée");
 
        isConnected = true ;
 
        removeChild( logPanel );
 
    } else if ( ! sessionManager.isSynchronized && isConnected ){
    // si la connexion est perdue
    isConnected = false ;
 
   /* supprime le container de session
   *  » il semble que dans cette version certains pods une fois déconnectés n'arrivent pas à se reconnecter.
   *
   *  » Pour se reconnecter, il faudra donc :
   *     - soit forcer le rechargement de la page
   *     - recréer dynamiquement le gestionnaire de sessionet ses pods
   */
   removeChild( sessionManager );
 
   // affichage d'un message de sortie de salon
   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, 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, et plus globalement à l’architecture du service. Nous utiliserons également la CocomoDevConsole et le LocalConnectionServer, les deux outils AIR proposés dans le SDK.

D’ici là bonne collaboration !!!

Cocomo est l’abréviation de “COmmon COllaboration MOdel“, c’est le nom donné par Adobe à son nouveau service en ligne dédié à la création d’applications collaboratives.

Cette appellation fait référence à la fois à:

• un kit de développement incluant une librairie de composants Flex et des outils destinés à la création d’applications multi-utilisateurs. Pour info, ces composants sont en partie ceux utilisés par Adobe pour développer ConnectNow, l’application de visio-conférence intégrée à la plateforme Acrobat.com.
• un service en ligne gratuit ( dans certaines limites ), permettant la création et le déploiement d’applications collaboratives basées sur des serveurs FMS hébergés et maintenus par Adobe.

En gros, Cocomo va nous permettre de créer des applications utilisant les fonctionnalités de communication en temps-réel de serveurs FMS, sans avoir à nous occuper de ces-dits serveurs… coooool !!!

Mais c’est quoi donc les “fonctionnalités de communication en temps-réels de ces serveurs FMS” ???

En fait, les serveurs Cocomo vont principalement nous permettre :

• d’échanger des flux audio et vidéo, cela nous permettra de développer des applications de visioconférence par exemple,
• de synchroniser différents types de données entre plusieurs applications clientes, ce qui nous permettra par exemple de rajouter un tchat à une application existante ou de développer un système de co-navigation, de co-édition de documents ou encore des jeux multi-utilisateurs…
• de partager des fichiers
• de gérer les droits des différents utilisateurs en fonction de leur rôle

La librairie contient des composants graphiques de “haut niveau”, les pods, mais également des classes de plus bas niveaux permettant le développement de ses propres composants ( SharedModel, CollectionNode ).

Les pods sont des composants collaboratifs “plug’n'play“, qui nous permettront de créer nos premières  applications sans, quasiment, avoir besoin d’écrire la moindre ligne de code ( Tchat, Webcam, Notes … ). Les classes de plus bas niveaux permettront ensuite de développer des composants plus adaptés à nos besoins.

Mais commençons par le début : un compte ‘Cocomo Developper‘…

Création d’un compte Cocomo Developper

Pour créer un compte  :

• Rendez vous sur le portail Cocomo ( https://cocomo.acrobat.com ),
• créez un nouveau compte ( vous pouvez aussi utiliser un compte Adobe existant )
• Choisissez un identifiant de compte Cocomo ( “account name”, il sera utilisé comme base de l’URL d’accès aux salons )

• Une fois le compte créé, notez l’URL de votre compte ( “account URL” ).
• Dans le panel “Room Instances“, créez un nouveau salon ( “room” ).

Un salon représente une sorte de “point de rencontre virtuel”, à travers lequel plusieurs applications clientes pourront échanger des flux audio/vidéos, des fichiers ou des messages. Votre compte vous permettra de créer plusieurs salons, et chaque salon pourra avoir ses propres paramétrages. Chaque salon est identifié par une URL du type : http://connectnow.acrobat.com/votreCompte/nomSalon

• Une fois le salon créé, télécharger le SDK.

Installation de Cocomo

Pour cette version 0.9, l’installation va se réduire à l’ajout de la documentation de la librairie dans l’aide d’Eclipse. Pour cela :

• Créez un dossier ‘com.adobe.cocomo‘ dans le dossier ‘plugins‘ de votre installation de Flex Builder
  Windows: C:\Program Files\Adobe\Flex Builder 3\plugins\com.adobe.cocomo
  Macintosh: /Applications/Adobe Flex Builder 3/plugins/com.adobe.cocomo
• Copiez le contenu de l’archive téléchargée à l’intérieur du nouveau dossier
• ( Re ) Démarrez Flex Builder et ouvrez l’aide ( Help / Help Contents ).

And nooow …let’s collaborate !!!

» La suite : Ma première application Cocomo

Trop la fête ! C’est parti !

Venez jouer avec nous, du mercredi 17 au lundi 05 janvier, avec 6 petits jeux à croquer pour peut-être gagner un des nombreux lots de Noël !

Pour cela guettez les posts de Maman Noël sur les forums !

Les lots :

- Des jeux Xbox (Age of Empires 3 et Shadow Run) et des webcams offertes par Microsoft ! Wow wow wow !
- Une suite Web Premium, offerte par Adobe d’une valeur de 2 270 € ! Outcha !
- Une suite Microsoft Expression Studio, offerte par Microsoft, d’une valeur de plus de 699 €.
- Une formation “Illustrator” ou “PHP mySQL” chez Regart.net (Adobe authorized Training Center), d’une valeur de 1650 €. HT.
- Une licence Flash Pro CS4, offerte par Adobe d’une valeur de 836 €.
- Une licence Microsoft Expression Web 2 offertes par Microsoft, d’une valeur totale de 299 $.

Enjoy

Les cours courts de Flashxpress

Si la webtv ne s’ouvre pas automatiquement sur la vidéo, cliquez ici

Voici la 1ère série des “Cours courts de Flashxpress”, avec le premier numéro “Cours courts Silverlight” !

L’objectif est double : vous apprendrez à gérer le redimensionnement d’un site Silverlight à 100% puis à accéder au mode plein écran.

Pensez à mettre à jour votre lecteur Flash 10 pour voir convenablement les vidéos sur la nouvelle webtv de Flashxpress.

A cette occasion je vous renvoie au blog Jean-Noël Lafargue, artiste et enseignant qui vient de mettre en ligne plusieurs cours d’initiation à Processing.

Autre source d’informations et cours en ligne par Douglas Edric Stanley sur le site de l’école des Beaux-Arts d’Aix : http://www.ecole-art-aix.fr/rubrique81.html

Et bien sur le site de Processing, avec beaucoup de ressources, cours et une communauté très active.

Et pour voir les travaux d’un maître du processing, allez jeter un oeil sur le site flight404 de Robert Hodgin, ex-flasheur converti à la puissance de cet outil.

PS : à l’heure où j’écris, il semblerait que cette version 1.0 présente des petits problèmes.

PS2 : la version 1.01 régle les problèmes. Merci à Gino pour l’info

Flash Catalyst, Gumbo, Alchemy, Durango, Pixel Bender, Cocomo, Stratus, Genesis… Si ces noms ne vous disent rien, je vous conseille de lire l’article suivant chez silicon.fr afin d’en savoir plus sur ce que nous réserve la firme de San Jose pour les prochains mois.
A suivre très bientôt sur fxp à l’occasion du MAX à Milan.

Le modèle événementiel a beaucoup évolué entre l’ActionScript 1 et 3 voici plusieurs exemples de code dans ces différents langages, nous expliquerons par la suite quels sont les différences, les principes et pour finir juste pour notre culture G, je parlerai un peu du modèle événementiel en C# 3.

1. AS1 & AS2 :

1. Au tout départ de Flash en 1978 donc… à l’époque de “Born to be Alive(Patrick Hernandez)”
   
   
   

   , on écrivait des événements dit statiques, c’est à dire qu’on déposait le code suivant sur des occurences(exemplaires) boutons :

   on(release)
   {
    trace("waaaaa ça fonctionne");
   }

   Puis avec l’arrivée de Flash MX, nous avons eu l’immense joie d’accueillir les événements dynamiques qui ont apporté avec eux la notion de modèle événementiel. Le code dans ce cas est positionné directement sur la première image de la scène. Les évènements dynamiques permettent donc :

• -à tout moment de modifier la façon dont réagit un objet à un évènement.

• -de contrôler le comportement de n’importe quel objet depuis le scénario principal, sans avoir à éditer ces objets ou à vous plonger dans une arborescence complexe. Tout le code peut donc se retrouver au même endroit, ce qui facilite grandement le déboguage, la maintenance, la mise-à-jour et le travail en équipe.

Pour faire réagir un objet à un évènement, il faudra définir une fonction dite “anonyme” à exécuter quand l’évènement en question sera diffusé, et affecter cette fonction à un gestionnaire d’évènement.

// le gestionnaire d'événement <strong>onMouseDown </strong>de <strong>monClip </strong>
// qui signifie "Souris Appuyée".
// est affecté (avec l'opérateur "=") d'une fonction anonyme
// on définit, entre les accolades de la fonction, les instructions
monClip.onMouseDown = function()
{
trace ("souris enfoncée!");
}

En ActionScript 1 et 2, nous n’avons pas réellement à faire  à un modèle événementiel car l’idée était à la base de simplifier le code pour les non-développeurs.

Mise en Application

Maintenant que nous venons de voir les bases, puisqu’un exemple s’avère toujours plus efficace que 10 pages de théorie, je vous propose d’étudier la réalisation d’une mini-application de dessin, qui illustre très bien cette notion d’évènements dynamiques.

Que se passe-t’il dans cette application en termes d’évènements?

Quand la souris est appuyée -> Quand elle se déplace -> on dessine.
Quand la souris est relâchée -> Quand elle se déplace -> on ne fait rien.

Autrement dit, quand on relâche le bouton de la souris, il faut arrêter de dessiner, c’est-à-dire annuler l’action qui a lieu sur le déplacement de la souris.
On a bien une notion d’évènement dynamique, puisque pour un même évènement (Souris Déplacée) on va avoir 2 comportements bien différents (dessiner ou ne rien faire).

Comment cela se traduit en ActionScript 1 ou 2

// 1. Mise en place
// Création d'un clip "toile_mc" sur la scène
 
this.createEmptyMovieClip("toile_mc",1);
// 2. Événements de la scène:
// ------------------------
// Quand on appuie sur la souris, il faut:
// * déplacer la mine du crayon virtuel sur toile_mc là où se trouve la souris (moveTo())
// * définir le style du trait (épaisseur,couleur,alpha) (lineStyle())
// * définir une fonction pour dessiner quand on déplace la souris (onMouseMove    = fonction) 
 
this.onMouseDown = function()
{
//on déplace la mine du crayon virtuel
toile_mc.moveTo(this._xmouse,this._ymouse);
//on demande tracer une ligne vers les nouvelles coordonées
toile_mc.lineStyle(5,0xFF3333,100);
 
this.onMouseMove = function()
{
toile_mc.lineTo(this._xmouse,this._ymouse);
updateAfterEvent();
//la fonction globale updateAfterEvent() permet de raffraichir le visuel
//sans tenir compte de la cadence, util uniquement pour setInterval et onMouseMove
}
}
 
// Quand on relâche la souris, il faut:
// annuler la fonction anonyme qui s'exécutait quand la souris était déplacée:
this.onMouseUp = function()
{
//this.onMouseMove = null;
//une meilleure écriture serait la suivante avec le mot clef delete
delete this.onMouseMove;
}

2. Principe du modèle événementiel AS3, javascript ou C#

Un nouveau modèle événementiel voit le jour en AS3, cependant ce modèle existait depuis longtemps en javascript, c# ou dans d’autres langages, Flash n’invente rien mais adapte les modèles existants à un contexte orienté visuel ce qui n’est pas plus mal.

Dans un modèle évenementiel évolué il existe 3 composants :

-le diffuseur de l’événement
-l’écouteur de l’événement
-l’événement lui-même

Voici un exemple de la vie courante qui illustre ce modèle :

* Vous décidez de prendre un abonnement à un site Web d’annonces immobilières, le fait de vous abonner fait de vous un écouteur.

* En effet, à chaque nouvelle annonce, vous recevrez un email d’information concernant le bien immobilier. Vous écoutez le site Web qui agit en tant que diffuseur de l’évènement « nouvelle annonce mise en ligne ».

* A chaque nouvelle annonce reçue vous décidez ou non de visiter le bien. Ce qui correspond bien à une action en retour.

* Souvent oubliée cette phase est pourtant très importante : lorsque vous avez trouvé le bien le plus approprié vous décidez d’arrêter la souscription à ce site, dès lors vous ne recevrez plus d’email. Autrement dit vous supprimez l’écouteur
Le grand avantage de ce modèle est que nous pouvons souscrire plusieurs écouteurs, en effet dans la vie de tous les jours des millions d’événements “nouvelle annonce immobilière” sont diffusés par des milliers d’agences et ces événements sont écoutés par des millions de particuliers. Chaque particulier peut réagir différemment lorsqu’une annonce est diffusée.

3. L’écriture en AS3

Dès lors voici comment s’écrit l’écoute du clique d’un bouton:

diffuseur.addEventListener("evenement", ecouteur);
monBouton.addEventListener ( "click", clicBouton );
function clicBouton ( pEvt:MouseEvent ):void
{
// affiche : événement diffusé
trace("événement diffusé");
};

Cependant la chaine de caractère “click” n’est pas très ergonomique pour un développeur, car il faudra retenir la casse de l’événement par coeur, nous utiliserons plutôt la classe MouseEvent qui stocke des propriétés statiques. Grâce à L’IntelliSense, plus besoin de se souvenir par coeur des noms des événements :

diffuseur.addEventListener("evenement", ecouteur);
monBouton.addEventListener ( MouseEvent.CLICK, clicBouton );
function clicBouton ( pEvt:MouseEvent ):void
{
// affiche : événement diffusé
trace("événement diffusé");
}
;

4. L’écriture en C#

je ne m’étendrai pas, mais sachez qu’en C# on récupère une référence faible du diffuseur via le sender, et que les propriétés propres à l’événement sont contenues sans RoutedEventArgs. Pour récupérer le container d’un objet diffuseur, il faudra cibler la propriété OriginalSource de l’objet événement reçu. Pour finir,  il suffit juste d’admirer la plus belle écriture qui soit, pour les amateurs, créer des événements personnalisés en c# est tellement simple que l’AS3 passe pour du lingo :

bouton1.Click += clicBouton;
//ou encore
bouton2.Click += new RoutedEventArgs(clicBouton); 
 
void clicBouton ( object sender, RoutedEventArgs e)
{
// affiche : événement diffusé
System.Diagnostics.Debug.WriteLine("nom du diffuseur :: {0}",(sender as Button).name);
};

Pour finir, je vous conseille vivement la lecture des chapitres liés au modèle événementiel du livre de Thibault Imbert que vous trouverez ici.

Ce partage d’expérience permettra aux professionnels qui souhaitent développer un site ou un blog de comprendre les fondamentaux pour la gestion d’un thème. Nicolas et Guillaume montreront les coulisses techniques de la refonte de 2 sites développés sous WordPress : designersinteractifs.org et flashxpress.net.

Agenda : le jeudi 27 novembre 2008
Lieu : Café Dune, Paris 10e
Durée : de 20h à 22h
Gratuit

Le workshop s’articulera en 2 parties :

• présentation des 2 approches de développement (d’un template acheté VS partir de zéro)
• description du contexte et justification des choix techniques
• présentation des grandes phases de conception et de développement.

• focus sur des points de développement précis
• séance de questions/réponses

Inscription sur le site des designers interactifs

Edit 28 nov. 2008 : voici les slides du workshop en SlideShare (ci-dessous) et en pdf ici