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

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

• Cocomo est là et personne me prévient ??!!
• Cocomo ? Kezako ?
• Introducing r.CØ … First « Cocomo ready » Air Wiibot…
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs

Notre premier prototype de robot Lego Mindstorms contrôlé par une wiimote à travers le web grâce au service Cocomo d’Adobe …

Réalisé à l’aide de Lejos , Merapi, Air, Wiiflash, Cocomo.Autres articles sur le même sujet

• Cocomo est là et personne me prévient ??!!
• Developing with AFCS a.k.a Cocomo – Introduction
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs
• FITC#09 : TwiiDee, WiiFlash and Rock ‘n’ Roll

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

« MAX is an experience unlike any other ». Cela résume bien ce qu’est MAX : une expérience ! Riche en rencontres, riche en partages…

Riche en partages, avec la démo de Twiidee que nous avons eu la chance de faire devant les membres d’Adobe, et qui a fait son « petit effet » : Ryan Stewart, Ben Forta, Michelle Turner, … Cà fait plaisir !

Ryan Stewart a posté aujourd’hui la vidéo de l’interview « live », pris sur le vif, avec une explication complète de l’application. Bon on ne dit rien concernant mon magnifique anglais . Bientôt le site dédié a cette application ouvrira ces portes : patience donc !

Riche en rencontres ! Car MAX c’est finalement çà : partager une passion commune. On pourrait ce dire que 1500 geeks ensemble ça doit faire mal, mais finalement c’est plutôt rigolo ! On parle Anglais beaucoup, russe un peu avec les gars de Alternativa et Flexis. Français très peu… et l’alcool aidant c’est un franglorusse général qui s’impose !

Riche en goodies aussi… là Adobe ne fait pas les choses à moitié. On retiendra le théorie darwinienne selon Adobe : Flash = singe, Flex = Robot… L’être humain ça doit être FlashCatalyst…

Remerciement spécial pour Thomas , Didier, Philippe, Pierrick, Gaëlle et la team KaptIT avec qui nous avons passé de bons moments !

Vous l’aurez compris : nous avons adoré ! Vivement le cru 2009 !

Autres articles sur le même sujet

• Balance ta souris on va wiigoler…
• Buzz à Max…
• Live from MAX Milan : hands on thermo…
• MAX 09 – Où est passé le Text Layout Framework ?

Bon souvenons nous, il y a quelques semaines, au cours d’une impressionnante offensive ( cf. la journée de la béta ), Adobe annonçait une vague de produits à venir, parmi lesquels Thermo, le futur Flash Player 10 , Air Beta 2 , flashlite 3 , Adobe Media Player, etc, etc…

Cela fait longtemps que je voulais revenir sur ces ‘et cætera’ justement, notamment sur 2 technos dont on a bien moins parlé : Cocomo et Pacifica

Derrière ces noms exotiques se cachent deux projets d’un type encore un peu nouveau pour Adobe : les services hébergés. Après Share, dont l’offre se situe presque au même niveau que n’importe quel service de stockage en ligne, mais en un peu plus « Rich », voilà le lancement en béta de Cocomo, destiné pour sa part au travail collaboratif.

En gros Cocomo est une bibliothèque Flex / AS3 regroupant la quasi totalité des composants de Adobe Connect.

Pour les quelques privilégiés qui ont pu tester Adobe Connect ( Breeze ), ils comprendront tout de suite la « folie du truc »: – salon de chat – tableau blanc – salle de visio – gestion de droits – partage de documents … etc etc

En gros deux trois balises MXML et on a son chat, une ligne de plus et ca devient une appli de visioconférence :p.

Si cela s’arrêtait là çà serait déjà « bien »… Vue la baisse de prix draconienne de FMS3, çà permet d’envisager des développements de « Rich Collaborative Web Applications » rapides et peu coûteuses. Bien vu Adobe !!!

Mais ils vont encore plus loin… les temps l’obligent ! Adobe va en plus donner accès à ses serveurs gratuitement. Vous pourrez créer des applications collaboratives en quelques lignes, sans même avoir besoin de votre propre serveur, tout passera par les serveurs d’Adobe, une sorte de « service/serveur hébergé gratuit ». Il y aura sûrement des limites en terme de débit, mais il sera possible ( je pense ) d’héberger une solution sur ses propres serveurs.

Vous trouverez des exemples sur le blog du projet.

Je vous conseille la présentation compléte dispo via Adobe Connect.

Reste plus qu’à recevoir l’invitation …

Sinon j’ai pas trop creusé sur Pacifica pour le moment, mais apparament en plus de la voIP, cela permettra également le P2P, et d’autres trucs. cf le blog du projet

Autres articles sur le même sujet

• Cocomo ? Kezako ?
• Introducing r.CØ … First « Cocomo ready » Air Wiibot…
• Developing with AFCS a.k.a Cocomo – Introduction
• Hello AFCS ( bye Cocomo ) : première application multi-utilisateurs