Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

31août/092

Flex 4 – Différences entre Flex 3 et Flex 4 (2-Nouvelle architecture Flex 4)

Traduction de l'article Differences between Flex 3 and Flex 4 beta de Joan Lafferty.

Un des principaux aspects de Flex 4 et le workflow entre designers et développeurs. Pour cela, le framework apporte une séparation claire entre le visuel et le comportement d'un composant. Dans Flex 3, le code d'un composant comprenait son comportement, sa mise en page et ses changements visuels. Dans Flex 4, les composants sont séparés en différentes classes, chacune traitant d'un comportement spécifique.

Une nouvelle architecture autour du FXG

Comme spécifié dans le document officiel Gumbo Architecture Document:

La classe principale du composants, celle dont le nom correspond au tag MXML du composant, encapsule le comportement principal du composant. Cela comprend la définition des évènements propagés par le composant, la donnée que le composant représente, la liaison avec des sous-composants, la gestion et le suivi de l'état interne du composant.

On couple avec cette classe de composant, une classe de skin qui gère tout ce qui est lié à l'apparence visuelle du composant dont les éléments graphiques, la mise en page, la représentation de la data, le changement d'apparence entre les différents States et les transitions entre ces State. Dans le modèle Halo, les skins Flex étaient des éléments graphiques responsable seulement de l'aspect graphique du composant. Changer n'importe quel autre aspect de l'apparence d'un composant, comme la mise en page ou la visualisation des states obligeait à créer une sous-classe du composant et à éditer le code ActionScript directement. Dans le modèle Gumbo, tout cela est définit déclarativement dans une classe de skin, principalement à l'aide des tags graphiques FXG.

Voir les spécifications du format FXG 1.0

Pour illustrer cette nouvelle architecture, on va regarder le code de la classe spark.components.Button. Cette classe ne contient que la logique du comportement du bouton. Tous ce qui concerne le visuel du composant est défini dans la classe spark.skins.default.ButtonSkin.

Pour des raisons de performance, Flex 4 donne aux développeurs des briques qu'ils peuvent utiliser pour construire la fonctionnalité dont ils ont besoin. Des fonctionnalités lourdes telles que le scroll ou la virtualisation qui ne sont pas nécessaires à toutes les applications ne sont pas appliquées par défaut.

Namespaces et packages dans Flex 4

Les classes de Flex 4 sont dans les mêmes packages mx.*. Flex 4 introduit le package spark.* pour les composants et les classes de base, effects, filters, layouts, primitives, skins et utils.

Flex 4 apporte un nouvel ensemble de composants et d'effets ayant le même nom que ceux de Flex 3. Pour éviter les conflits MXML, Flex 4 comprend 4 namespaces différents: MXML 2006, MXML 2009, Spark et Halo.

Remplis sous: CSS, Exemple, Flex 4 Lire la suite
31août/090

Flex 4 – Différences entre Flex 3 et Flex 4 (1-Migration vers Flex 4)

Traduction de l'article Differences between Flex 3 and Flex 4 beta de Joan Lafferty.

Flex 4 (nom de code Gumbo) représente un changement majeur par rapport à Flex 3. Flex 4 introduit en effet une nouvelle architecture de composants et de skinning. En tant que développeur Flex 3, vous ne devriez cependant par rencontrer trop de difficultés pour compiler vos applications Flex 3 avec le SDK Flex 4, car la compatibilité descendante (backwards compatibility) avec Flex 3 est conservée.

Dans cette série d'articles, je vais donner d'ensemble des objectifs principaux de Flex 4, des différences d'architecture ainsi qu'une introduction aux changements de composants, de mise en pages mais aussi l'utilisation des States et des effets. On verra aussi comment compiler votre application Flex 3 avec le SDK Flex 4. Cet article ne couvre pas les nouvelles fonctionnalités de Flex 4.

Tout au long de cette série d'articles, le terme de "Composants Halo"  réfère aux composants inclus dans Flex 3. Le terme "Composants Spark" réfère au nouvel ensemble de composant de Flex 4.

