Voilà quelques temps que nous nous activions sans donner de nouvelles…, il est temps de corriger tout ça.
Aussi, pour démarrer cette nouvelle année du bon pied, La Fabrick vous propose une petite application de génération de code AS3 à partir d’un schéma XSD.

Ce petit outil nous a été utile pour pas mal de projets développés pour nos premiers clients, alors pourquoi ne pas vous en faire profiter ? Peut-être deviendrez-vous aussi MdaME-addict ?

Retrouvez toutes les infos sur http://mdame.lafabrick.comAutres articles sur le même sujet

• API de dessin en AS3
• Crée ton navigateur perso avec 5 lignes de code !
• Flex Builder 3 et le PHP ( PDT ) : installation
• Skiner un composant Flex 3 avec Fireworks CS3 [Tutoriel Vidéo]

Pour ceux qui utilisent l’API de logging de Flex, au sein d’une application AIR ont certainement remarque qu’il manquait cruellement une Target « fichier » pour tracer dans un fichier texte (même si le résultat de la fonction trace se retrouve enfoui quelque part dans les tréfonds du répertoire de données du Flash Player).

Pour ceux qui se sont posés cette question, vous êtes sans doute tombés (Ô joie) sur la FileTarget de notre ami Mike Chambers dans l’AS3 core lib.

Pour ceux qui se sont demandé s’il y avait un équivalent du RollingFileAppender de log4j en Flex (j’espère qu’il en reste, sinon restez, c’est bien quand même !), eh bien vous êtes certainement tombés sur l’ensemble vide.

N’y tenant plus, j’ai craqué sur une extension de la FileTarget pour créer le RollingFileTarget. Vous en voulez ?

Un rapide point sur l’API de logging

Et pourquoi pas un bon vieux trace("qui tâche") ?
Simplement parce que trace() trace tout, tout le temps, sans indication complémentaire sur le moment, ou la criticité de l’événement tracé. En clair, c’est très pratique pour en phase de test simple, lab ou autre, mais devient très vite inapproprié dès qu’on entre dans un développement structuré.

Comment faire de jolies traces bien propres Aïe

C’est très simple (cf. doc Flex) :

La target

/* Create a target. */
var logTarget:TraceTarget = new TraceTarget();

/* Log only messages for the classes in the mx.rpc.* and
mx.messaging packages. */
logTarget.filters=["mx.rpc.*","mx.messaging.*"];

/* Log all log levels. */
logTarget.level = LogEventLevel.ALL;

/* Add date, time, category, and log level to the output. */
logTarget.includeDate = true;
logTarget.includeTime = true;
logTarget.includeCategory = true;
logTarget.includeLevel = true;

/* Begin logging. */
Log.addTarget(logTarget);

Vous noterez l’usage de la TraceTarget qui va indiquer d’envoyer les traces vers la console et donc faire comme la fonction trace().
La target permet d’aller un peu plus loin en indiquant notamment :

• le niveau de log : toute trace d’une criticité inférieure au niveau défini sera donc ignorée
• des filtres sur les catégories de log : ces filtres vont permettre de n’envoyer sur la cible que les traces correspondantes

Le logger

Nous avons donc une cible, maintenant il faut tracer ! Pour cela, il suffit de créer un logger :

private static var _logger:ILogger = Log.getLogger("com.lafabrick.classes.UneClasse");

Il est en général recommandé de créer un logger par classe de façon statique pour limiter le nombre d’instances en mémoire.
Vous pouvez noter l’utilisation de la notation sous forme de packages permettant de faire le lien avec les filtres définis au niveau d’une target.
Pour utiliser le _logger, vous pouvez appeler les méthodes suivantes :

_logger.debug("Trace niveau debug");
_logger.info("Trace niveau info");
_logger.warn("Trace niveau warning");
_logger.error("Trace niveau error");
_logger.fatal("Trace niveau fatal");

Les appels provoqueront l’ajout de votre trace à tout target définie correspondant au paramétrage de votre logger (catégorie et niveau).

Faire sa target personnalisée

Il ne reste plus qu’à écrire une target personnalisée qui va écrire dans un fichier au lieu d’écrire dans la console.

Vous pouvez pour cela étendre la classe AbstractTarget ou LineFormattedTarget (cette dernière prendra en charge la mise en forme du message pour vous, donc bien pratique).

C’est ce qu’a fait Mike avec sa FileTarget que je vous laisserai consulter sur Github.

La RollingFileTarget

C’est sur ce modèle que j’ai développé la RollingFileTarget dont l’objectif est de pratiquer une rotation sur un fichier de log selon deux critères :

