AIR et javascript

Exécution et interprétation du javascript

Soyons clairs : le javascript dispose d'un support complet et très performant, Webkit étant un moteur d'exécution très rapide et fluide. On peut s'attendre à une performance similaire à de l'exécution dans Safari au détail près que AIR est pourvu d'une version antérieure de Webkit.

Rien d'autre à dire ici, le tout étant très performant.

Support des bibliothèques javascript

Le javascript c'est bien, mais si je veux utiliser une bibliothèque javascript ?

La réponse est : c'est possible mais pas toutes. J'avoue ne pas avoir testé chacune des bibliothèques existantes pour voir quel est le niveau de support de cette dernière :

1. parce qu'il y en a trop ;
2. parce que je n'ai pas la prétention de vouloir connaître quinze ou vingt bibliothèques différentes, j'ai déjà suffisamment à faire avec jQuery.

Donc selon cette page chez Adobe, les bibliothèques supportées pour la version actuelle de AIR (1.5) sont :

• Dojo Toolkit (http://www.dojotoolkit.org/) (en anglais);
• Ext JS (http://extjs.com/) (en anglais);
• jQuery (http://jquery.com/) (en anglais);
• Mochikit (http://mochikit.com/) (en anglais);
• Mootools (http://www.mootools.net/) (en anglais);
• Spry (http://labs.adobe.com/technologies/spry/) (en anglais).

Petit bémol : il apparait que la faq d'Adobe AIR n'a pas été mise à jour depuis quelques temps (les versions des bibliothèques évoquées sont anciennes déjà). Néanmoins, on peut supposer que le support des bibliothèques suit leur évolution.
J'utilise personnellement jQuery, et je n'ai rencontré aucun problème pour l'instant (bien que ma version soit largement plus récente que celle proposée sur le site). Il parait également probable que d'autres bibliothèques viennent enrichir à l'avenir Adobe AIR (je pense notamment à Prototype et Scriptaculous).

En plus de jQuery, j'utilise jQuery UI (http://jqueryui.com/, UI pour User Interface), une bibliothèque modulaire d'effets qui se greffe à jQuery simplement. Seulement voilà : tout n'est pas supporté encore. Certaines méthodes fonctionnent, d'autres pas (la majorité des effets par exemple). Il se peut qu'en rusant et en détournant un peu notre façon d'écrire le script, cela fonctionne quand même.

Prenons un exemple simple : un des apports de jQuery UI est de permettre au développeur de faire la transition entre deux classes CSS qui changeraient une couleur (de texte par exemple). UI se charge toute seule de faire la transition entre les deux couleurs.

Le CSS, basique :

.blue {
    color:#00f;
}

.green {
    color:#0f0;
}

Le script d'animation de la couleur, basique également :

jQuery("#monElement").switchClass("blue","green", 500);

La méthode switchClass() permet de replacer une classe existante (ici "blue") par une autre classe (ici "green") et d'exécuter l'animation selon une durée en millisecondes prédéterminée (ici "500"). Très pratique. Mais voilà : cela ne fonctionne pas. La classe change mais la transition est nulle.

Afin de contourner cette petite difficulté, le retour à une méthode propre à jQuery est obligatoire :

Le script d'animation de la couleur, modifié :

jQuery("#monElement").animate({color: "#0f0"},400);

On admettra que la couleur par défaut de notre élément est le bleu. La méthode animate() permet de doucement glisser vers la couleur de notre choix. C'est plus intrusif, mais cela fonctionne.

Cet exemple est délibérément trivial. Il est juste là pour illustrer le fait que certaines choses fonctionnent alors que d'autres non. Le modèle de sécurité d'Adobe AIR doit interférer dans la bonne exécution de certaines parties de bibliothèques comme jQuery UI.

Spécificités de l'exécution du javascript

Adobe AIR permet de créer des applications pour le bureau. Ces applications ont accès au système de fichiers : elles peuvent stocker des informations sur la machine hôte, créer dossiers, fichiers, les effacer etc.

Afin de garantir un niveau de sécurité optimal pour les utilisateurs d'application AIR, Adobe a mis en place un système de sécurité.
Certaines méthodes javascript, jugées potentiellement dangereuses sont inopérantes dans la partie de l'application ayant accès au bureau.

Parmi elles, on compte :

• setInterval()
• setTimeout()
• eval() (utilisée pour évaluer un objet javascript, tel qu'un objet JSON par exemple).

Mais alors comment je fais ?

Comme je l'ai évoqué plus haut, Adobe AIR possède un modèle de sécurité particulier : application sandbox et non-application sandbox.

Petite explication rapide (je reviendrai sur le modèle de sécurité dans un billet à part entière).
Il faut imaginer notre application divisée en deux parties :

• la partie qui a accès au bureau ou application sandbox, aux fichiers mais qui ne peut pas exécuter de scripts jugés dangereux ;
• la partie isolée ou non-application sandbox qui peut exécuter sans limitation tout type de scripts (la limitation pour eval(), setInterval() et setTimeout() ne s'applique pas) mais qui en revanche, n'a pas du tout accès à l'API de AIR et à ses méthodes. Autrement dit, c'est comme une pièce sans porte ou fenêtre : rien ne rentre (ou presque) et rien n'en sort (ou presque). C'est dans cette "boîte" que nous pourrons lancer des évaluations d'objet JSON par exemple.

Bien qu'un peu contraignant au début, ce système permet de garantir la sécurité du poste de travail de l'utilisateur.

Je reviendrai sur ce modèle de sécurité plus en profondeur dans un prochain billet et notamment sur le moyen de faire communiquer les deux sandboxes entre elles.

Je suis intéressé par tout retour éventuel concernant le support d'une librairie javascript particulière dans AIR que je n'aurai pas cité dans ce billet.