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

3jan/120

Les vidéos de Back From MAX Paris sont en ligne

Le 27 Octobre dernier, avait eu lieu le Back From MAX organisé par Adobe à Paris:

Adobe Back from MAX Paris le 27 Octobre 2011

A la suite des présentations de la journée, ont eu lieu les "Lightning talks", ces mini-présentations de 10 minutes (en théorie :P ). A cette occasion, 5 participants ont pu donner leur retour d'expérience sur le développement d'application AIR Mobile.

C'est d'ailleurs à cette occasion que j'ai pu découvrir l'application Pocket Agile dont vous avez peut-être entendu parler sur flex-tutorial:

Pocket Agile – Une application AIR multi-plateforme connectée au cloud

J'ai aussi présenté une des applications que j'ai développé chez Business Geografic, avec quelques explications sur le mode déconnecté.

Toutes les vidéos sont sur le site de BAAO, vous n'avez qu'à vous servir :) :

http://baao.com/bfm/

17déc/110

Flex given to the Apache Software Foundation – round-up and opportunities

This post is the 1002nd published on flex-tutorial.fr since January 2008, and it is especially important because it addresses the future of the evolution of Flex. The 1000th article was actually this same article but in French. Due to popular  demand and Twitter RTs, I decided to translate it into English, adding a few things I missed when writing the original article

Flex Community Summit

Last week, I was invited  by Adobe to spend 2 days at their offices in San Francisco for a rather special Flex Community Summit. 2 days of presentations / lectures on the following points:

  • Clarify the message given by Adobe
  • Explain the consequences of the Flex project being given to Apache
  • Explain how the Apache Software Foundation and their hosted projects actually work
  • Bring the community together to get its feedback and participate in open discussions

The latest announcements made by Adobe were quite rushed and often clumsy. It must be said that the change of strategy was a surprise to many, given that it was made after Adobe MAX (October). It is too late to change this, and Adobe has even apologised for its poor communication. So, we must now forget about it and think about the future of Flex.

Apache Software Foundation

Although the presentation was not particularly exciting, it was interesting to see how the Apache SF and the projects it hosts actually work. The presentation was provided by a member of the board of the ASF, Roy T. Fielding , who is one of the authors of the specification HTTP / REST, no less.

The ASF is a non-profit association which hosts projects licensed under the Apache licence. The most famous of these projects is the Apache HTTP Server, one of the most popular softwares in the business. There are many others, with 97 other projects, including Apache Maven, Ant, Tomcat, OpenOffice, Lucene, Subversion, … I'm just listing the "official" projects because Apache projects have 2 states: incubation and accepted.

For Flex, it will of course begin with the incubation period. For this to happen, Adobe will send a proposal (a document that we saw earlier in the week) to the Apache mailing list which will be considered by the board. Apache will acknowlege this proposal within 72 hours and decide whether the project is accepted into the incubation process or not. This step should not be a problem, Adobe is one of the largest contributors to the Apache Foundation and recently had PhoneGap accepted by the Apache Foundation.

During this incubation period, the organisation of the project must be proven and shown to be ready. If all goes well, the project can come out of the incubator and become a "real" Apache project. This may take several weeks to one year.

The roles within the ASF – Committers & contributors

The ASF is organised quite differently to how you may expect. The organisation of the board is almost exclusively done through the mailing list, no meetings. Within the projects themselves, it is the same, there is no hierarchy as such, no president, no manager, etc.. You can find more information on the operation of the Apache Software Foundation on this page:

Apache Software Foundation – How it Works

Everything is done on the basis of "meritocracy". Put simply, the more you do for the project, the higher your rank is.

If you are involved in the project, you have the role of "contributor". This means that you are active on the mailing list, you have submitted patches or written documentation, for instance.

Then you have special contributors called "committers". These people have  write access to the versioning system of projects (SVN).

Then we can find members of the "PMC" which are "contributors" or "commiters" entitled to vote for decisions taken by the community.

Open governance

The voting system is very important in the projects of the ASF, and work in a very simple manner. Each voter can give a +1, 0 (neutral) or a -1. The decision is then made based on the score of the vote, and the negative votes must be justified.