1. La date
   Objectif : un fichier de log par jour, par mois ou par an
2. Le poids
   Objectif : la taille d’un fichier de log ne doit pas excéder N octets

Utilisation

Il s’agit d’une target classique, utilisable comme la TraceTarget :

var fileTarget:RollingFileTarget = new RollingFileTarget(new File("app-storage:/logs/monappli.log"));
fileTarget.filters = ["*"];
fileTarget.includeDate = true;
fileTarget.level = LogEventLevel.ERROR;
fileTarget.includeTime = true;
fileTarget.includeCategory = true;
fileTarget.includeLevel = true;
fileTarget.rollingInterval = RollingFileTarget.DAY_INTERVAL; // Un fichier de log par jour
fileTarget.maxLogFileWeight = 0; // Pas de limite de taille de fichier
fileTarget.maxLogBackups = 7; // Une semaine de roulement sur les fichiers de log
Log.addTarget(fileTarget);

A noter les trois propriétés suivantes :

• rollingInterval : le mode de roulement par date. Vous avez le choix entre RollingFileTarget.DAY_INTERVAL, RollingFileTarget.MONTH_INTERVAL, RollingFileTarget.YEAR_INTERVAL, RollingFileTarget.NO_INTERVAL
  Je ne traduis pas, j’imagine que vous comprenez
• maxLogFileWeight : la taille maximale d’un fichier de log, en octets.
  Pour limiter la taille d’un fichier de log à 5Mo par exemple, vous pouvez indiquer maxLogFileWeight = 5000000. Une valeur à zéro désactive la rotation selon la taille du fichier.
• maxLogBackups : le nombre maximum de backups à conserver.
  Le principe réside en la conservation d’un nombre suffisant de logs pour retrouver les éléments importants ayant pu se passer. En général, une semaine de log suffit pour retrouver ses petits pour une application utilisée raisonnablement.

A savoir que ce motif est utilisé par la target pour détecter les backups existants dans le répertoire de stockage de votre fichier de log principal et gérer ainsi proprement les backups entre deux lancements de l’application (oui, c’est rare de laisser tourner son appli pendant 2 semaines sans l’arrêter…)

Je n’ai donc pas préféré laisser le choix sur le motif de renommage pour éviter les problématiques pouvant évidemment en découler. En même temps, on a affaire à des fichiers de logs…

Note importante : ces deux politiques sont combinables mais il est plus que conseillé de choisir entre un roulement sur le poids OU un roulement selon la date pour conserver des backup dans un ordre cohérent. En effet, si vous choisissez de combiner la rotation sur la taille ET sur le poids, vous aurez maxLogBackups fichiers de log suivant le motif AAAA-MM-JJ-nom.log et maxLogBackups fichiers de log suivant le motif nom.log.X.

J’envisage à terme que lors d’une rotation par date, l »ensemble des fichiers de backup par taille existants soient préfixés de la date du jour pour grouper correctement l’ensemble.

Téléchargement

Vous pouvez gracieusement télécharger, utiliser, modifier cette classe comme bon vous semble, La Fabrick déclinant toute responsabilité sur un quelconque dommage, problème ou perte d’information liée à son utilisation, de manière directe ou indirecte. Veillez également à respecter le copyright indiqué en entête du fichier, merci !

A noter bien entendu que cette classe utilise l’API d’accès au système de fichiers de AIR et ne peut donc être utilisée qu’au sein d’application compilées avec ce runtime.

Bons logs…Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5

Fonctionnement et limites d’un NativeProcess

Packaging de l’application

Pour diverses raisons de sécurité, une application AIR utilisant un NativeProcess doit être packagée dans le format de la plateforme cible (exe pour Windows, dmg pour Mac, rpm / deb / … pour Linux). Fini donc dans ce cas le pratique fichier .air qui marche partout !
Vous devez également indiquer dans le descripteur de l’application qu’il s’agit d’une application au profil « extendedDesktop » lui conférant donc les capacités d’exécuter un NativeProcess.
Vous devez ouvrir le fichier monAppli-app.xml et modifier la balise <supportedProfiles>

<supportedProfiles>extendedDesktop</supportedProfiles>

A partir de là, si vous tentez d’exporter un fichier .air, vous aurez un joli message d’erreur vous invitant à changer de profil.

Considérations de sécurité

Si AIR sans native process dispose de limitations de sécurité, dès lors que vous utilisez un native process, vous ouvrez la porte… Il est donc bon d’anticiper et de faire un maximum de vérifications sur vos appels pour éviter un remplacement d’un exécutable par un autre, moins sympathique, par exemple…