Migration d'applications vers Flex 4

Pour une migration d'application Flex 3 vers Flex 4, vous n'aurez que peu de choses à modifier. A part quelques résolutions de bugs et un changement du thème par défaut, attendez-vous à ce que votre application fonctionne de la même manière (voire mieux) qu'elle le faisait en Flex 3. Cependant, voici quelques points sur lequels vous devriez être attentifs.

Dépendance à Flash Player 10

Compilez bien pour Flash Player 10. Flex 4 impose la compilation en FP10.

Les Type Selector (style) ont besoin d'un namespace

Un type selector CSS lie une classe Flex à un style. Par exemple, les sélecteurs CSS suivant agissent sur Button et DateField:

Button {
    cornerRadius: 10;
}
DateField {
   color: #780800;
}

Dans Flex 4, quand une application utilise des Type Selector, un namespace est requis. Si vous utilisez uniquement le namespace MXML 2006 dans votre application Flex, ajouter la déclaration de namespace par défaut à votre CSS:

<mx:Style>

@namespace "http://www.adobe.com/2006/mxml";
…
</mx:Style>

Si vous utilisez plusieurs namespaces dans votre application, vous devrez les indiquer dans votre CSS (voir plus loin).

De plus, si votre application utilise une méthode comme StyleManager.getStyleDeclaration("Button"), le type selector devra inclure le package. Par exemple, l'appel à getStyleDeclaration() deviendrait StyleManager.getStyleDeclaration("mx.controls.Button")

Changement de theme

Le theme par défaut des composant Flex 3 (Halo) est maintenant le theme Spark. C'est pourquoi le look et les tailles de votre application pourraient être différent en utilisant Flex 3. Si vous voulez tout de même utiliser le look Flex 3, vous le pouvez car Flex 4 inclut toujours le thème  Halo de Flex 3. Pour compiler en utilisant le thème Halo, utilise le flag -compatibility-version=3.0 dans les arguments du compilateur ou bien le flag -theme. Pour cela, dans Flash Builder 4, vous devez modifier le paramètre Additional Compiler Arguments dans la section Flex Compiler du panel de propriétés. Si vous utilisez ces arguments, assurez vous que le répertoire framework/themes/Halo est bien dans votre Source Path.

30août/090

[Offre d'emploi/stage de fin d'études] – Développeur Flash AS3 / FLEX sur Paris

Développeur Flash AS3 / FLEX sur Paris en Stage de fin d'études / CDD / CDI sur Paris (17e) (Offre d'emploi/stage de fin d'études)

  • Titre: Développeur Flash AS3 / FLEX
  • L'entreprise: NEXT RIALITY (site web),Vous recherchez une société innovante et fortement orientée vers les nouvelles technologies ?
    Alors rejoignez NEXT RIALITY pour partager nos convictions telles que la confiance, la transparence, la convivialité et la proximité.
    Fort de notre expertise en développement de RIA (technologies Flash, Flex, Actionscript3), NEXT RIALITY souhaite renforcer son équipe de développeurs.

Profil Recherché

  • Profil recherché: Nous recherchons un développeur Flash AS3 / FLEX, passionné par le développement d'applications nouvelle génération, inventif, curieux et habité par l'esprit startup.
    Des compétences en design, programmation 3D, PHP, MySQL ou JAVA sont un plus.
    Vos taches se situent à la fois dans la production et la R&D, que ce soit pour le compte de nos clients ou pour des projets internes.

    Vos missions:

    • Réalisation d'applications B2B/B2C en AS3 sous Flash CS3/4 ou FLEX
    • Développement de frameworks ou d'API
    • Veille technologique, R&D et innovation
  • Compétences Techniques Requises: Actionscript 3, FLEX BUILDER, Flash, PHP, MySQL, JAVA, programmation 3D (Papervision 3D, Sandy…), programmation réseau (FMS, Cocomo, Red5, BlazeDS…)Au-delà de votre formation, c'est votre goût pour le développement en général qui nous intéresse. Vous justifiez au minimum d'une première expérience (stage significatif de 6 mois minimum en développement Flash/AS3/FLEX/AIR).
    Anglais technique demandé

    • Passion pour le développement d'applications web (Présentez-nous vos travaux professionnels et personnels !)
    • Esprit innovant, autonome
    • Aptitude à travailler en équipe
  • Expérience Requise: -
  • Formation: -
  • Disponibilité: ASAP

