vhe74′Stuff

Je vous ai déjà parlé à plusieurs reprises de l’architecture AIR, par le biais d’applications, mais j’ai pensé qu’il était nécessaire de remettre tout ça dans son contexte afin de mieux la comprendre

L’architecture AIR d’adobe c’est l’aboutissement de la convergence de plusieurs technologies maîtresses chez Adobe. On vu ces dernières années les sites Web à interfaces riches prendre de plus en plus d’ampleur, avec une forte proportions de sites réalisés en Flash. Passé ce premier point, à l’intérêt esthétique indéniable, les ingénieurs Adobe se sont rendu compte que l’orientation métiers de la production graphique de Flash c’était quand même pas extraordinaire pour produire de véritables environnements applicatifs. Je me souviens avoir essayé de produire un configurateur de produits en Flash, rapidement l’équipe de développement était revenu vers une applet Java. C’est ce qui vu l’arrivée  de la technologie Flex donc l’objet est de produire a partir d’un environnement de développement intégré de véritables interfaces riches pour applications Web. Les applications produites sont en fait des fichiers SWF qui s’appuient sur le runtime Flash dans un navigateur pour s’exécuter. Avec cette technologie Adobe parvenait donc à faire revenir dans son giron des tas de purs développeurs qui pouvaient porter leur savoir faire vers la plateforme Flash. De nombreuses communauté on commencé à créer des API pour accéder à tel ou tel service sur le Web, et le potentiel de la plateforme est très vite apparu avec surtout une capacité à mettre en œuvre de solides scénarios de d’interaction avec l’utilisateur.

La richesse de ces applications développées a fait apparaître leur principale faiblesse qu’était leur exclusive intégration dans le navigateur Web. Le modèle de sécurité du runtime Flex ne permettait pas par exemple d’accéder à des ressources locales sur le poste de travail, ou d’interagir de manière complexe avec l’utilisateur. C’est à ce moment là que le runtime AIR est apparu avec comme objectif de nous permettre de passer de RIA (Rich Internet Application) à des RDA (Rich Desktop Application). L’idée de base étant de conserver la portabilité du runtime Flash de Windows à Mac en passant par Linux et d’en faire une plateforme complète.  Toutes les fonctionnalités nécessaire à mettre en œuvre des applications sont intégrée dans le runtime, il ne reste plus qu’à déployer, enfin presque !

Ici volontairement je vais pas parler de langage mais plutôt de plate-forme, quand on commence à parler d’une application. Les langages vont se caractériser par plusieurs point que sont leur complexité, le spectre fonctionnel couvert (éventuellement par des frameworks disponibles), et leur facilitée de mise en oeuvre. Comme beaucoup de monde j’utilise depuis la nuit des temps des outils basés sur du php pour mes plate-formes (wordpress, dotclear, frontaux d’accès à des bases de données… ), j’ai utilisé de manière ponctuelle Ruby-on-rails, et maintenant je m’aperçois que python est de plus en plus utilisé. L’une des différences ente ces approches est principalement due au fait que d’un coté on a des langages simples plus ou moins généralistes et que de l’autre on se retrouve avec des frameworks complet beaucoup plus rigides.

Le PHP à plusieurs avantages, c’est un langage qui est dédié à la création de pages web. Ceci permet une grande souplesse dans la création sur un mode itératif, mais a comme corollaire de permettre de rendre le produit rapidement non maintenable. En effet cette approche ne favorise pas la séparation des éléments d’interface des éléments de code, a moins là aussi de mettre en oeuvre un framework. Les expériences que j’ai pu avoir de reprise de code après de longue périodes de production ont été assez dramatiques.Un autre avantage de PHP c’est son universalité, qui permet de facilement déployer les pages sur des hébergements simples. Bref PHP c’est idéal pour les petits projets, même si de grosses infrastructures l’utilisent.

RUBY ON RAILS est un framework complet construit autour du langage ruby. ce framework a comme gros avantages de facilement séparer la logique, du contenu, et de la présentation. En effet tout est formalisé au travers d’une architecture Model/Vue/Controller. Cette structuration apporte un indéniable confort dans le développement, permet de facilement structurer le développement en équipe, et apporte une capacité de maintenance du code incomparable. On retrouve un peut la démarche qu’on a par ailleurs avec une architecture J2EE, tout en étant plus abordable quand même. ROR permet une rapidité de création incomparable tant qu’on reste dans les limites du framework. Si on s’intéresse à des architecture de type interfaces riches (Flex, Air, Sylverlight), alors le découplage logique / présentation présente un intérêt non négligeable. Le gros défaut de ROR est qu’aujourd’hui les compétences sur le sujet sont assez limitées, et que lorsque la phase de maquette est terminée il faut déployer obligatoirement sur une infrastructure de type dédiée donc nécessairement avec une charge d’administration plus élevée.