An important point to note is that the projects of the ASF are composed of individuals, not groups or businesses. Some members of the Apache Flex project will be Adobe employees, but they will not have more importance than the others, everything will be based on the votes of individuals.

Here Adobe loses control of the governance of Flex, and therefore the direction the project takes. The community members of the ASF will decide. And this changes many things, including the fact that strategic decisions from Adobe will no longer influence the project.

Great, then what is the roadmap?

One issue that was raised at the Summit was to know what the roadmap for the next Apache Flex would be. And in fact, there is no roadmap, but it's not a problem. This is the "design" for any Apache project.

In an Apache project, there is no manager who will dictate where the project is moving, everything depends on individuals. The evolution of the Apache project Flex is in fact directly dependent on the contributions made by its members. Basically, if a "contributor" wants to do something in the project, he will submit a patch and start a thread on the mailing list. If the contribution seems interesting, it will be included in the source code of the project.

Nobody is going to tell a member of the project to work on a specific feature. The feature itself may be discussed on the mailing list but governance is open, so there is no instruction.

There is no public roadmap itself. This may seem strange at first, but that is how the ASF works. In the end, I think it's a very good system.

8déc/115

Flex 5 most wanted features – Polls and results

A couple of days ago, I put together an online meeting (using Adobe Connect) with French developers about the future of Flex. This meeting wasn't about Flex being dead or not, or complaining about Adobe decisions. Instead, we tried to think of features that would make Flex even better than it is today.

There were 4 main points of focus:

  • Improving the industrialisation of Flex projects (eg. better integration with Maven or with other piece of software which we find in our business, such as Sonar, …)
  • Improving the efficiency of Flex developers (eg. missing components, …)
  • Improving the integration of Flex applications within their environment (cross-domain restrictions, full screen mode, AutoFill on forms, keyboard shortcuts, embedded WebKit, …)
  • Giving Flex exclusive features (file access, SQLite + WebKit within Flash Player, …)

Around 80 developers (exclusively from France) participated in this Connect session. We started with two polls, then everyone could suggest features they wanted to see as part of the future of Flex for about 1 hour. We ended up with about 40 features and then everyone had around 30 minutes to vote for the features they liked the most.

Since this is quite important, I decided to share the results and translate them into English. Maybe it will give some ideas to other community leaders outside of France :) .

If you can read French, here are the results. If not, keep reading ;) .

Poll results

Here are the results for the first 2 polls. The number of votes is given in brackets.

Would the FalconJS compiler (Flex -> HTML5) be suited to your projects?

  • (26) – Yes, if it performs well
  • (10) – No, I don't like cross-compilers, I prefer writing my own HTML5 content
  • (7) – No, I have some features which are impossible to create without Flash Player
  • (1) – My customer is not asking for a migration / can't migrate

Are you (or your company) willing to participate in the Spoon project?

  • (16) – Yes, depending on the time I can spend on it
  • (9) – No, I will wait and see how Spoon works out before I make any decision
  • (4) – Yes, active participation
  • (4) – No, but I want to use the new features of the framework
  • (2) – No, I'm moving away from Flex

Most wanted features