Prêt ? On code

Paramétrage

Un native process a besoin d’un contexte d’exécution. Ce contexte est défini à l’aide de l’objet NativeProcessStartupInfo décrivant notamment les éléments suivants :

• workingDirectory : le répertoire d’exécution
• executableFile : l’exécutable à lancer
• arguments : la liste des arguments à passer à l’exécutable (Vector.<String> sous Flash Player 10, ou un bête Array sinon)

Vous pourrez alors instancier un objet NativeProcess et lui passer cet objet de paramétrage avant de le lancer.

Lancement & suivi de l’exécution

Le lancement d’un NativeProcess est asynchrone. Il propose donc un certain nombre d’événements vous permettant de suivre son exécution une fois lancé, notamment :

• ProgressEvent.STANDARD_OUTPUT_DATA : écriture sur la sortie standard
• ProgressEvent.STANDARD_ERROR_DATA : écriture sur la sortie d’erreur
• IOErrorEvent.STANDARD_OUTPUT_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie standard
• IOErrorEvent.STANDARD_ERROR_IO_ERROR : déclenché lorsqu’une erreur apparaît en tentant de lire la sortie d’erreur
• NativeProcessExitEvent.EXIT : déclenché lors que l’exécution du process est terminée

Lecture de l’entrée / sortie standard

Bien que tout à fait possible, la lecture de la sortie standard ou d’erreur via le listener ProgressEvent.STANDARD_OUTPUT_DATA ou ProgressEvent.STANDARD_ERROR_DATA n’est pas fiable à 100% concernant le contenu retourné : la sortie étant « bufferisée », vous n’aurez donc pas systématiquement le même résultat selon la machine exécutant le programme, à chaque appel de votre listener… N’utilisez donc la lecture de sortie standard que pour afficher ce qui se passe, ou à la limite récupérer la totalité du contenu écrit une fois le process terminé…

Appeler un JAR

Rappels

Pour appeler un JAR en Java, il doit être exécutable (bah oui…), et appelé en ligne de commande de la manière suivante :

java -jar monJar.jar [-cp jars du classpath]

Nous sommes dans une appli AIR, donc évitons de surcharger la commande à appeler avec un classpath, aussi je vous suggère d’utiliser les fonctionnalités d’export complets d’un JAR (si les licences associées vous l’autorisent) intégrant au final l’ensemble des sources dans un groooos JAR contenant tout ce qu’il lui faut pour fonctionner.
Notes :

• Les utilisateurs de Maven peuvent utiliser le plugin qui va bien pour ça.
• L’export eclipse, c’est pas mal non plus, il suffit de cocher la « case qui va bien » au moment d’exporter

Depuis un NativeProcess

On voit mieux ce qui se dessine:

1. Définir l’exécutable java dans vos « startup infos »
2. Définir les arguments
   • -jar
   • /chemin/vers/monJar.jar
3. Ajouter les listeners permettant de savoir lorsque l’exécution est terminée
4. Lancer le native process

Restons multi plateforme

Java est multi plateforme, oui, mais l’exécutable dépend de la plateforme, aussi il vous faudra récupérer le chemin vers votre JAVA_HOME (contenant le répertoire bin avec l’exécutable Java).
Vous avez donc deux solutions maintenant:

1. La plus simple (pour le développeur) : demander à votre gentil utilisateur où est son JAVA_HOME. Ça peut le faire si c’est un geek velu qui a compris qu’on ne parlait pas de venir danser chez lui (aïe, elle est rude celle-ci)
2. La plus compliquée (mais pratique pour l’utilisateur) : utiliser un autre exécutable (voire NativeProcess) qui remonte cette information ou permette de pointer directement sur l’exécutable en question

La seconde solution bien que séduisante est un peu plus longue à implémenter.
Pour les développeurs sous Windows, j’ai noté l’utilisation par Serge Jespers d’un petit (mais pratique) exécutable « jexe.exe » lançant le java.exe présent dans le %JAVA_HOME%\bin de la machine. L’utiliser vous évitera la première solution, sans vous lancer dans un développement spécifiquement dédié à cela (merci Serge). En revanche, si votre application est diffusée à un public d’utilisateurs non avertis, ils sont tout à fait susceptibles de ne pas avoir de variable JAVA_HOME définie sur leur machine : pensez donc à déterminer précisément votre cible avant de choisir une solution.

