EKAMELEON - DevBlog ActionScript & ECMAScript

J'ai beaucoup de travail en ce moment pour finaliser les outils permettant d'utiliser le design pattern d'Inversion de Contrôle avec VEGAS (mon framework opensource) et je suis en train d'écrire un gros article (50aines de pages !) sur le sujet qui arrivera d'ici peu sur ce blog et via une publication opensource basée sur des documents au format Google Documents

En attendant, voici un petit article très simple pour vous parler d'un mini "problème" découvert par des amis à moi il y a quelques semaines. Je devrais parler d'un "changement de comportement" plutôt que d'un problème...

Voyons donc de plus prêt le comportement de la méthode MovieClip.play() en ActionScript 3.

Nature du problème

Pour tester et isoler le problème de la méthode MovieClip.play() en AS3, il suffit de suivre la méthodologie suivante :

1 - Ouvrir Flash CS3 et créer un nouveau document.

2 - Créer un MovieClip dans la bibliothèque du document ouvert et à l'intérieur créer une petite interpolation de forme ou de mouvement pour que le clip contienne une petite animation sur plusieurs images clés.

3 - Créer un calque de code dans le scénario (timeline) du clip et mettre un stop(); sur la première image clé du clip.

4 - Poser une occurrence du symbole sur la scène et lui donner un nom d'occurrence "mc" dans le panneau de propriété en ayant bien pris le temps de sélectionner le clip avant.

5 - Créer sur la scène principale un calque de code au dessus du calque qui contient l'occurrence et taper le code suivant :

mc.play() ;

Si nous essayons de compiler le swf (CTRL + ENTER) avec une publication au format AS1 ou AS2 (voir paramètre dans panneau des paramètres de publication du document), pas de problème l'animation du clip se lance sans problème.

Si par contre nous essayons de compiler avec un format AS3 avec une publication pour le FlashPlayer 9 alors le clip ne lance pas l'animation est reste figé sur sa première image clé.

Il est très important de pouvoir "localiser" (ou régionaliser) nos applications. Localiser une application permet de rendre dynamique son contenu (texte, sonore ou autres) en créant une interface utilisateur qui peut changer en fonction d'une langue en particulier. La localisation d'une application permet d'améliorer l'accessibilité pour différents utilisateurs et il est certain qu'avec toutes les difficultés que l'on peut avoir pour communiquer de façon général, il est tout de même sympathique de pouvoir le faire avec le plus grand nombre dans le monde entier.

Une bon moteur de localisation permet de changer à tout moment les traductions et éléments graphiques de l'application en fonction de données traduites dans plusieurs langues. Il est certain que le plus souvent la localisation d'un site passe par une page d'accueil simple qui permet de diriger l'utilisateur vers une version spécifique de l'application avec un contenu régionalisé. Pour ma part dans VEGAS j'ai préféré créer un moteur qui possède les caractéristiques suivantes :