Here are the most wanted features for Flex 5 in general, so this also includes AIR and Flash Player because both are linked to Flex:

  • (27) – Improve the language (private constructors, operator overloading, generics, metatags, enums, abstract classes, introspection, …) so that ActionScript becomes the same level as Java
  • (26) – Finish the Spark component set (Tree, Charts, …)
  • (23) – Improve the AIR Mobile Simulator ADT (resolutions, screen density, …)
  • (22) – Advanced debugging tools (follow event propagation, reverse debugging, …)
  • (21) – HTML content integration, also on mobile (iFrame component, htmlText properties, …)
  • (20) – Reduce tight coupled classes within the SDK using more interfaces
  • (20) – Improve the Spark components (selectable Label, Autocomplete, …)
  • (20) – Improve debugging on mobile (debug player + errors from ANEs)
  • (19) – Native PDF display
  • (19) – Ability to embed a web browser (such as WebKit used in AIR) also in Flash Player
  • (18) – SQLite access within Flash Player
  • (17) – Official Maven integration of flex-mojos (archetype, …)
  • (17) – Be more flexible with security rules (x-domain, keyboard in full screen mode, …)
  • (15) – Printing
  • (15) – Integration with the history / password manager of the browser
  • (15) – Render components with the GPU
  • (14) – Support ANE development in tooling
  • (14) – Enhance StageWebView for better JS / communication
  • (14) – Resuscitate code quality tools such as Flex CPD, Flex PMD, and improve Sonar integration
  • (14) – Better and asynchronous JPEGEncoder/PNGEncoder within the SDK (using Alchemy)
  • (13) – Removing the MX components + changing some packages such as "core"
  • (13) – A sharing system similar to the AppStore for components with 3 levels of integration (Unstable / Stable / Official)
  • (13) – Code obfuscator
  • (12) – Replace the Tween class (too slow)
  • (12) – Customisation of the right click contextual menu
  • (11) – Facilitate AIR applications update when compiled with Captive Runtime
  • (11) – SEO
  • (10) – Metatag checking at compile-time
  • (10) – Allow users to contribute the framework using Git
  • (9) – Remove compiler integrations (ADL and such) from Flash Builder for a better integration within other IDEs
  • (9) – A way to make it easier to play sound within RIA applications
  • (8) – Stop using the bloated UIComponent class
  • (8) – Allow one-click technology stacks such as Spring/Hibernate on Tomcat ; EJB3/Hibernate on JBoss ; Spring/Hibernate on Tomcat  or Jetty
  • (8) – Solve the rendering issues when embedding fonts in an AIR Desktop application
  • (7) – Better integration with GraniteDS
  • (7) – Fusion of GraniteDS and BlazeDS + RTMP support
  • (7) – BlazeDS enhancements : BigInteger and BigDecimal out of the box
  • (6) – Better ASDoc support : compile-time variables, allow ASDoc generation of some parts of the project
  • (4) – BlazeDS enhancement : Using non-blocking NIO for messaging scalability

Quick analysis of the results

The results of this session are quite clear. A participant actually summed it up pretty well in one of the comments made on the French article.

There are 2 main topics that stand out:

  • A better IDE (= better productivity). Flash Builder isn't good enough for a consistent project (compile time, design view, …). A more complete language to make our life easier.
  • Opening Flex to other web technologies. Being able to communicate and integrate HTML5 content with your Flex project will be key. A good example is Google deprecating the AS3 Google Maps API in favor of the JS one. A better HTML integration/communication within Flex projects would allow us to use the JS API without any issue.

If you are interested in the future of Flex development, I suggest you do the same kind of exercise, it's always very informative (and if you need a Connect room, contact me at fnicollet@gmail.com).

Adobe have invited myself and a few others to San Francisco in a few days time to discuss where Flex is headed. If you want Spoon to be a success, the time is now :)

7déc/1112

Concertation Flex 5 – Bilan et résultats

Il y a quelques jours, je vous annonçais l'organisation d'une rencontre entre développeurs FR pour imaginer la roadmap de la prochaine version de Flex:

Concertation Flex 5 – Partagez vos idées sur l'évolution du framework Flex

Chose promise, chose due, cette concertation a bien eu lieu cette après-midi. Ce billet va présenter les résultats des différents sondages réalisés pendant cette session ainsi que la liste des fonctionnalités que les développeurs demandent. Bien sûr, cela ne veut pas dire que ces éléments seront intégrés dans la roadmap, mais cela permet de doser le ressenti des développeurs sur les éléments manquants à Flex.

Avant de dévoiler les résultats, je tiens à remercier tous ceux qui ont participé à cette réunion (en cumulé, on a du atteindre les 80 participants).

Je vais mettre les résultats par ordre décroissant de votes. Le nombre entre parenthèses représente le nombre de votes.

Le compilateur FalconJS (Flex->HTML5) conviendrait-il à vos projets?

  • (26) – Oui (sous réserve de bonnes performances)
  • (10) – Non, je n'aime pas les cross-compiler, je préfère écrire mon contenu HTML5
  • (7) – Non, j'ai des fonctionnalités impossibles à réaliser sans Flash Player
  • (1) – Mon client ne me demande pas de migration / ne peut pas migrer