J’ai également noté en relisant un extrait de la licence du JRE que la redistribution est autorisée sous certaines conditions. Si vous les remplissez, vous pourriez carrément embarquer le runtime java dans votre application AIR, au risque de la faire gonfler en taille…

Un exemple ! Un exemple !

Voici un petit exemple de code permettant de lancer un JAR exécutable depuis une application AIR :

package com.lafabrick.nativeprocess
{
import flash.desktop.NativeProcess;
import flash.desktop.NativeProcessStartupInfo;
import flash.events.EventDispatcher;
import flash.events.NativeProcessExitEvent;
import flash.events.ProgressEvent;
import flash.filesystem.File;
import flash.system.Capabilities;

public class JarExec
{
protected var _process:NativeProcess;

public function JarExec()
{
}

public function getDefaultJavaExecutable():File
{
if (Capabilities.os.toLowerCase().indexOf("win") > -1)
{
return File.applicationDirectory.resolvePath("native/jexe.exe");
}
if (Capabilities.os.toLowerCase().indexOf("mac") > -1)
{
// TODO: Changer avec un paramètre de configuration
return new File("/System/Library/Frameworks/JavaVM.framework/Commands/java");
}
throw new Error("Système non pris en charge");
return null;
}

public function testJava(executablePath:String = null):void
{
// Tester le lancement de l'exécutable 'java'
try
{
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.workingDirectory = File.applicationDirectory;
nativeProcessStartupInfo.executable = (executablePath == null ? getDefaultJavaExecutable() : new File(executablePath));

var args:Vector.<String> = new Vector.<String>();
args.push("-version");
nativeProcessStartupInfo.arguments = args;

_process = new NativeProcess();
_process.addEventListener(NativeProcessExitEvent.EXIT, onJavaTestExit);
_process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA, onStandardOut);
_process.addEventListener(ProgressEvent.STANDARD_ERROR_DATA, onErrorOut);
_process.start(nativeProcessStartupInfo);

trace("-- Début d'exécution");
}
catch (e:Error)
{
trace("Impossible de lancer le process\n" + e.message + "\n" + e.getStackTrace());
}
}
protected function onStandardOut(e:ProgressEvent):void
{
trace("STDOUT: " + _process.standardOutput.readUTFBytes(_process.standardOutput.bytesAvailable));
}
protected function onErrorOut(e:ProgressEvent):void
{
trace("STDERR: " + _process.standardError.readUTFBytes(_process.standardError.bytesAvailable));
}
protected function onJavaTestExit(e:NativeProcessExitEvent):void
{
trace("-- Fin d'exécution");
}
}
}

Cet extrait donne un aperçu, mais vous pouvez vous lancer (soyons fous) à installer le package suivant :

Pour Mac

Pour Windows

Pensez au clic droit > View Source…

Packager l’application

Comme je le disais au début de ce post, il est nécessaire de packager votre application dans le format natif du système d’exploitation visé. Vous avez deux solutions pour cela :

1. Passer par la dernière version de Flash Builder 4 qui propose cette fonctionnalité
2. Utiliser l’application PackageAssistantPro proposée par Serge Jespers (re merci Serge)

Il s’agit d’une application AIR utilisant des NativeProcess (et packagée en ligne de commande vu que l’application n’existait pas avant… Remarquez, la version 2 et plus ont probablement été packagées avec la version 1… Mais je m’égare)

Quelques liens

• Un petit exemple d’application utilisant un NativeProcess : ZXPackager
• ASDoc de la classe NativeProcess [EN]
• Un bon article pour démarrer [EN]

Autres articles sur le même sujet

• Un projet Java / Flex avec Maven 2
• Arduino #2 : Flash, socket et Processing
• ZXPackager : application pour l’empaquetage ZXP d’extensions CS5
• RollingFileTarget pour AIR 2.0 : let’s roll !

Cette application propose un moyen simple de packager vos extensions CS5 développées avec le nouveau SDK Creative Suite.

Les extensions ZXP

Depuis la CS5, Adobe propose un nouveau SDK de développement et un format d’extension commun a toute la suite logicielle.
Ce SDK, disponible ici, vous permet de développer vos propres panneaux et autres menus CS5. Le premier format de sortie est le MXP, toujours disponible, vous permettant d’exporter votre extension pour un logiciel cible.
Maintenant, avec la CS5, vous disposez d’un format commun, le ZXP, qui rend compatible votre extension avec toutes la suites CS.

