Rss Feed

Flash Builder 4 / Flex 4

Cela fait maintenant plus de 6 mois que nous développons sur la nouvelle version de Flex Builder, version s’appelant désormais Flash Builder 4. Nous avons commencé sur la beta 1, et sommes désormais sur la beta 2. Nous en sommes à 4 projets dont 2 qui sont en production ce qui nous donne un certain recul sur cette nouvelle version, sur les avantages, inconvénients par rapport à la version 3.

Nous entamons donc une série de billets qui vont porter sur les nouveautés de Flash Builder 4, de Flex 4, mais aussi sur les points qui peuvent poser des soucis dans le développement de tous les jours. Dans ces billets, nous posterons parfois des exemples qui contiendront bien évidemment le code source. Afin de compiler ce code source, il vous faudra au minimum le sdk Flex 4 pour l’installer sur eclipse ou Flex Builder 3 (disponible sur http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4) ou bien de télécharger Flash Builder 4 beta 2 (disponible http://labs.adobe.com/technologies/flashbuilder4/). Si vous disposez d’un numéro de série pour Flex Builder 3, vous pouvez obtenir un numéro de série pour Flash Builder beta2 pour étendre la période d’essai (disponible sur https://freeriatools.adobe.com/flashbuilder4beta/).

Avant de commencer la série de billets, nous voulions donner notre avis sur l’adoption de Flash Builder 4. Au sein de Matsiya, il est clair que nous ne souhaitons plus repasser sur Flex builder 3, les améliorations apportées par la version 4 surpasse de très loin les points négatifs de cette beta, qui seront, nous l’espérons, corrigés dans la version finale. De plus, cette version devrait être disponible cette année, donc il n’est pas inconscient de commencer un projet à l’heure actuelle sur cette version beta 2, qui reste très stable pour une version beta.

A très vite.

Loader application Flex / AIR

Nous avons développé plusieurs applications AIR / Flex. La plupart sont soumises à des clauses de confidentialité, mais heureusement quelques unes ne le sont pas, nous pouvons ainsi vous montrer le chargement.

Pour chaque application, nous réalisons un loader personnalisé à l’identité de la société qui indique l’état de chargement de l’application et le numéro de version.

En effet, au démarrage de l’application, nous pouvons être amenés à charger des modules ou des datas. Le temps de chargement et d’initialisation de l’application AIR peut prendre plusieurs secondes, il est donc important d’informer l’utilisateur de ce chargement.

load1.jpg

 

load3.png

 

load2.png

Loader AIR from Matsiya on Vimeo.

10 astuces pour optimiser les performances de Flex

Voici un article publié sur InsideRIA parlant de bonnes pratiques pour avoir un code flex performant.

A lire sans plus attendre : insideria tips for flex

Externaliser la configuration de ses remoteObjects.

Vous avez l’habitude de « hardcoder » les urls d’accès de vos remoteObjects, mais devez à chaque fois qu’il y a un changement de serveur recompiler tout le projet ? Ou bien lors du passage du projet entre le serveur de test et le serveur de prod ?

Christophe Coenraets nous propose un article simple et clair sur l’utilisation d’un fichier xml externe pour gérer cette configuration des remoteObjets.

À consulter sans attendre : l’article.

Magazine Flash/Flex en ligne

Le magazine en ligne « Flash & Flex Developper’s magazine » dans son édition de Mars vient d’être mis à disposition gratuite. Il est possible de le télécharger au format PDF à l’adresse suivante : http://www.ffdmag.com/prt/view/about-the-mag/issue/1015.html.

On retrouve dedans des infos sur des points précis du développement de flex, mais aussi sur des aspects plus génériques comme l’architecture de son application à l’aide du framework Cairngorm.

On y trouve aussi un intéressant article sur l’utilisation de modèles 3D, créés grâce au logiciel libre Blender, dans flash grâce à Sandy 3D.

A lire de toute urgence pour les anglophones.

Tutoriaux Adobe Flash Collaborative Services

Le site Flex tutorial a mis en ligne une série d’articles sur l’utilisation d’Adobe Flash Collaborative Services (AFCS) anciennement appelé Cocomo, permettant de s’adonner aux joies des outils collaboratifs. On y retrouve toutes les informations utiles permettant de construire son application basée sur ce service, et ainsi gagné un temps loin d’être négligeable lorsque l’on doit mettre en place ce type de structure.

A consulter de toute urgence sur ce lien

Contourner l’erreur de parse des && dans le mxml

Voici une petite astuce d’écriture pour éviter de devoir inverser les conditions lorsqu’on les place dans du code mxml. En effet, Flex ne supporte pas que l’on ait les opérateur && dans du code mxml.

Le code : <mx:Label text= »matsiya » visible= »{condition1 && condition2} » /> devrait fonctionner dans la logique, puisque <mx:Label text= »matsiya » visible= »{condition1 || condition2} » /> fonctionne très bien, mais ce n’est pas le cas.

On pourrait certainement chercher pourquoi derrière il refuse cette compilation car le code mxml n’étant autre que du code as3, la raison doit se trouver là dedans. Néanmoins, ce problème d’écriture résulte souvent dans une prise de tête.

Pour le contourner, il suffit alors d’écrire sous la forme suivante :

<mx:Label text= »matsiya » visible= »{(int(condition1)*int(condition2))==1} » />

Cela rend le code un peu moins lisible, mais est terriblement efficace.

Zend AMF et socket UNIX

Dans la plupart des tutoriaux présents sur le net Zend AMF est utilisé pour un nombre très restreint de services et de classes. Les performances pour des petits projets restent acceptables cependant pour des projets nécessitant le chargement de beaucoup de VOs et de services les temps de réponse chutent considérablement. Ceci est tout simplement du au fait qu’à chaque requête le framework refait l’introspection des services et réimporte toutes les class.

Pour remédier à ce problème, nous avons modifié Zend AMF afin qu’il soit derrière une socket UNIX, Flex se connecte donc au enpoint qui va envoyer la requête à la class Server de Zend à travers la socket. Le endpoint attend une réponse du Server et affiche le résultat. Il n’y a donc plus d’introspection, une seule et même instance de l’AMF Server est utilisée.
Grâce à cette technique nous avons réussi à obtenir des gains de performance allant de 2000 à 3500 % , les temps de réponse sur des gros projets pouvant être divisés par plus de 30. (17 millisecondes en local pour récupérer 300 enregistrements dans un projet qui compte une trentaine de class). Des temps inférieurs à ceux qu’on enregistre avec BlazeDS et largement inférieurs à ceux enregistrés avec AMFPHP !!

On utilise déjà cette solution sur plusieurs projets et le gain côté utilisateur est assez bluffant. Bien évidemment cette solution ne fonctionne pas sur les serveurs mutualisés mais on trouve aujourd’hui des serveurs virtualisés très bon marché.