Conditions d'embauche

  • Affectation: Paris
  • Rémunération: Entre 30 K€ et 40 K€ brut annuel en fonction du profil
  • Contrat: Stage de fin d'études / CDD / CDI

Pour postuler

  • Contact: Contacter Alexandre Delbarre à adelbarre (AT) nextriality (POINT) com
29août/0923

Flex Best Practices – MVC (Model View Controller) par l'exemple

Dans le petit monde de Flex, on entend très souvent parler du modèle MVC alias Model View Controller. Plutôt que de rester dans la théorie, le blog unitedmindset propose de montrer MVC par l'exemple, en voici une traduction. Au départ, on a un code qui est écrit "en vrac" et on va le transformer pour qu'il soit cohérent avec le modèle MVC.

MVC en quelques mots…

D'autres articles en parlent mieux, mais en quelque mots, le modèle MVC est une "best practice" (bonne pratique) permettant de coder plus facilement, de ne pas dupliquer son code et de le rendre facilement réutilisable. MVC est un concept simple pour simplifier le développement. Le concept et de séparer dans son application le model (la donnée), la view (ce que l'on voit) et le controller (les méthodes et les fonctions qui font la liaison entre la vue et le model, et inversement).

Code d'exemple non-MVC (Worst practice)

Voici un exemple de code (Flex 4) qui est mauvais car totalement rigide. Si vous codez de cette manière, prenez bien le temps de lire cet article:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/halo"
    creationComplete="application1_creationCompleteHandler(event)">
    <fx:Script>
        <![CDATA[
            import mx.controls.Alert;
            import mx.rpc.events.FaultEvent;
            import mx.rpc.events.ResultEvent;
            import mx.collections.ArrayCollection;
            import mx.events.FlexEvent;

            [Bindable]
            private var searchList:ArrayCollection = new ArrayCollection();

            protected function application1_creationCompleteHandler(event:FlexEvent):void
            {
                runSearch();
            }

            private function runSearch(event:MouseEvent=null):void
            {
                httpService.send({searchTerm:searchInput.text});
            }

            protected function httpService_resultHandler(event:ResultEvent):void
            {
                searchList = new ArrayCollection( event.result as Array);
            }

            protected function httpService_faultHandler(event:FaultEvent):void
            {
                searchList = new ArrayCollection();
                Alert.show("fault");
            }

        ]]>
    </fx:Script>
    <fx:Declarations>
        <mx:HTTPService id="httpService"
            result="httpService_resultHandler(event)"
            fault="httpService_faultHandler(event)"
            resultFormat="e4x"
            url="http://www.someUrl.com/yourMethod"/>
    </fx:Declarations>
    <s:layout>
        <s:VerticalLayout gap="20" paddingBottom="20" paddingLeft="20" paddingRight="20" paddingTop="20"/>
    </s:layout>
    <s:HGroup width="100%">
        <mx:Label text="Search Term"/>
        <s:TextInput width="100%" id="searchInput"/>
        <s:Button label="Do It!" click="runSearch(event)"/>
    </s:HGroup>
    <s:List width="100%" height="100%"/>
</s:Application>

Cet exemple est extrêmement simple et si c'est tout ce que votre application doit faire, alors vous pouvez laisser ce code comme tel. Si votre application est plus complexe (ou va le devenir), vous allez vite comprendre que cette manière de coder va vous poser problème. Vous aurez ainsi du mal à créer des tests unitaires, réutiliser le code ou bien implémenter les designs patterns OO tels que la Factory ou même les interfaces. Notre application MVC finale pourra faire ces choses là.

Comprendre le Model