Un fichier ZXP est défini par un manifeste xml, définissant le fonctionnement de l’extension (type, portée logiciel, …), et contient le (les) SWF de l’extension (une extension est en fait une pseudo application AIR, basée sur le SDK CS). Un fichier ZXP est signé numériquement. Vous devez donc avoir un certificat (PKCS12, PKCS11, JKS). Vous pouvez bien entendu utiliser votre certificat auto-signé préalablement créé avec Flash/Flex Buider.

Pour plus d’informations :

• Creative Suite SDK
• le blog CSSDK

Un fichier ZXP doit (habituellement) être compilé en utilisant le packager Java UCF. Et c’est là l’idée de cette petite application : ne pas avoir a redéfinir vos certificats et autres options pour chaque package, et vous proposer une interface plus « user friendly » que le terminal.

Fonctionnement

Démarrage, et préférences

Au premier démarrage, l’application doit obtenir vos préférences de base.

• Java Home

  Vous devez indiquer le chemin vers votre JDK/JRE java, si celui-ci ne correspond pas à celui par défaut (l’application intègre le packager jar UCF, et elle doit connaître le répertoire racine de Java pour pouvoir le lancer). Les chemins racines par défaut sont:

  • Pour Windows : ‘C:\Program Files\Java\jdk1.6.0′
  • Pour Mac : ‘/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0′

• Certificat

  Vous devez préciser l’emplacement de votre certificat (généralement un fichier de type .p12 ou .p11), ainsi que votre mot de passe. Ces informations sont nécessaires pour la signature de l’extension.

  • Fichier cible

    Vous devez indiquer le fichier de destination. L’extension .zxp est ajoutée automatiquement.

  • Source de l’extension

  Les sources de l’extension, comme défini dans la nomenclature du SDK CS, doivent correspondre à ce schéma:

  
  Ce répertoire est construit préalablement par la tâche ant de compilation, dans votre projet (cf. en fin d’article, le téléchargement du projet test d’extension)
  Vous devez pointer sur le répertoire « bin ».

  • Démarrer un nouveau package;
  • Ouvrir et installer l’extension via Extension Manager (vous devez bien entendu avoir préalablement installé Extension Manager CS5)
  • Projet fxp
  • Archive zip du bin de test

Définition de votre extension

Un package ZXP a besoin de 2 informations : le nom et l’emplacement de votre extension cible, et l’endroit où se trouve le répertoire « bin » de votre extension.



Une fois le packaging démarré, un message d’attente s’affiche.



Finalisation

Une fois le package créé, l’application vous propose de :



Téléchargements

ZXPackager

Extension de test

Autres articles sur le même sujet

• [Flex 3 Beta] bug : Application File doesn’t exist
• Un projet Java / Flex avec Maven 2
• AIR 2 : appeler un JAR exécutable via un NativeProcess
• RollingFileTarget pour AIR 2.0 : let’s roll !

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 !

Ah oui, au fait, juste avant de commencer : un mot sur les Awards. Nous avons eu droit à une présentation des MAX Awards par Mark Hamil juste avant la session Sneak Peeks. On ne reviens pas dessus tellement nous avons trouvé ça pauvre en information. Nous sommes certains que les projets choisis sont effectivement géniaux, mais nous n’avons vraiment pas eu l’occasion d’en voir suffisamment et d’en entendre parler leurs concepteurs pour se faire une quelconque idée de la chose.

Voici plutôt un aperçu de ces Sneak Peeks particulièrement intéressants sur les innovations en cours chez Adobe. Le principe est simple : prenez Mark Hamil (Luke Skywalker pour les intimes) comme présentateur qui ne comprend rien aux technologies montrées, déguisez les ingénieurs Adobe en chevaliers de l’empire, Chewbacca ou princesse Leïa et vous obtenez un show de geek vraiment sympa et impressionnant.

Principe

Chaque équipe passe présenter son projet et doit rivaliser d’idées innovantes pour obtenir les clameurs de la foule en folie. Ca va vite, ils font souvent des blagues et vont parfois jusqu’à scénariser la présentation. C’est vraiment excellent ! Les infos passent très bien, on ne s’ennuie pas… Voyons voir.

Mobile

L’équipe mobile nous a présenté un jeu multi-joueurs utilisable depuis différents terminaux mobiles (Palm, Google Android, Nokia…), une application AIR sur portable et en mode web sur PC. Le principe technique est que ce jeu s’exécute côté serveur et que les images du jeu sont envoyées en streaming sur les terminaux (un peu comme une vidéo YouTube). Chaque commande est également envoyée au serveur pour lui permettre de calculer le comportement attendu pour le joueur.

