Après avoir utilisé le framework Flex pendant une année au cours de mon stage d’ingénieur à Polytech’Nice Sophia (voir mon CV), je souhaite donner un peu mon avis sur cette technologie, ses avantages, ses inconvénients, points forts et faibles. Comme pour WebObjects, voici une petite description pour les personnes qui ne connaitraient pas Flex.

Adobe Flex est un framework de développement de clients riches (ou clients lourds) compilé vers la machine virtuelle Flash. Pour les personnes connaissant Silverlight, Flex a inspiré Microsoft pour sa création. Les interfaces sont réalisées à l’aide d’un langage basé sur XML, le MXML (XAML pour Silverlight) et le comportement est écrit à l’aide du langage Action Script 3 (.Net pour Silverlight).
Il ne surtout pas considérer Flex comme un outil fait pour les designeurs, c’est un framework créé pour les développeurs.

Déploiement

Comme dit dans l’introduction, Flex est compilé dans un fichier SWF qui est lu par la machine virtuelle Flash. Pour lire une application Flex, la version 9 du plug-in est au minimum nécessaire, or plus de 95% des personnes répondent à ce besoin. C’est un point assez fort du framework, surtout en comparaison avec Silverlight qui peine à passer les 30% (toutes versions confondues).
Étant donné que Flex se base sur le plug-in Flash, vous bénéficiez également d’une compatibilité entre les différents systèmes d’exploitation et les différents navigateurs. Pas de mal de tête à assurer le même rendu entre IE6 sur Windows et Safari sur Mac, c’est le travail des gens d’Adobe.
Pas de doute ici, c’est un gros point fort et un très bon travail d’Adobe qui donne à Flex un avantage certain sur ses concurrents directs. On pourra également remarquer sur l’utilisation de Flash la mise à disposition d’une excellente librairie pour créer des animations de l’interface qui donnent un cachet très professionnel aux applications.

ActionScript et API

Le comportement et le business d’une application Flex est décrit dans le langage ActionScript 3. Pour le langage en lui-même, il est souple et propose un certain nombre de fonctionnalités puissantes et pratiques, je citerais en exemple la possibilité d’appeler une méthode sur une variable à l’aide de l’opérateur [] comme suit: maVariable["maMethode"].
En revanche on peut vraiment reprocher à Adobe la pauvreté de l’API. Pour l’anecdote, sachez que la méthode addAll permettant d’ajouter tous les éléments d’un tableau dans un autre tableau vient d’être implémentée dans la version 3.4 du framework … Sachez également que la gestion de dictionnaire est extrêmement réduite, impossible par exemple de récupérer l’ensemble des clés d’un dictionnaire …
Il est certes possible d’écrire soit-même toutes ses classes, mais d’une part on n’a pas forcément envie de coder toutes les classes de base lorsque l’on s’attaque à un projet ambitieux et d’autre part, si Adobe comble le manque un jour il faudra faire le remplacement partout.

Modèle MVC

A première vue, Flex semble proposer une bonne architecture pour respecter le pattern Modèle-Vue-Contrôleur avec les interfaces et leur comportement décrites en MXML, des classes de comportement et des classes de modèle. Cependant en pratique, on a rapidement tendance à mélanger la vue et le contrôleur. En effet il est possible d’écrire de l’ActionScript dans le fichier MXML et la tentation est grande d’y écrire le code business de la vue.

Quelques framework tentent d’imposer de bonnes pratiques (je citerais Cairngorn et Tide) mais ils ne sont pas toujours simple à mettre en place. En pratique il devient également difficile de maintenir du code propre au sein d’un projet de grande envergure. Le projet peut être découpé en modules qui sont chargés à la demande, mais on arrive assez facilement à des dépendances inter-modules ou de la recopie de code pour effectuer la même action dans deux endroits différents mais inaccessibles entre eux.

Asynchronisme et thread unique