Comptez-vous (ou votre entreprise) participer au projet Spoon?

  • (16) – Oui, en fonction du temps disponible
  • (9) – Non, je continue flex j'attends de voir le travail de spoon avant de me décider
  • (4) – Oui, participation active
  • (4) – Non, mais je veux profiter des nouveautés du framework
  • (2) – Non, je souhaite m'écarter de Flex.

Viennent ensuite les fonctionnalités attendues par les développeurs. Ces derniers ont d'abord tous donné les fonctionnalités qu'ils souhaitaient voir (en vrac). Celles-ci ont été consignées dans une liste de 40 points différents. Au bout d'une grosse heure de discussions, les participants ont pu voter (sans voir les résultats) pour une ou plusieurs fonctionnalités.

Fonctionnalités les plus demandées

  • (27) – Amélioration du langage (constructeurs privés, surcharge d'opérateurs, generics, metatags, enums, classes abstraites, introspection) pour venir au même niveau que Java
  • (26) – Terminer la "sparkisation" de tous les composants (Tree, Charts,…)
  • (23) – Amélioration du simulateur pour AIR mobile (résolutions, …)
  • (22) – Outils de debug avancés (pouvoir suivre les propagations des évènements par ex.)
  • (21) – Gestion du contenu HTML (y compris sur mobile)
  • (20) – Réduire le couplage fort du code du SDK en utilisant davantage d'interfaces
  • (20) – Amélioration des composants Spark (Label selectable, Autocomplete, …)
  • (20) – Amélioration du debug sur mobile ( player debug + erreurs ANEs)
  • (19) – Affichage natif des PDFs
  • (19) – Possibilité d'embarquer un navigateur (type Webkit pour AIR) aussi en web dans Flash Player
  • (18) – SQLite en web, pas que dans AIR
  • (17) – Intégration officielle de maven (archetypes & co)
  • (17) – Réduire la taille des swc du framework
  • (17) – Etre plus souple avec des règles de securité incompréhensibles (cross domain, clavier en full screen, etc.)
  • (15) – Impression
  • (15) – Intégration avec les gestionnaires d'historique / mot de passe navigateur
  • (15) – Faire le rendu graphique des composants en passant par le GPU
  • (14) – Support du développement des ANEs
  • (14) – Améliorer StageWebView pour communication avec JS / DOM + SWV Desktop
  • (14)  - Réanimation des outils orientés qualité: Flex CPD, FlexPMD, et améliorer l'intégration à Sonar
  • (14) – JPEGEncoder et PNGEncoder du SDK plus rapides (Alchemy) et asynchrones
  • (13) – Suppression des composants MX + modification des packages trop communs comme core.
  • (13) – Un système de création et de partage de composants à la sauce App Store avec 3 niveaux progressifs: 1) Instable: proposé à la communauté et rapidement testé 2) Stable: Validé par plein de développeurs qui l'ont utilisé en prod 3) Officiel: intégré dans le framework Flex
  • (13) – Outil d'obfuscation du code
  • (12) – Remplacer la classe Tween fournie par Adobe car trop lente)
  • (12) – Personnalisation du menu contextuel en click droit (FP 11.x)
  • (11) – Faciliter l'updating des applications AIR compilée avec Captive Runtime
  • (11) – Référencement
  • (10) – Contrôle des metatag à la compilation (par exemple: un Bindable dans une interface peut ne pas être Bindable dans l'implémentation, idem pour les [Event] dont le compilateur ne contrôle pas l'existence d'un dispatch ===> les interfaces gagneraient encore plus en intérêt)
  • (10) – Permettre la contribution au Framework via Git
  • (9) – Sortir les intégrations des compilateurs (ADL et autres) de FB, dans une appli externe (pour une meilleur intégration du SDK dans d'autre IDE)
  • (9) – Gestion du son dans les applications
  • (8) – Réduire les dépendances vers UIComponent à 0
  • (8) – Permettre des installations automatiques (one click) de technologies stacks en local, genre (Spring/Hibernate on Tomcat ; EJB3/Hibernate on JBoss ; Spring/Hibernate on Tomcat  or Jetty )
  • (8) – Régler le problème de différence de rendu des polices embedded dans une application AIR Desktop, selon les plate-formes
  • (7) – Envisager une meilleure intégration de GraniteDS
  • (7) – Fusion des projet GraniteDS et BlazeDS + support du RTMP
  • (7) – Améliorations BlazeDS : gestion de types BigInteger et BigDecimal de base.
  • (6) – ASDoc: Support des variables de compilations + possibilité de générer seulement une partie (celle qui fonctionne)
  • (4) – Améliorations BlazeDS : intégrer d'emblée le non-blocking NIO de manière à permettre la scalabilité du messaging

Analyse rapide des résultats

Il est intéressant de voir que la fonctionnalité la plus votée est une amélioration du langage ActionScript 3 sur lequel repose Flex. La plupart des développeurs Flex ont de l'expérience dans d'autres domaines / langages (Java, le plus souvent) et souhaitent arriver aux mêmes possibilités syntaxiques. Cela peut aussi permettre aux frameworks d'injection de dépendance de devenir plus puissants et de mieux s'intégrer avec le code (metatags compilés, introspection, …).

Pour le reste, je crois que les fonctionnalités parlent d'elles-même. Pour n'importe quel développeur Flex, le Top 10 peut améliorer sa productivité et la qualité de son code.

Encore une fois, merci à tous les participants d'avoir donné un peu de leur temps !

Comme je l'avais annoncé dans mon billet précédent, je serai à San Francisco la semaine prochaine chez Adobe pour discuter de la roadmap de Flex. Votre parole sera donc entendue :)

3déc/112

AIR Mobile – Modifier la classe NavigationStack pour effectuer un "popToView"

Difficile de trouver un bon titre pour cet article :) . On va voir ici un "petit hack" qui peut vous rendre bien des services dans certains cas. Cela va en fait simplifier votre code lorsque vous avez une grosse utilisation des pushView, popView etc. pour naviguer dans votre pile de vues.

J'avais en fait déjà parlé de ce problème dans un article (avec une référence à Justin Beiber que *personne* n'a remarqué):