Même si la technicité est certainement élevée et innovante, la pauvre bande passante du Wi-Fi disponible a montré les lacunes de l’outil. L’intérêt reste à notre sens assez limité, bien que nous ne soyons pas des spécialistes du jeu en ligne. On salue quand même la performance (faut le faire non ?)

Flash

La démo Flash est assurée par Chewbacca en personne. Il nous montre comment la future version de Flash Professionnel permettra de générer des animations de formes à l’aide d’un moteur physique pour leur donner un aspect particulièrement réaliste. L’exemple ci-après est réalisé à partir de dessins de formes vectoriel et d’activation de quelques cases à cocher…

On vous laisse imaginer les possibilités offertes au designer pour réaliser des animations réalistes et relativement complexes en quelques clics, c’est vraiment intéressant pour le monde de la création.

Flex pour mobile

Cette fois, c’est princesse Leia qui procède à la présentation d’un développement en environnement Flex avec le framework mobile. Concrètement, il/elle utilise des composants liste et champ de recherche, compile et lance une application ressemblant plus que fortement à une application iPhone de recherche et affichage d’informations.

Le résultat, affiché sur un iPhone (forcément…), est particulièrement réussi, très réactif. C’est impressionnant, en tant que développeurs Flex de voir la simplicité du développement Flex apportée sur un environnement de ce type !

Photoshop

On ne sait plus à quoi s’attendre sur Photoshop. Le logiciel vit depuis un certain temps, et pourtant cette présentation nous a laissé sur le c… pardon, pantois.

Concrètement, l’équipe a travaillé sur une fonctionnalité de gommage intelligent (mathpatch), interprétant la globalité de l’image pour remplacer le contenu supprimé par un contenu particulièrement réaliste. Le résultat est absolument hallucinant. Vous pouvez supprimer le fameux fil électrique qui rature le beau bâtiment à présent.

Ce fonctionnement a carrément été appliqué à des parties d’images : la démonstration montre le conférencier supprimer une usine de la vue de la photos. 20% de l’image est recomposée automatiquement. On constate déjà un peu plus l’intervention de la machine, mais en faisant attention. Bluffant !

Fireworks

L’équipe Fireworks a présenté une fonctionnalité de retour arrière sur ses actions de manière ciblée. Concrètement, vous travaillez sur une partie de votre image, puis une seconde et ne voulez annuler que les changements effectués sur la première partie, mais pas sur la seconde, vous pouvez sélectionner ladite première partie et annuler uniquement ces changements : particulièrement pratique pour les designers habitués à ce genre d’outils !

Dreamweaver

Nous n’avons pas particulièrement l’utilisation de Dreamweaver habituellement, mais on retient cette démonstration, particulièrement intéressante pour l’utilisation de la nouvelle norme HTML 5.

En l’occurrence, une nouvelle spécification est sortie (HTML 5) intégrant notamment un notion de Canvas, des interactions et animations pouvant être définies pour ce canvas. Adobe montre une forte volonté de tirer partie de cette nouvelle solution en permettant un copier coller depuis Flash dans Dreamweaver d’une animation Flash, Dreamweaver la transformant en animation native Canvas.

L’intérêt ? Pas de Flash Player, des performances excellentes, et une adéquation parfaite aux standards. Une excellente initiative pour tenter de se rapprocher du standard plutôt que chercher à l’évincer.

AIR : Rome

Attention, énorme application. Le conférencier nous présente un outil à l’ergonomie particulièrement réfléchie et léchée regroupant en quelque sorte le principale de chaque outil d’Adobe. Vous pouvez dessiner en vectoriel (Illustrator / Fireworks), ajouter des animations (Flash), importer des calques Photoshop, ajouter des écrans et créer une interaction type navigation entre écrans (Flash Catalyst).

Enfin, vous pouvez exporter votre travail en SWF, AIR, SVG, image, page HTML, PDF… Tout cela étant, également fonctionnel en mode Internet : il y avait de la bave sur les sièges…

Pour nous, c’est le vainqueur. C’est absolument impressionnant à voir ! Ca montre notamment les capacités offertes par AIR et confirme son positionnement sur une application Internet mêlée à une application de bureau.

Autres articles sur le même sujet

• Du HTML dans mon Flex…
• Live from MAX Milan : hands on thermo…
• MAX 09 – Le multitouch
• MAX 09 – Ça annonce !

Un conférence sur le multitouch, un thème qui nous tenait à coeur pour cet événement !