• Externalisation des traductions et documents.
• Utilisation de fichiers ou données externes encodées en UTF8.
• Moteur dynamique au "runtime". La localisation doit être totalement dynamique et doit intervenir après la compilation (plus léger et plus simple à maintenir)
• API simplifiée permettant de centraliser les mises à jours de l'interface utilisateur via un mapping utilisant plusieurs stratégies selon les besoins.
• Par défaut, utilisation du format de donnée eden (http://code.google.com/p/edenrr/) ou JSON (http://www.json.org) même si il est vrai que j'utilise très peu cette dernière notation. Malgré tout il est assez simple de créer un module de parsing basé sur une autre notation comme par exemple du XML.

Dans Flash et surtout dans le framework de base ActionScript nous trouvons la propriété flash.system.Capabilites.language qui permet à tout moment de renvoyer le code langue du système dans lequel l'application swf vient d'être lancée. L'ActionScript se base sur des noms des "codes langue" au format ISO 639-1, par exemple la propriété language aura pour valeur "fr" si le système par défaut est un système français.

Implémentation du moteur de localisation de VEGAS

Dans VEGAS le moteur de localisation se trouve dans le package asgard.system.

1 - La classe asgard.system.Lang

La première classe que nous allons étudier dans ce package est la classe asgard.system.Lang qui permet d'énumérer les "codes langue" par défaut définis par la norme ISO 639-1 dans le FlashPlayer. Cette classe donne un outil simple pour valider dans vos applications les langues disponibles. Il est ainsi possible d'ajouter d'autres langues en cas de besoin dans la liste des langues par défaut du FlashPlayer mais bien entendu elle ne seront pas prises en compte automatiquement par la propriété System.capabilities.language(AS2) ou flash.system.Capabilities.language(AS3) du Flash Player.

Voici un exemple d'utilisation de cette classe :

Il n'y a pas de secret. Le code ne passe pas seulement par des interminables lignes de code mais surtout par d'interminables lignes de documentation (en général plus nombreuses). Un framework, une classe, un bout de code non documenté et c'est très rapidement l'anarchie.

Pour générer nos documentations en AS3 ou MXML, Adobe nous propose ASDoc une application en ligne de commande assez complexe mais qui a le mérite de générer une documentation HTML bien complète.

Je ne vais pas entrer dans mon article sur une explication super détaillée de toutes les options proposées par ASDoc ou encore sur la "meilleure manière" de générer sa documentation via une tache ANT ... Je préfère vous parler d'une fonctionnalité à mes yeux importante et pourtant non prévue dans ASDoc : la colorisation syntaxique du code contenu dans la documentation.

En effet, même si ASDoc propose via les balises code et listing une "solution" pour afficher une partie du texte contenu dans vos documentations avec un formatage "spécifique".. on peut pas dire que le résultat soit très explicite !

A côté de cela Google a sorti il y a un petit moment maintenant un petit module opensource écrit en JAVAScript qui permet de coloriser un code HTML efficacement via le script Google Code Prettify. L'intérêt de ce module réside dans le fait qu'il ne nécessite pas, comme GESHI (PHP) par exemple, d'un script serveur pour coloriser le code d'un texte HTML.

Google Code Prettify permet de coloriser un bon nombre de langages et fonctionne vraiment bien avec les langages basés sur une écriture C, Java, Python, Bash, SQL, HTML, XML, CSS et Javascript.

Pour faire simple Google Code Prettify permets de modifier dynamiquement dans une page HTML les balises pre et code possédant un attribut "class" avec la valeur "prettyprint" comme ceci :

<html>
 
    <header>
 
        <link href="prettify.css" type="text/css" rel="stylesheet" />
        <script type="text/javascript" src="prettify.js"></script>
 
    </header>
 
    <body onload="prettyPrint()">
 
    <p>
 
    <pre class=prettyprint>
    var s = "hello world" ;
 
    var sum = function( n1 , n2 )
    {
        return n1 + n2 ;
    }
 
    trace( 2 + 3 ) ;
    </pre>
 
    </p>
 
    <p>The previous script return <code class="prettyprint">5</p></p>
 
    </body>
 
</html>

Au final, nous avons d'un côté ASDoc un applicatif en ligne de commande qui permet de documenter nos classes via la notation JAVADOC et un texte au format HTML distribué officiellement par Adobe et de l'autre côté Google Code Prettify qui permet de formater un texte HTML si il contient des scripts. L'idée est de pouvoir utiliser les 2 pour créer nos documentations AS3

Généralités

Voici mon premier feedback technique sur Flash Media Interactive Server 3.... Sérieux... pourquoi Adobe donne un nom aussi compliqué à son serveur ? A chaque fois que je suis obligé de parler de FMS3 j'ai l'impression de discuter de la dernière version de Street Fighter 2 Turbo X fatal mega super tropdur alpha combo lol Donc je décide de faire simple et d'utiliser le terme FMS3 dans la suite de mes articles... (fin de cette petite note sur la nomenclature de mes articles traitant de FMS3 :D)

Comme je l'ai déjà dit, les enjeux majeurs de cette nouvelle version de FMS reste une amélioration des performances, une amélioration de la qualité des vidéos en live streaming (full HD avec H264) et pour finir une baisse des prix des licences et une simplification de celles ci en proposant seulement 2 types de serveurs (oui quand je parle de simplification, je ne parle pas du nom des serveurs... cf début de ce message ;))

Reste que pour ma part, même si après l'annonce officielle de la sortie de FMS3 je n'avais que très peu d'espoirs dans les nouveautés au niveau du code côté serveur (pas d'AS3 ou d'ES4 côté serveur), j'espérais que Adobe mettrait un peu plus d'efforts dans l'évolution de la nouvelle version de FMS en faisant une petite mise à jour du moteur Javascript SSAS de FMS. J'avais de gros espoirs là dessus en prenant en compte l'arrivée de l'E4X en AS3 et de la disponibilité de l'E4X depuis la version 1.6 du Javascript. Surtout qu'en regardant Flash CS3 de plus prêt on se rend rapidement compte que le moteur JSFL est bien en version 1.6 !

Ainsi, pendant l'installation du serveur j'ai rapidement ouvert le PDF flashmediaserver_SSLR.pdf contenu dans le répertoire de documentation du serveur et tout de suite j'ai était "choqué" en lisant une documentation pratiquement similaire à la version que l'on peut trouver dans l'installation de FMS2 avec dès le début le joli paragraphe :

Server-Side ActionScript is Adobe’s name for JavaScript 1.5. Flash Media Interactive Server has an embedded Java-Script engine that compiles and executes server-side scripts. This Server-Side ActionScript Language Reference documents the Flash Media Interactive Server host environment classes and functions. You can also use core Java-Script classes, functions, statements, and operators. For more information, see the Core JavaScript 1.5 Reference at http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference. For more information about JavaScript, see “About JavaScript” in the Mozilla Developer Center at http://developer.mozilla.org/en/docs/About_JavaScript.

Bref... je veux bien que l'on ne passe pas tout de suite à une version Javascript 2 ou AS3/4 du SSAS mais là c'est vraiment n'importe quoi ! Il faut à mon avis très peu de temps pour changer le JS engine de FMS pour les développeurs d'Adobe et il ne faut pas oublier qu'à l'heure actuelle Mozilla est en train de diffuser les bases du Javascript 1.8... Politique commerciale ou tout simplement simple suffisance des développeurs d'Adobe. Pour ma part je me demande sérieusement si Adobe utilise sérieusement son serveur.

Je passerai rapidement sinon sur la couche "script" des composants FMS mis à jour dans le répertoire scriptlib de l'installation du serveur avec un code tout juste remis à jour au niveau de la licence en entête des fichiers .asc.

Au final, j'ai beau chercher et je ne vois que très peu de nouvelles méthodes dans la documentation du serveur et encore pire ! La nouvelle documentation ne donne aucune information sur la compatibilité des méthodes côté serveurs compatibles avec FMS2 ou FCS 1.5 Il faut maintenant que je me penche un peu plus sur la documentation du PLUG-IN DEVELOPER GUIDE mais pour le reste une simple relecture rapide suffira je pense.

Alors oui ! C'est génial que le prix de la licence baisse ! C'est génial que la qualité des vidéos et la sécurité soient meilleures ! C'est génial d'avoir une version plus stable et performante du serveur ( peut être car à chaque fois que Adobe nous dit que le serveur est stable je me retrouve avec des soucis avec mes clients ... ) ! Mais sérieusement il y a un manque réel de suvi sur les besoins des développeurs SSAS. On est limite dans un flou artistique depuis le début avec FMS qui favorise l'utilisation des composants de Adobe (vraiment médiocres pour le moment) et commercialement annonce bien la sortie prochaine des projets Cocomo et Pacifica.

AMF3 avec FMS3

J'en reviens maintenant au sujet de mon article, avec l'utilisation du protocol AMF3 avec FMS3

Bonne nouvelle malgré tout ce que j'ai pu dire plus haut, FMS3_ apporte la possibilité d'utiliser des données transférées entre le serveur et les clients Flash via le protocol AMF3. Il est donc possible maintenant de diffuser des ByteArray et des instances de type XML(E4X) directement via les méthode NetConnection.call() (AS3) et Client.call()__ (SSAS).

Voici donc un petit exemple d'utilisation de l'AMF3 avec Flash CS3 et FMS3 :

Présentation du problème

Voici un petit article rapide pour vous informer d'un gros problème que j'ai pu rencontrer ces dernières semaine lors de la mise en ligne de plusieurs projets basés sur des applications qui se connectent à un serveur Flash Media Server. Pour une fois, je ne peux pas mettre en cause la stabilité du serveur FMS car au final c'est bien Windows VISTA qui n'aime pas Flash Media Serveur

La description du problème reste simple et se résume au ralentissement des échanges de données entre un client Flash et un serveurt FMS. Par exemple pour connecter un client Flash avec un serveur FMS en ligne, la connexion entre le client et le serveur se fait bien automatiquement mais ensuite les informations ou données renvoyées par le serveur peuvent prendre en moyenne 3 à 5 secondes pour revenir à chaque requête vers le client

Il m'a fallu un certain temps pour trouver la nature exacte du problème.

En prenant tout d'abord en compte la possibilité que le bug puisse provenir du Flash Player lui même (problème de stabilité du player avec Windows VISTA ?). Mais non le problème ne provient pas du FlashPlayer. Il faut dire qu'avec toutes les sécurités injectées dans les dernières version du player, j'ai eu très peur que Adobe nous ai coulé FMS en sortant les dernières version du FlashPlayer mais ce n'est pas le cas.

J'ai également très vite repoussé l'idée d'un bug provenant de mon code car l'application fonctionne parfaitement sur les autres versions de Windows, ainsi que sur MAC.

Il reste donc que Windows Vista dans la liste des responsables ! N'ayant pas Windows Vista installé sur ma machine, il a fallu tout d'abord que je me procure un ordinateur tournant sous une configuration VISTA et ensuite il a fallu passer beaucoup de temps dans les pages de Google pour trouver une réponse à mon problème. Je remercie au passage Zwetan pour quelques liens envoyés un soir sur Google Talk qui m'ont permis au final de trouver la solution... enfin si on peut appeler cela une solution lol

Il est clair que la sécurité de VISTA pose problème et que le problème d'échange de données entre un client Flash et un serveur FMS n'est pas le seul problème rencontré sur la toile avec cet OS. Donc, en cherchant un peu en profondeur on se rend compte que le gros soucis vient d'une protection sur les données réceptionnées par VISTA avec le protocol TCP/IP.

Travaillant pour ma part sur un Window XP pro je n'avais pas imaginé qu'un tel problème puisse exister et je peux vous dire qu'après de longs mois de développement sur une application, c'est assez décourageant de se rendre compte qu'un problème comme celui là (indépendant de notre volonté) peut compromettre des heures et des heures de travail. En effet... Vista est diffusé massivement dans toutes les configurations actuellement en vente (portable ou ordinateur acheté en magasin) et un utilisateur lambda n'a pas le réflex d'acheter une machine sans VISTA.

Solution actuelle au problème

Voici tout d'abord le lien qui m'a permis de trouver une réponse à ce problème : Slow network in Vista?

Windows Vista propose une protection des données reçues en TCP/IP avec un filtrage activé par défaut, chez Microsoft ils appellent cela le Receive Window Auto-Tuning Level

Pour configurer et éditer cette protection dans VISTA il faut suivre les opérations suivantes :

• Touche VISTA
• Ouvrir la console DOS en tapant : CMD
• Taper ensuite dans la console la commande : netsh interface tcp show global

Il s'affiche alors les paramètres de sécurité TCP de VISTA :

TCP Global Parameters
------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : enabled
Receive Window Auto-Tuning Level : enabled
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled

Nous pouvons nous rendre compte que la protection est bien activée par défaut avec la ligne : Receive Window Auto-Tuning Level : enabled

Voici un petit message qui sort un peu de ma ligne éditoriale habituelle avec une proposition d'offre d'emploi pour la société JobinLive spécialisée dans le vidéo recrutement dans le sud de la france (Marseille).

En plus de travailler au soleil et prêt de la mer (super important pour le moral et la motivation ;)), le candidat sélectionné travaillera directement avec une équipe de développeur (dont je fais parti en tant que chef de projet et responsable R&D) sur de nombreux projets online et offline utilisant principalement des technologies comme Flash Media Server, Flash Remoting, AIR, etc.