Récemment je me suis intéressé  à Python, ayant vu que c’était le langage utilisé par Google pour son app engine, j’ai un peu plus creusé sur ce sujet. Aujourd’hui chez Google trois langages sont utilisés : C++, Java, Python. Python sert aussi bien en interne, qu’en externe pour réaliser toutes les chaînes de traitement, réaliser tout le packaging d’application, etc… Bref on est en présence d’un langage relativement structuré, donc suffisamment directif pour permettre de produire avec une certaine qualité, et d’être suffisamment versatile en termes d’usages. Il y a une communauté, et des sources d’informations importantes autour de ce langage, et le dernier point, et pas des moindres, c’est la disponibilité en offres d’hébergement, qui peut donc en faire une plate-forme non négligeable pour déployer des applications de taille moyenne.

Même si aucun choix sur ce sujet ne peut être définitif, je pense qu’il y a des pistes intéressantes à surveiller.

Le sujet du jour va être de quelle manière on peut utiliser les facultés de Adobe AIR à accéder au système de fichiers pour réaliser des fichiers de préférences pour une application.Le contexte va être le suivant, on va charger un fichier dans un objet de type XML, et ensuite il n’y plus qu’à aller chercher les variables dans cet objet. Pour ce qui est du sens inverse c’est tout aussi simple, on met à jour les variables et on enregistre le tout dans un fichier XML.

Commençons par quelques déclarations :

import flash.filesystem.*; //pour disposer des classes d'accès aux filesystems
public var prefsFile:File; //Le fichier dans lequel résident les préférences
public var prefsXML:XML; //L'objet XML dans lequel on va mettre nos data
public var stream:FileStream; //le flux qui sera utilisé pour lire/écrire dans le fichier

Ensuite, codons la fonction de lecture qui va voir comme faculté de créer le fichier si il n’existe pas. cette fonction doit être obligatoirement être appelée lors du cycle d’initialisation de  l’application. le fchier est placé dans le répertoire de stockage de l’application, ce qui permet de gérer facilement le portage entre les différents environnements.

private function lireprefs():void {

prefsFile = File.applicationStorageDirectory;
prefsFile = prefsFile.resolvePath("fichierpreference.xml");
stream = new FileStream();
if (prefsFile.exists) {

stream.open(prefsFile, FileMode.READ);
prefsXML = XML(stream.readUTFBytes(stream.bytesAvailable));
stream.close()
}

bon voilà tout va bien le fichier existe, donc pas de soucis, on le lit via le stream pour instancier la variable prefsXML, et le tour est joué. Là ou ça peut se compliquer c’est lorsque le fichier existe pas encore, et qu’il faut le créer au préalable. On positionne donc un else sur la condition précédemment utilisée et on gère cette situation. Dans ce cas on instancie la variable XML depuis une chaîne de texte, et on déclare chacun des noeuds à la suite les un des autres avec leur valeur par défaut :

prefsXML = new XML("<preferences/>");
prefsXML.prenom = "votre prenom";
prefsXML.nom = "votre nom";

Ensuite il faut créer le fichier depuis une chaîne de texte et y injecter le contenu de la structure, puis l’enregistrer sur le disque…

var outputString:String = '\n' + prefsXML.toXMLString();;
outputString = outputString.replace(/\n/g, File.lineEnding);
stream = new FileStream();
stream.open(prefsFile, FileMode.WRITE);
stream.writeUTFBytes(outputString);
stream.close();

C’est ce même bout de code qui sera utilisé lorsqu’il s’agira de sauvegarder le fichier de préférences par exemple lorsqu’on sortira de l’application.

Une fois qu’on a fait tout ça l’application peut continuer sa petite vie tranquille et on utilisera les variables de préférences tout simplement  :

label.text = prefsXML.prenom ;

Voila finalement c’était pas si compliqué, et ça peut dépanner dans bien des situations…