MAX a été l’occasion pour Adobe d’aborder le multitouch de manière plus détaillée. En effet, le matériel commence à devenir disponible pour le grand public et le succès de l’iPhone montre déjà l’intérêt des utilisateurs pour ce type d’interactions et la nécessité d’anticiper cette composante dans la conception des nouvelles Interfaces Homme Machine.

Nous résumerons ici deux conférences auxquelles nous avons pu assister : la première « officielle » assurée par une personne du groupe Cynergy, relativement générale et montrant quelques exemples intéressants. La seconde, appelée « unconference », assurée par une personne d’Adobe, en charge de la prise en compte du multitouch au niveau du Flash Player 10.1, celle-ci plus technique et orientée sur les bonnes pratiques, particulièrement intéressantes.

Essayons de ressortir les principales idées et conclusions de tout cela.

La présentation s’articule autour des axes suivants :

• Matériel et principaux environnements de prise en charge, à disposition du grand public
• Types de mouvements reconnus nativement sur ces matériels
• Implémentation avec AIR 2.0 et bonnes pratiques

Matériel et principaux environnements

Aujourd’hui, le multitouch est accessible au grand public via :

Types de mouvements et informations reconnus

• Natifs
  • Zoom,
  • Swipe (action de faire glisser à deux doigts),
  • Rotation
  • Taille d’appui sur l’écran
• Personnalisés (permet d’implémenter ses propres interprétations de mouvement)

C’est peu mais suffisant pour la plupart des actions connues.

On regrettera le fait que seul un mouvement natif est reconnu par le système à la fois, impliquant qu’on ne peut zoomer et faire pivoter un élément en même temps. Il faut dans ce dernier cas se débrouiller.

On appréciera aussi le fait que le « standard » établi par l’iPhone se retrouve dans les mouvements reconnus et pris en charge pour tous ces systèmes. A savoir que les mouvements natifs ne peuvent être utilisés en concurrence avec les événements personnalisés. Aussi, soit vous faites du natif, soit vous vous démerdez… Why not !

Implémentation avec AIR 2.0 et bonnes pratiques

La nouveauté est que AIR 2.0 écoute les événements envoyés par les systèmes multitouch et offre une API assez simple permettant d’y réagir. nous ne rentrerons pas dans les détails, mais plusieurs choses doivent être prises en compte avec attention pour produire une « bonne » application multitouch :

• Il est important de pouvoir gérer les événement Souris et les événements Touch de manière unifiée pour que l’application reste compatible avec un système standard. N’oublions pas que le multitouch est loin d’être encore accessible à tous
• Il faut penser à la taille des doigts : un bouton sera certainement plus gros dans une application multitouch, l’homme étant moins précis que la souris (désolé pour la blague de geek).
• De ce fait, il faut idéalement être capable d’adapter son application à des résolutions différentes : certaines applications multitouch prennent tout leur sens sur des écrans très grands (table type Microsoft Surface), mais peuvent être amenées sur des écrans plus petits (tablet PC par exemple). Selon la résolution cible, un pixel n’aura absolument pas la même taille et l’application pourra devenir totalement inutilisable
• Utiliser un gestionnaire personnalisé d’interprétation de mouvement en ActionScript (type touchLib) se révèle être une solution généralement plus flexible voire performante que l’usage de la détection native de mouvements simples. D’autant plus quand on repense à la restriction de non parallélisation de mouvement natifs simples (zoom + rotation).

Conclusion

Nous arrivons à un moment où les outils se présentent pour proposer des interface apportant réellement quelque chose en terme d’innovation et d’interactivité. C’est donc naturellement qu’Adobe s’insère dans cette voie et propose de reprendre la main sur les technologies déjà existantes dans ce domaine (type TUIO, touchLib…) et se tient prêt pour le matériel de demain !

A quand les éléments tangibles dans les boutiques Adobe ?

À noter : vous pouvez retrouver  les conférences sur le multitouch, sur Adobe TV :

• Multitouch Development with flex
• Multitouch and the flash plateform

Autres articles sur le même sujet

• MAX 09 – Où est passé le Text Layout Framework ?
• MAX 09 – Sneak Peeks !
• MAX 09 – Ça annonce !
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher

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

Un peu moins de 4 mois après la sortie de la beta1 , AIR poursuit son développement et passe en beta2. Voici la liste des nouveautés annoncées, ainsi que le lien vers les docs qui vont bien :

• amélioration de la gestion des icones du « system tray » ou du « dock », possibilité de :
  • définir une image ou une animation pour l’icone du dock
  • gérer les mouse Events sur celui-ci
  • activer le « icon Bounce » ( sur mac )