Il n'y a pas de profil particulier sur le plan de l'éducation. Un portfolio avec des références ou projets prouvant les talents du candidat sera aussi important que des années d'étude. Le candidat devra tout de même justifier une certaine expérience dans le profil recherché.

Poste proposé :

WebDesigner et développeur ActionScript avec bonne maitrise dans le domaine du montage vidéo et de l'animation.

Généralité

PEGAS est une extension AS2/AS3 de VEGAS, je n'ai pas encore beaucoup parlé de cette extension mais il est temps de commencer des tutoriels concernant cette bibliothèque de code spécialisée.

PEGAS possède des fonctionnalités spécifiques définies par les packages suivants :

pegas.color

Manipulation et gestion avancée des couleurs.

pegas.draw

Ce package contient des outils de dessin avancés utilisant les API de dessin dynamique et permettant la création et l'affichage de dessins complexes via des structures de données ecmascript ou via un document au format SVG.

pegas.geom, pegas.maths et pegas.util

Ces 3 packages mettent à votre disposition des outils mathématiques et géométriques de bases permettant de gérer des transformations physiques ou 3D dans vos applications.

pegas.process

Moteur de process permattant de créer des actions et des séquenceurs d'actions dans vos applications. Une action est un objet qui s'éxécute via une méthode "run" (IRunnable) mais qui permet de notifier au moins 2 événements au début et à la fin du process.