AIR Mobile – Le cycle de vie des View (destructionPolicy, viewActivate, …)

Le problème avec destructionPolicy="never"

Je vous répète donc le problème:

Pour reprendre l'expression de notre ami chevelu, il ne faut jamais dire jamais. En effet, même si votre vue a une "destructionPolicy" fixée à "never", dans certains cas, la vue va être recrée.

Dans mon application, par exemple, j'ai les vues suivantes:

  • Map
  • Recherche
  • Resultats
  • Fiche Info

Si l'utilisateur fait le cheminement suivant:

Map > Search > BACK (popView) > Map

Parfait, notre vue Map n'a pas été détruite et on a bien pu la récupérer. Prenons maintenant le cheminement suivant, en réalisant un "pushView" à chaque étape:

Map > Search > Result > Info Sheet > Map

Et bien dans ce cas, le ViewNavigator va créer une nouvelle vue Map. Pour résumer, lorsque vous faîtes appel à pushView, même si vous lui donnez une Class qui a déjà été instanciée auparavant, ViewNavigator va créer une nouvelle vue et peu importe la destructionPolicy de celle-ci.

Il faut noter que le cheminement suivant ne détruit pas la vue:

Map > Search > Result > Info Sheet > popView();popView();popView(); > Map

Mais ce n'est pas une vraie solution.

Modifier le comportement interne du SDK Flex

Je ne le dirai jamais assez mais le truc excellent avec Flex, c'est que vous pouvez aller voir les sources pour voir comment le SDK fonctionne, et cela depuis toujours. En parcourant un peu le SDK, vous allez découvrir que l'implémentation de pushView se situe dans la classe spark.components.supportClasses.NavigationStack:

    /**
     *  Adds a view to the top of the navigation stack.
     *  Pushing a view changes the display of the application to
     *  the new view on the stack.
     *
     *  @param viewClass The class of the View to create.
     *
     *  @param data The data object to pass to the view when it is created.
     *  The new view accesses this Object by using
     *  the <code>View.data</code> property.
     *
     *  @param context The context identifier to pass to the view when
     *  it is created.
     *
     *  @return The data structure that represents the current view.
     *
     *  @langversion 3.0
     *  @playerversion Flash 10
     *  @playerversion AIR 2.5
     *  @productversion Flex 4.5
     */
    public function pushView(viewClass:Class, data:Object, context:Object = null):ViewDescriptor
    {
        var viewData:ViewDescriptor = new ViewDescriptor(viewClass, data, context);
        _source.push(viewData);

        return viewData;
    }