Les Model sont les données de votre application et sont extrêmement simples. En ActionScript, lorsque vous créez des model, vous allez devoir utiliser des getters et des setters pour vos propriétés. Pourquoi? Parce que le Model contient la donnée et que le Model change, il propage des évènements pour alerter tout écouteur que le model à changé.

Model : Best Practices

Toutes les propriétés de votre model devraient avoir des getters et des setters. Votre classe Model doit aussi hériter de EventDispatcher pour pouvoir envoyer des évènements (Event) quand votre modèle est modifié. Vous verrez comment cela se passe plus loin dans l'exemple. Vous pouvez aussi utiliser des évènements personnalisés pour indiquer les changements à votre application. Dans cet exemple, on va utiliser simplement la classe Event. Il est aussi "Best practice" de vérifier que la propriété a bien changé avant de propager l'évènement et de mettre à jour la valeur. C'est très simple avec des String ou des Number mais c'est plus compliqué avec des objets complexes.

Création du Model (exemple)

Pour notre exemple, le model est extrêmement simple puisque l'on a une seule propriété, mais vous pouvez remarquer la simplicité du Model et la manière par laquelle il sépare et simplifie l'application. En effet, vous pourrez réutiliser ce model dans de multiple controllers.

package com.unitedmindset.models
{
    import flash.events.Event;
    import flash.events.EventDispatcher;
    import flash.events.IEventDispatcher;

    [Event(name="searchListChanged",type="flash.events.Event")]

    public class SampleModel extends EventDispatcher
    {
        public static const SEARCH_LIST_CHANGED:String = "searchListChanged";

        public function SampleModel(target:IEventDispatcher=null)
        {
            super(target);
        }

        private var _searchList:Array;

        public function get searchList():Array
        {
            return _searchList;
        }

        public function set searchList(v:Array):void
        {
            _searchList = v;
            dispatchEvent(new Event(SEARCH_LIST_CHANGED));
        }

    }
}

Comprendre le Controller

Un Controller n'est ni plus ni moins qu'une classe qui va contenir des méthodes pour gérer la data, mettre à jour et gérer la vue (View). En séparant votre code et en créant  des classes spécifiques, vous pourrez avoir des interfaces, des sous-classes, des tests unitaires sur chaque méthode et enfin utiliser la vue "Outline" d'Eclipse pour aller direct sur une méthode spécifique.

29août/090

Flex Data Visualisation maintenant en Open Source (datavisualization.swc)

Le framework Flex 3.4 SDK est maintenant disponible au téléchargement et corrige notamment des problèmes de cross-scripting.

Pour télécharger le dernier SDK Flex 3.4, c'est ici:

Télécharger le SDK Flex 3.4

Autre nouvelle intéressante, vous trouverez sur cette page les sources des composants faisant partie du Data Visualization 3.4 (Adobe Flex 3.4 Data Visualization Components for Flex Builder) comprenant notamment l'AdvancedDataGrid ou le Charting. Les sources AS sont donc disponibles avec la version 3.4 du SDK Flex, seul le SWC datavisualization.swc était disponible auparavant.

Data Visualization Open Source != Gratuit

Le framework Flex est, et reste, open source et gratuit d'utilisation. Seul le Builder (Flex Builder) est payant et existe en 2 versions, la version basique et la version professionnelle. La version professionnelle permet d'avoir accès aux composants de Data Visualization. Si vous n'avez pas la licence Flex Builder Pro, vos graphiques et vos AdvancedDataGrid auront un "watermark", c'est à dire un filigrane indiquant "Data Visualization Trial".

Sur le blog officiel Adobe, Matt Chotin précise l'état d'avancement des composants de Data Visualization et notamment la mise à jour de ces composants pour le futur framework Flex 4. Il écrit notamment:

we still consider these components to be under the Flex Builder license, and the source to be considered "Professional Component Source Files" as described in the Flex 3 SDK EULA. So I hope that clears up the licensing question

En clair, les sources sont disponibles pour aider les développeurs mais le système de licence ne change pas, vous devrez toujours avoir une licence Flex Builder Pro pour utiliser le datavisualization.swc.