• Synchronous database API :

il est possible de définir au moment de la création de l’instance de la connexion à la BDD locale (SQLConnection ) si les opérations seront synchrones ou asynchrones.

• Native menus :

Possibilité d’insérer la barre des menus propre à chaque OS

• Améliorations et modification du système de DRAG’n'Drop:

Disparition des classes TransferableData and ClipboardManager pour laisser place à un Clipboard.generalClipboard ( Singleton ) Drag and drop enhancements including bitmap support

• Amélioration du modèle sécurité ( plus d’infos )

• gestion du plugin Acrobat reader 8.1 pour affichage des pdf dans les HTMLControl

• Gestion des profondeurs de fenêtres et des multi-Ecrans

• Amélioration de la fenêtre d’installation et du système des installations ‘seamless’

• Activation et gestion du Focus

• Gestion des mises à jour d’applications ( classe Updater )

• gestion du double-clic et de la molette des souris

• Améliorations des performances et de la gestion de la mémoire

• gestion de la « signature d’applications »

• support du XSLT

• compatibilité avec Windows 2000

• des centaines de bugs fixés…

A lire aussi :

• guide de migration beta 1 -> beta 2
• Air security Documentation

Tous les infos nécessaires dans la doc officielle.

Bon ben au boulot maintenant !!!Autres articles sur le même sujet

• Adobe Air : comment proposer une "air express install" ?
• L’ère de l’AIR
• Noël avant l’heure : la journée de la béta 2 sur Labs.adobe.com
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher

L’un des problèmes avec les applications Air, c’est qu’elles nécessitent… AIR justement. Ce qui veut dire télécharger l’installeur, installer le runtime, ensuite télcharger et installer l’appli. Comme pour le lecteur flash depuis la version 8, Air permet heureusement de proposer une « air express install », beaucoup plus simple pour l’utilisateur. Je ne sais pas si vous avez jeté un coup d’oeil à Adobe ‘Digital Edition’, une appli de lecture/gestion de pdf. Sur la page Adobe, le lien proposant l’installation, on voit un petit bandeau « Install now ». Ce lien est en fait un fichier swf capable d’installer de manière transparente le runtime air ainsi que l’application .air souhaitée sur la machine de l’utilisateur. Cet installeur automatisé vérifie la présence du Runtime, le télécharge et l’installe si nécessaire, télécharge le .air, l’installe et ‘boooom’… l’appli est lancée . On a tout simplement l’impression d’avoir ouvert une « popup Air ».

-UPDATE : – Comme Tekool me l’a fait remarqué, et l’explique dans son article, la fonctionnalité n’est pas entièrement supportée par la version béta de Air, et pour le moment seule l’installation du runtime peut être faite via le navigateur, ensuite, contrairement à Digital Edition, c’est une fenêtre « applicative » qui propose l’installation du fichier .air. –

Pour proposer l’installation « express » du runtime Adobe Air :

1. récupérez le SDK Air
2. à l’intérieur, vous trouverez un dossier source contenant un fichier ‘badge.fla’ et un ‘install.as’, copiez les et placer les dans le dossier de votre projet.
3. vous pouvez « personnaliser » le Fla
4. Publiez votre swf

Une fois le swf prêt il ne reste plus qu’à l’intégrer dans un page html. Pour fonctionner le badge à besoin de trois variables obligatoires :

• appname : le nom de l’application
• appurl : l’adresse du fichier
• airversion : pour le moment : 1.0.M4

Vous pouvez également transmetre une couleur de fond pour le bouton :

• buttoncolor

Il va donc falloir transmettre ces variables depuis la page html, grâce aux FlashVars. Au final, avec le AC_RunActiveContent.js ( script de gestion du Active Content pour tous navigateurs, automatique avec Flash CS3 mais nécessite cette extension pour Flash 8 ), ca donne :

voir l’exemple / Télécharger les sources de l’exemple

Chose un peu étonnante, j’ai regardé comment Adobe l’avait intégré sur leur site, et j’ai eu la surprise de voir qu’il préfére le JS de swfobject, à celui qu’ils fournissent eux même pour gérer l’Active content (AC_RunActiveContent.js )… J’ai essayé vite fait de faire pareil, mais j’ai dû faire une bourde, çà bug ! à suivre…Autres articles sur le même sujet

• L’ère de l’AIR
• et Adobe créa l’.air!!!
• Flex Builder 3 et le PHP ( PDT ) : installation
• Développer une application iPhone – XCode et Interface Builder passés au crible