Le projet Spoon cherche des volontaires
Les "anciens" du monde Flex s'en souviennent sûrement, en mars 2009 a eu lieu le Flex SDK Bug Quash. Le but de ce Bug Quash était d'aller voir les bugs de Flex rentrés dans le JIRA, effectuer un correctif puis proposer un patch. Il y avait même un système de point avec un ninja, c'était assez bien fait. A l'époque, le SDK Flex était très Open Source, dans le sens où vous aviez accès au /trunk officiel du SDK.
Depuis, la situation a évolué. Le framework Flex est toujours Open Source mais "moins" dans le sens ou vous avez accès aux versions stables (release) et plus au trunk depuis le site officiel:
http://opensource.adobe.com/wiki/display/site/Source
Alors pourquoi ne pas partager le trunk comme avant? Et bien cela vient du fait que Flex et AIR se basent sur les APIs Flash Player. Celles-ci sont en constante évolution, vous pouvez d'ailleurs allez télécharger la dernière beta de Flash Player 11 depuis l'incubator:
http://labs.adobe.com/technologies/flashplatformruntimes/flashplayer11/
Les APIs Flash Player ne sont pas, elles, Open Source. Il y avait donc un conflit à ce moment-là, et les sources que vous auriez dans le trunk n'auraient pas pu être compilées parfois puisque le trunk des APIs Flash Player n'était pas partagé. Bref, je pense que vous avez compris (enfin j'espère).
Le projet Spoon
Le projet Spoon est né de l'initiative de certaines personnes (hors Adobe) qui veulent relancer l'intérêt de la communauté des développeurs Flex dans la contribution au SDK.
Un site web est consacré au projet pour toutes les informations:
http://www.spoon.as/core-values/
Le but du projet est de construire une organisation (pas 3 personnes qui se sont mis d'accord sur Twitter) afin de travailler de près avec les équipes du SDK chez Adobe. Cette coordination permettrait de proposer des patchs de qualité, revus par l'équipe de Spoon, ce qui permettrait un traitement plus rapide du côté d'Adobe. Pour pouvoir s'assurer que les patchs ne "cassent pas tout", le but est aussi de pouvoir intégrer toute la batterie de tests de l'équipe QA de Flash Player.
Bref, un projet très intéressant qui est là pour durer. Si vous souhaitez en savoir plus, 2 sessions de Q&A sont prévues mardi prochain le 16 Août:
http://www.spoon.as/2011/spoon-introductory-meeting/
Recherche de volontaires
Le projet Spoon recherche des volontaires. Si vous voulez mettre les mains dans le cambouis, c'est une opportunité exceptionnelle ! Voici le détail:
http://www.spoon.as/2011/call-for-volunteers/
Si vous avez des doutes, demandez aux responsables de Spoon (@jonbcampos par exemple) sur Twitter ou posez vos questions pendant le Q&A. En tout cas, je me suis proposé comme volontaire, j'espère que d'autres français seront aussi intéressés !
AIR pour mobiles – Bug de Google Maps (freeze) enfin pris en compte par Google
Dans tous les frameworks vraiment natifs (Android et iOS), se trouvent des composants par défaut pour afficher une carte, pour indiquer une géo-localisation par exemple. Ces composants sont en fait des carte Google Maps optimisées pour mobile qui sont bien pratiques puisqu'elles vous permettent de vous focaliser sur vos problématiques métier et pas sur la création d'une carte.
Dans un cadre "classique" web, on utilise le SDK Google Maps for Flash pour pouvoir intégrer une carte dans son application AS3 ou Flex.
Pour les applications AIR, on fait de même, seul le mécanisme de licence change. Le système de licence web est lié à une clé correspondant à une URL ce qui n'est pas adapté à une application AIR. Google expliquait donc qu'il fallait donner une url par laquelle l'application pouvait être téléchargée.
L'intégration se fait très bien dans une petite application mais lorsque vous avez une application plus conséquente, vous allez remarquer un bug plutôt bloquant. L'application se gèle pendant un temps qui peut aller jusqu'à 20 secondes. L'application n'est plus accessible et le système la croit plantée.
Un bug a été rentré il y a quelques mois sur la bug base de Google Maps SDK:
Bug: AIR application freezes on initialization for 15+ seconds
Ce bug a été maintes fois reproduit, aussi bien sur Mac que sous Windows. Un des utilisateurs a même commenté sur le bug, expliquant la raison possible de ce freeze. Pour autoriser l'application Google Maps semble mettre toute l'application dans un ByteArray avant de l'envoyer pour vérification de licence. Plus l'application est grande, plus cette manipulation va prendre du temps et freezer l'application.
Ce bug était aussi présent lorsque l'on créait une application AIR pour Android ce qui était plutôt gênant. Il existe certes des "hacks" décrits dans les commentaires mais ceux-ci ne sont pas simples à mettre en place ou tout simplement impossible à réaliser avec AIR pour Android.
La bonne nouvelle
La bonne nouvelle est arrivée il y a quelques jours de la part d'un admin "lukem":
Comment 37 by project member lu…@google.com, Dec 01 (2 days ago)
We're looking into it. Thanks!
Status: Acknowledged
Labels: Internal-3246096
Bon, cela ne nous donne pas une date de résolution mais il faut espérer que ce soit bientôt!
Intel lance AppUp – Un point l'avenir des applications multiplateformes
Il y a quelques semaines maintenant se tenait Adobe MAX 2010 à Los Angeles. Durant la keynote du deuxième jour, Adobe a présenté une nouveauté, Adobe InMarket. Voilà le topo que j'en avait fait:
Un nouveau produit lancé par Adobe nommé InMarket. Celui-ci vous permet d'envoyer votre application AIR pour la soumettre sur plusieurs "Market". Pour l'instant, on donne l'accès au "Intel App", le market d'Intel pour laptops et notebooks. On ne parle pas de l'AppStore ou de l'Android Market, et je ne suis pas sûr que cela se fasse un jour, chaque Market ayant déjà son propre éco-système.
Si vous vous inscrivez dès maintenant, vous aurez droit à une clé de signature gratuite (d'une valeur de 300$ si j'ai bien entendu). Ensuite, les prix ne sont pas communiqués. Inscrivez vous donc dès maintenant, cette offre est limitée dans le temps!
Plus d'informations sur leur site:
Bon alors petite erreur de rédaction, ce n'était pas "Intel App" mais "Intel AppUp" qu'il fallait lire. Ce programme "Intel AppUp" vient de démarrer, il y a même un concours pour gagner pas mal d'argent si cela vous intéresse :
http://appdeveloper.intel.com/en-us/contest/contest-details
Intel AppUp va aussi être présenté lors de l'évènement LeWeb'10 qui se tiendra à Paris. Plus d'informations sur l'évènement:
http://www.leweb.net/partners/2010/sponsors
Au passage, ce billet fait aussi office de participation à un jeu-concours dédié aux bloggeurs organisé par Intel. Si je suis tiré au sort, je ne manquerai pas de faire un compte-rendu 
.
Le futur des applications multiplateformes
Dans le cadre de la participation à ce concours, je dois donner mon opinion sur l'avenir des applications multiplateformes et c'est avec plaisir que je vais le faire ^^. Avant tout, quand on parle d'application, on parle maintenant des applications présentes sur les smartphones type Android Market ou AppStore. On a un peu tendance à oublier les applications bureautiques "traditionnelles" qui est maintenant devenu la méthode "old school" de création d'application.
Le succès des applications mobiles
Alors pourquoi le succès des applications sur mobile? Selon moi, la raison est plutôt simple, c'est l'expérience utilisateur qui l'emporte. Le premier point est le fait que l'on peut rechercher sur un repository commun (le store), une application adaptée à son matériel. Dans un environnement desktop, on passe par des sites qui fonctionnent plus ou moins bien, financés par la pub qui inonde l'écran. Sur mobile, le store est réduit au strict minimum, un champ de recherche, des catégories et des "tops" pour guider l'utilisateur. Pour se faire une idée du succès de l'application, les utilisateurs laissent des notes et des commentaires, le tout sur une fiche descriptive d'application.
Le deuxième point important est le paiement et la "micro-économie" générée par les "store". L'exemple plus flagrant est celui des jeux vidéos. Pour un jeu vidéo type console, il faut débourser 40-70 euros pour un jeu qui vient de sortir. Pour le dernier jeu iPad "Rage HD", le prix est de 1.59euros. Vraiment une bagatelle pour l'utilisateur (c'est d'ailleurs mon seul achat sur le store 
) et pour le développeur, la possibilité de toucher des millions d'utilisateur sans passer par les circuits de distribution classiques. Le bénéfice sur chaque jeu est bien sûr minime mais avec le nombre, le profit peut être important.
Troisième point, la pertinence des applications. Chaque application à un domaine bien particulier dans lequel elle excelle. La plupart des applications offrent la connexion à un service ou un mashup de service. Lorsque l'on télécharge l'application "Le Monde", c'est que l'on souhaite consulter le journal. L'application offre ce service et ne va pas "plus loin". On se retrouve donc à naviguer entre application, Facebook, Twitter et Le Monde sont de bon exemples. Ils offrent une inter-communication entre applications mais se concentrent sur leur coeur de métier. Cette cohérence est vraiment appréciable du point de vue de l'utilisateur, la simplicité prime.
A ce sujet, je vous conseille vivement la lecture d'un article de Wired UK d'Octobre 2010 par Chris Anderson nommé "The Web is dead. Long live the internet". qui offre une vision très éclairée sur le sujet.
L'importance du X-platform
Dans le beau monde du smartphone, certains acteurs se sont démarqués, soit en tant que constructeur, soit en tant qu'éditeur. Parmi eux, on trouve Apple, Google , Windows et BlackBerry principalement. Pour pouvoir se démarquer et pour des raisons économiques évidentes, chacun va faire "son propre système". Apple est certainement le meilleur dans ce domaine puisqu'il maitrise le store (AppStore), le matériel et le système d'exploitation (iOS). Google a tenté lui de faire des téléphones (cf. Nexus One) pour montrer l'état de l'art Android mais l'a rapidement abandonné, ce n'est pas son métier. Il a (et continue) cependant lancé et aidé l'OS Android qui est utilisé par d'autres constructeurs (Samsung par ex.). BlackBerry semble quant à lui prendre le même chemin qu'Apple.
Cette "granularité" est certainement le plus grand risque qui peut s'abattre sur ce nouveau marché. En effet, chaque monde est cloisonné et ne permet pas un présence sur toutes les plate-formes. Les premiers touchés ont sûrement été les développeurs, qui ont du faire des choix. Il n'existe pas aujourd'hui de langage "commun" à toutes les plate-formes. On parle à l'une, mais l'autre ne nous comprend pas.
Flash Builder "Burrito" – Les nouveautés (productivité, mobile, …)
Il y a maintenant quelques semaines, Flash Builder "Burrito" est sorti en public release lors du salon Adobe MAX 2010. Je n'avais pas encore eu le temps d'en parler, notamment des nouveautés apportées par cette version, ce qui va être résolu par cet article 
.
Notez que cette version est une version "public release", il est donc pour l'instant déconseillé de l'utiliser dans un environnement de production.
Dans ce billet, je vais détailler les évolutions importantes, et notamment celles que je trouve très intéressantes au quotidien. Avant tout, si vous voulez lancer le téléchargement pendant la lecture de l'article, voici le lien:
http://labs.adobe.com/technologies/flashbuilder_burrito/
Améliorer votre productivité au quotidien
C'est selon moi l'objectif principal d'un IDE, de vous accompagner et de vous aider dans votre développement. Flex Builder 3 faisait assez peu de choses et assez lentement. Flash Builder 4 a commencé à corriger le tir en apportant quelques améliorations et en améliorant de manière significative, la vitesse de l'IDE (notamment lors de la recherche de référence et le refactoring). Flash Builder 4 ajoute quant à lui de nombreuses améliorations, dont certaines vraiment indispensables au quotidien.
En côtoyant des développeurs Java au quotidien sous Eclipse, il est parfois rageant de voir qu'ils ont accès à des fonctionnalités très simples telles que la création de variables locales (+refactoring) ou à des templates de code automatiques, lorsqu'il font une itération avec un for each par exemple.
D'ailleurs, de nombreux autres IDEs du marché ont attaqué sur ces points de productivité là. Pour l'instant, les seules alternatives à Flash Builder sont:
- IntelliJ Idea: J'en ai entendu beaucoup de bien dernièrement, notamment au niveau de la gestion des modules. Ne gère pas le dev ActionScript dans sa version gratuite et Open Source, seulement Java et Groovy. Il vous faudra débourser 528 euros pour la version entreprise.
- FDT 4: 700$ pour avoir un Debugger alors que Flash Builder le propose dans sa version standard à 250$, rly?
- FlashDevelop: l'alternative gratuite en .Net
- Amethyst: Pour ceux qui aiment Visual Studio
Après, on pourrait joyeusement "troller" sur tel IDE est mieux que l'autre etc. Pour moi, Flash Builder 4 représente le meilleur rapport qualité / prix / performances / futur.
En tout cas, pour ce qui est des fonctionnalités de productivité, le vide est comblé. En vrac, templates de code en AS3, génération d'event handler, renommage d'une variable dans un fichier ou dans le workspace, génération de classes / interfaces pour les types déclarés mais non reconnus, création de variables locales, complétion de code sur les metadata…
Flex Roadmap – Le futur du SDK Flex (post-Hero)
Pendant Adobe MAX 2010 se sont déroulées de très nombreuses sessions parmi lesquelles, une session dirigée par Deepa Subramaniam (Senior Product Manager for the Flex SDK). Durant cette session d'environ une heure, elle a présenté le futur du Flex SDK.
Cette session est vraiment très très très intéressante. Si vous êtes développeur Flex /AIR, vous devez absolument la regarder, de nombreuses pistes sont dévoilées.
Les sessions peuvent maintenant être visualisées sur le site d'Adobe MAX 2010. Voici donc la vidéo de la présentation "Flex Roadmap":
Comme je l'ai dit plus haut, je vous conseille très vivement de regarder cette vidéo en entier, on y apprend beaucoup. Pour ceux qui n'ont pas envie, voici un petit résumé.
Le futur du SDK Flex
Avant tout chose, il faut préciser que ce qui est dit lors de cette présentation (et répété ici) ne sera pas forcement implémenté. On parle d'objectifs à long terme qui pourront être modifié (ou supprimés) au cours du temps.
Voici donc les points forts de la présentation (selon moi).
Enrichissement de la librairie de composants Spark
Ce n'est pas nouveau et c'est plutôt un objectif aussi court terme, de nouveaux composants Spark vont arriver pour compléter les composants qui existaient en Flex 3 (Halo). Dans Hero, on a déjà accès à Spark Form, Spark Image et Spark DataGrid qui est toujours un peu en chantier. De nouveaux composants seront développés pour encore plus de possibilités out-of-the-box.
Utilisation des APIs de globalization de Flash Player 10.1
Flash Player 10.1 embarque de nouvelles APIs de "globalization" qui permettent de connaître la "locale" (le langage /pays) du poste client. Les composants seront ainsi automatiquement adaptés à la locale de l'utilisateur (Validator, Formatter, …)
Mes projets (Open Source)
Autres
