Que vous soyez acteurs dans les nouvelles technologies ou simplement curieux de voir ce que le présent nous réserve, vous êtes conviés à venir participer au 1er BarCamp dédié aux Interfaces Riches, le 23 juin 2010 à partir de 17h, au cyberCafé du campus de la Doua à Villeurbanne.

Au programme : des conférences, des ateliers et des démonstrations de ces technologies naissantes ou déjà matures et de leurs usages dans différents domaines (commerce, enseignement, divertissement…). Aux côtés des principaux innovateurs de ce secteur, vous pourrez même, si vous le souhaitez, proposer votre propre présentation dans les tribunes libres prévues à cet effet.

Quelques présentations au menu :

• Nouvelles expériences utilisateurs multi-canal grâce aux RIA (ipTv, bornes interactives);
• OpenScales: client cartographique basé sur les technologies ActionScript3 / Flex / AIR;
• Comment développer une RIA moderne en Javascript avec RESTHub.

Rendez vous, donc, le 23 juin 2010 pour une rencontre conviviale qui vous donnera l’occasion de découvrir ou de montrer dès aujourd’hui, les interfaces de demain.

• « Flash In The Can » : hymne a l’AS3
• Virtual Cabinet, flash et interfaces riches pour l’apprentissage des langues (3)
• Interfaces tangibles : le futur du multitouch
• Barcamp Lyon : Mix-IT, Flex, Java, PHP, JS, Cloud… (et chips)

Alors le multitouch remplaçant de nos bons vieux claviers / souris ? Pas si sûr ! Pour certains acteurs cela ne fait pas de doute. Pour d’autres en revanche, ces interfaces ne sont que des périphériques supplémentaires, un moyen différent de « consommer ».

Imaginez manipuler un fichier Excel en multitouch… Ça risque d’être assez pénible ! Pour peu que l’on soit un accro des macros ! (bon moi je m’en fou je fais pas d’Excel). Et puis pour l’instant ça fait mal aux doigts ! A force de gesticuler autour de sa table 50 pouces, on prend des crampes…

D’accord mais c’est bien le multitouch ! LA solution ? Les pseudo claviers / souris comme périphériques physiques de la table. Imaginez un clavier souple ou une souris transparente en plexiglas : pas d’électronique dedans, et tout de même repérés par la table. Un peu comme les tables tangibles, reconnaissant des périphériques électroniques (appareils photos…), ou des périphériques de soirée (un verre…) ou n’importe quoi qui possède un tag RFID. RFID ou bien par une forme particulière : on peut imaginer des objets de formes différentes, qu’une analyse d’image peu détecter.

slap widgets demo

Plusieurs groupes travaillent sur ce type d’interfaces tangibles : le MIT avec le groupe Tangible Media Group, le Media Computing Group, un groupement de recherche des universités allemandes, avec le projet SLAP : Silicone Illuminated Active Peripherals.

Et ce n’est qu’un début ! Le monde de la musique dispose déjà d’interfaces tangibles.

[update] Do you want more ?
Pattie Maes, du Fluid Interface Group – MIT, à présenter en février dernier leur dernier jouet : « the SixthSense » : Minority Report en vrai. Pourquoi avoir un périphérique alors que ses doigts c’est si bien ?!

Ils sont aussi à l’origine du projet fou Siftables

Je vous invite vivement à découvrir l’ensemble des projets de ce groupe : il y a là de quoi rêver sur l’avenir des interfaces !
[/update]

Et là oui ! J’imagine mieux Excel en multitouch !
A suivre de près donc… A quand un docteur maboul virtuel tangible ?
Et vous, des idées ?Autres articles sur le même sujet

• Un curseur… des curseurs ???
• MAX 09 – Le multitouch
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher
• BarCamp interfaces riches, Lyon, 23/06

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

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