Code plutôt simple, sans aucune réutilisation. Pour résoudre notre problème, il faut en fait aller récupérer la vue qui se situe dans la pile courante et la renvoyer. Vous pouvez faire cela de plusieurs manières, cela va dépendre de votre code métier que vous voulez obtenir. Vous pouvez par exemple passer dans la variable "context" (un peu fourre-tout), si la vue doit être ré-utilisée ou non.

Voici une version simple permettant de réutiliser la classe si elle se trouve dans la pile:

package spark.components.supportClasses
{
  import mx.core.mx_internal;

  use namespace mx_internal;

  /**
  *  The NavigationStack class is a data structure that is internally used by
  *  ViewNavigator to track the current set of views that are being managed
  *  by the navigator.
  *
  *  @see spark.components.ViewNavigator
  *
  *  @langversion 3.0
  *  @playerversion Flash 10
  *  @playerversion AIR 2.5
  *  @productversion Flex 4.5
  */
  public class MyNavigationStack extends NavigationStack
  {

    //--------------------------------------------------------------------------
    //
    //  Constructor
    //
    //--------------------------------------------------------------------------

    /**
    *  Constructor.
    *
    *  @langversion 3.0
    *  @playerversion Flash 10
    *  @playerversion AIR 2.5
    *  @productversion Flex 4.5
    */
    public function MyNavigationStack(){
      super();
    }
    /**
    * Returns the index of the view if it already exists or -1 if not.
    * */
    public function hasView(viewClass:Class):int{
      for (var i:int;i<source.length;i++) {
        if (ViewDescriptor(source[i]).instance is viewClass) {
          return i;
        }
      }

      return -1;
    }

    /**
    * Returns the first instance of the view of the class specified or null if no instance is found
    * */
    public function getViewDescriptor(viewClass:Class):ViewDescriptor{
      for each (var viewDescriptor:ViewDescriptor in source) {
        if (viewDescriptor.instance is viewClass) {
          return viewDescriptor;
        }
      }
      return null;
    }

    /**
    * Same as pushView but adds reuseExistingInstance to pop to the view of the viewClass already exists
    * */
    override public function pushView(viewClass:Class, data:Object, context:Object = null):ViewDescriptor
    {
      var reuseExistingInstance:Boolean = true;
      var viewData:ViewDescriptor;
      var index:int = reuseExistingInstance ?  hasView(viewClass) : -1;

      if (reuseExistingInstance && index!=-1) {
        viewData = getViewDescriptor(viewClass);
        source.length = index + 1;
      }
      else {
        viewData = new ViewDescriptor(viewClass, data, context);
        source.push(viewData);
      }

      return viewData;

    }
  }
}

Le code est simple. Si on trouve une vue du même type dans la pile, on la renvoie. L'assignation suivante:

source.length = index + 1;

Est une manière simple (et rapide) de dépiler un tableau en AS3 jusqu'à une certaine longueur. Comme si on avait fait des pop() successifs.

Utilisation de la classe MyNavigationStack pour remplacer NavigationStack

Vous avez donc votre classe mais pour l'instant, elle n'est pas utilisée. Pour cela, il faut attendre l'évènement "applicationComplete" et réaliser l'assignation suivante:

import mx.core.mx_internal;
private function onAppComplete():void {
  navigator.mx_internal::navigationStack = new MyNavigationStack;
  ...
}

Vous pourrez ensuite réaliser des pushView() qui vont aller récupérer une vue existante dans la pile si possible et ainsi sauver des ressources.

Voilà, un petit hack bien pratique !

Remplis sous: Adobe Air 2 Commentaires