pegas.transitions

Ce package contient des outils pour créer facilement des interpolations numériques simples ou complexes (Tween) dans vos applications. Il contient également un moteur de transitions utilisant toutes les fonctionnalités du package pegas.process.

pegas.ui

Ce package permet la gestion des double-click(AS2) et la gestion des fonctionnalités avancées liées aux touches du clavier (KeyValidator).

Les interpolations (tweens).

Une interpolation est un changement d'une valeur numérique dans le temps. Le plus simple exemple d'utilisation d'une interpolation réside dans une petite animation sur un clip sur la scène principale d'une animation flash qui permet de faire bouger le clip entre un point et un autre.

En général, la première chose que l'on apprend en utilisant Flash c'est la création des animations sur le scénario de Flash en utilisant sur les formes ou les symboles des interpolations. Malgré l'extrême simplicité d'utilisation de ces interpolations automatiques nous nous rendons rapidement compte qu'un peu de code permet d'aller beaucoup plus loin dans ce domaine.

C'est Robert Penner et sa célèbre classe Tween qui a révolutionné réellement la philosophie des flasheurs en leur proposant une solution élégante pour créer des animations en utilisant des équations de mouvement mathématiques permettant de créer des mouvements naturels et non linéaires. Adobe a vite intégré cette fonctionnalité dans Flash MX 2004 pour donner du mordant à ses composants et depuis la classe mx.transitions.Tween reste un grand classique.

Malgré tout l'implémentation de Adobe reste sympathique mais de nombreux développeurs se sont essayés dans l'implémentation d'autres solutions proposant au final le même résultat. J'ai donc moi même très rapidement crée ma propre implémentation de l'algorithme d'interpolation basé sur des équations de mouvements en gardant l'esprit d'origine de la classe de Robert Penner mais en changeant légèrement le moteur interne et l'étendu des possibilité de la classe originelle.

Dans PEGAS j'ai donc décidé dans le package pegas.transitions d'implémenter 2 classes TweenLite et Tween

A noter que tous les exemples de ce tutoriel peuvent être testés dans le repository de VEGAS dans le répertoire AS2/trunk/bin/test/pegas/transitions

La classe pegas.transitions.TweenLite

Cette classe possède pratiquement toutes les fonctionnalités de la classe mx.transitions.Tween de Adobe. Elle permet de controler sur un objet une propriété numérique et de la modifier dans un certain intervalle de temps donné.

Voici un exemple basique d'utilisation de cette classe.

import pegas.transitions.TweenLite ;
import pegas.transitions.easing.* ;
 
var tw:TweenLite = new TweenLite(mc, "_x", Bounce.easeOut, mc._x, 550, 1, true) ;
tw.run() ;