Le plug-in Flash est presque mono-threadé. Je dis presque car en réalité un deuxième thread existe, qui attend les réponses aux requêtes effectuées vers des adresses externes. De cette situation ressort deux choses.

Toute demande de données est asynchrone. La demande est déposée vers le thread de communication qui propagera un évènement lorsque celle-ci sera complétée. S’il n’est pas dérangeant que vos données arrivent de façon asynchrone, pas de soucis mais dans le cas où vous aimeriez attendre d’avoir concrètement les informations, vous allez commencer à rencontrer des difficultés.

Il est impossible d’effectuer deux actions à la fois, cela incluant le dessin de l’interface ou le traitement d’un clic souris. Par conséquent, si vous lancez un traitement lourd de calculs, l’interface sera figée. Avantage en contrepartie, vous n’avez pas du tout à vous préoccupé de problèmes de validité des données entres threads ou de deadlocks, cela est impossible !

Bindings

Il est possible dans les interfaces MXML de réaliser des « bindings » entre une variable ActionScript et une propriété d’un élément graphique. Une fois le binding mis en place, la modification de la valeur de la variable entrainera la modification de la valeur de la propriété de l’élément graphique. Cela est très pratique puisque le mécanisme permet de réaliser à vitesse grand V l’écran de visualisation d’un objet Business en « bindant » sur ses différents attributs.

Dans la version 3 de Flex quelques embuches appaissent pour mettre en place des double bindings, c’est à dire que les modifications de valeur s’effectuent dans les deux sens. En effet, le premier binding mis en place aura pour effet d’effacer la valeur d’une des deux variables avec la valeur de l’autre. Dans le cas d’un objet business et un objet graphique, il vaut mieux effacer la valeur de la propriété graphique avec celle de l’objet business et non pas le contraire … Ce petit problème a été corrigé dans Flex 4 qui sortira prochainement.

Flex est un outil

En conclusion de l’article et avant de tirer avantages et inconvénient, j’aimerais donner un avis très subjectif sur le framework. Flex un outil jeune mais toutefois puissant pour développer rapidement les applications pour lesquelles il a été créé. Et je vais insister sur ce point.

A mon idée, Flex est parfait pour des applications simples, avec peu de code business. La manière classique de travailler va être d’appeler un WebService ou une page Web, parser les résultats pour remplir des variables sur lesquelles l’interface est bindée. Le résultat sera obtenu rapidement, propre, et joliment animée.

En revanche, Flex n’est pas fait pour une lourde application avec de nombreuses implications de code business entre les écrans et des grappes d’objets à récupérer, modifier, renvoyer, etc. Pour avoir tenté d’utiliser le framework pour ce type d’application, je peux dire qu’on passe plus de temps à lutter contre Flex qu’à lutter contre les difficultés de l’application elle-même.

Comme beaucoup d’autres framework, Flex est un outil. Flex est un tournevis cruciforme. Si votre application est faite de vis cruciformes, ce sera un excellent outil et vous allez aboutir rapidement à un résultat de qualité. Si en revanche vous devez fabriquer une chaise avec des clous, vous êtes condamné à taper sur les clous avec le manche, et au final vos clous seront plantés de travers, votre chaise sera bancale et s’effondrera à la troisième personne qui tentera de s’assoir dessus et enfin vous vous serez fait mal à la main.

Mais assez parlé et voyons le bilan avantages/inconvénients

Avantages

• Compatibilité OS/Navigateur
• Plug-In flash très répandu (95%)
• Animations simple à utiliser et très classes
• Pas de problématique de programmation concurrente
• Mécanisme de binding très pratique

Inconvénients

• Inconvénients de Flash (vous devriez les trouver facilement sur d’autres sites)
• Pauvreté de l’API ActionScript
• Trop grande facilité de mélanger Vue et Contrôleur
• Impossibilité d’utiliser la programmation concurrente
• Obligation de récupérer les données de façon asynchrone
• Doubles bindings laborieux (résolu normalement dans Flex 4)

cv, flex, ingénieur, Programmation