Liens:
- Adobe AIR 1.5.1 Developer and User Release Notes
- Adobe AIR 1.5.1 Documentation
- Download the Adobe AIR SDK
- Adobe AIR 1.5.1 Known Issues and Limitations

Via air team blog

A paraître dans les prochains jours, un article d’investigation qui devrait vous plaire. So stay tuned !

Ca me rappellerait presque l’époque d’Ellipsis…

D’ailleurs quand je tombe sur certains posts et que je lis Vaut mieux avoir CS3 toujours sous la main…, j’avoue être plutôt content de n’avoir quasiment plus besoin de ce logiciel dans mes travaux.

Avec un peu de recul, il est d’ailleurs étonnant de constater à quel point il est devenu nécessaire au fil du temps de faire de l’anti Flash pour produire du Flash, du moins si l’on souhaite améliorer son workflow et les performances de ses réalisations. Quelques exemples: Préférer le bitmap au vectoriel, les tweens à la timeline, l’animation en copypixels aux MovieClips, la programmation OO au scripting, l’utilisation d’un logiciel tiers à l’IDE…

De quoi rendre perplexe si certains élans artistiques n’étaient pas là pour nous réconcilier avec l’outil roots d’animation.

Via galvan on flash

Kevin Lynch vient d’annoncer la publication prochaine des specs du RTMP (Real-Time Messaging Protocol). Encore une initiative qui confirme les velléités d’ouverture d’Adobe avec ses publications Open Screen Project.

Aucune date de sortie n’a été annoncée pour l’instant. On sait juste que le document sera disponible à cette adresse avant l’été.
En attendant, vous pouvez consulter l’intégralité du communiqué de presse ici.

Via webkitchen

La librairie est découpée en 3 parties:

- Représentation du modèle de données en mémoire:
Il s’agit d’un arbre découpés en noeuds de différents types: Properties, structures, arrays, qualifiers…
L’API de la librairie s’assure à chaque instant de la validité des données de l’arbre afin qu’elles puissent être sérialisées à la demande. Une exception est lancée dans le cas contraire.

- Parseur (XML, String ou ByteArray) :

var xmpStr: String = "”
+ data + "";
var xmp: XMPMeta = new XMPMeta(xmpStr);

- Sérialiseur (XML, String ou ByteArray):

var xmp:XMPMeta = new XMPMeta(...);
// ... modify metadata
var str:String = xmp.serialize();
var buffer:ByteBuffer = xmp.serializeToBuffer();

On devrait bientôt voir éclore des applications AIR capables de lire (et de réinjecter ?) le metadata d’un fichier CS4.

Cette initiative a déjà su s’entourer d’une liste de partenaires prestigieux avec en tête de liste Adobe et Microsoft. Les régies publicitaires ont répondu à l’appel bien sûr. On retrouve: 24/7 Real Media, BlackArrow, Eyewonder, OpenX, Panache, ScanScout et Smartclip.

Un framework open source décliné en deux versions (Silverlight 2.0 et Flash 9.0) est disponible sur le site. Il est utilisé par les non moins prestigieux Adobe TV, FWA Theater et New York Magazine.

La distribution Flash inclut les fonctionnalités suivantes: Connexions (Ondemand RTMP, Live RTMP et HTTP), containers audio et vidéo (H.264, VP6, FLV, AAC3 et MP3), détection de bande passante, prise en charge des firewalls, gestion avancée des cue points, bridage du data rate, contrôle du playback, gestion des MetaDatas, parsing Media RSS 1.1.2…

Ci-dessous, un petit test maison utilisant un connecteur 24/7 Real Media pour illustrer les possibilités d’intégration d’une régie publicitaire.

Pour l’exercice de style et proposer du contenu après la pub, j’ai modifié la classe AkamaiMediaRSS.
Après une succincte réécriture de la méthode parseXML, le player est capable de lire un flux RSS Seesmic et de prendre en charge une version raccourcie (pour l’occasion) de ma playlist utilisateur.
Que du bonheur !

Pour lancer l’exemple, il faut cliquer sur le gros bouton bleu, aimer la bière, les chutes et les brèves de comptoir.

[kml_flashembed movie="http://www.tweenpix.net/files/Akamai_Player_247.swf" width="330" height="280"/]

Via flashmagazine

Selon William Leszinske Jr., le processeur CE 3100 devrait permettre d’utiliser les possibilités HD de Flash et délivrer aux utilisateurs une expérience Internet riche sur un écran de TV .
Sortie prévue, mi 2009.

Via RTTNews.com

Si Google avec Android Market et Microsoft avec Microsoft Skymarket marchent sur les traces de l’iPhone et de l’iTunes Store, ce n’est pas innocent. Les deux géants l’ont compris, déployer une plateforme de distribution de qualité est un point capital pour la pénétration d’une technologie mobile.

Alors qu’attend Adobe pour offrir à ses développeurs un organe officiel de diffusion pour les applications AIR et Flash Lite ?
On dirait bien qu’Adobe a choisi une autre stratégie en se tenant à l’écart des combats titanesques d’OS et de hardware, préférant produire un middleware de qualité sous le nom de code: Open Screen Project. Il reste une dernière marche à franchir, celle de l’adoption.

Petite parenthèse pour finir, AndSpot vient d’annoncer qu’ouvrira les portes de son store ouvrirait ses portes d’ici Mercredi. On pourra consulter, installer et acheter des applications Android, avec la possibilité de se connecter depuis son téléphone (par le biais d’un client dédié). 95% des bénéfices seront reversés aux développeurs.

Update: Scott Janousek vient de me tweeter pour me signaler l’existence de l’Adobe AppZone pour la distribution des applis Flash Lite. Autant le dire tout de suite, la démarche est plutôt confidentielle comparée à celle de la concurrence. Concernant AIR, c’est toujours le néant pour l’instant.
Merci à aSH pour l’url !

Brendan Eich aka Mr Harmony

La décision a été prise à Oslo fin juillet en compagnie de quelques géants de l’industrie: Lars Hansen d’Adobe, Mark Miller de Google et Allen Wirfs-Brock de Microsoft. Harmony est né, nom de code introduit par le grand gourou de Mozilla pour mettre fin aux querelles ES4/ES3.1 et endiguer l’inertie qui condamne depuis plus d’un an toute évolution du standard ECMA-262.

Samedi, le renommage de la mailing-list es4-discuss@mozilla.org par es-discuss@mozilla.org vient confirmer les inquiétudes de certains.

ES4 est-il mort ?

Dans sa forme initiale, oui… et non sans faire de bruit. La communauté Flash crie au scandale. Ironie du sort, c’est la seule à ce jour à pouvoir jouir de l’implémentation d’une partie des specs de feu ce standard. Quoi de plus légitime, quand on sait qu’Adobe est l’acteur majeur de ce schisme ES3.1/ES4 avec sa rutilante démo du nom d’ActionScript 3.0, implémentation partielle avant l’heure, mais fut surtout le contributeur le plus actif avec la cession de sa machine virtuelle au sein du projet Tamarin

Les ingénieurs d’Adobe seraient-ils des idéalistes sémantiques atteints de philanthropie aïgue ?

Peaceware ?

Du tout ! La manoeuvre est bien plus stratégique qu’elle en a l’air. C’est une véritable guerre industrielle qui fait rage depuis 2 ans. Les enjeux économiques sont masqués mais ne sont pas des moindres. Adobe pousse à l’adoption de ses technologies et rêve le soir sur les plages californiennes, une tequila sunrise à la main, sous l’oeil libidineux des surfers bodybuildés, qu’ActionScript devienne un jour la syntaxe du web de demain et pourquoi pas (soyons fous !) d’une intégration de Tamarin dans Internet Explorer. Microsoft ne l’entend pas de cette oreille et rejette en bloc toutes les proposition ES4. Forcément !

Je vous recommande au passage la lecture de ce billet de Hank Williams qui propose une analyse caustique à souhait de ce conflit d’intérêts (euphémisme ?). Rien que le nom de domaine de son blog vaut le détour !

En bref ?
Le choc des titans une fois de plus: Adobe vs Microsoft.

Adobe vs Microsoft

Microsoft sent que le web lui échappe et que les alliances adverses ne l’épargnent pas. La résistance devient de plus en plus difficile si l’on jauge la force de frappe du consortium de compétiteurs qui avance masqué. Adobe, Mozilla, Google et Yahoo se donnent la main pour sonner la fin d’un empire. Le champ de bataille se nomme le Web. Il ne manquerait plus que SilverLight soit obligé de calquer la syntaxe ActionScript 3.0 pour le déploiement de ses futures applications se gaussent les ingénieurs de la firme de Redmond.

Adobe ferait donc peur ? Encore récemment, Steve Jobs nous a fait une belle démonstration des craintes que pouvaient susciter l’essor de la plateforme Flash en boycottant le player sur la version Safari de l’IPhone et en vantant plus tard les prouesses du très conventionnel SproutCore pour faire avaler la pilule.
« Euh… Mais Steve, si la technologie Flash n’est pas adaptée à l’IPhone, comment se fait-il qu’elle le soit à d’autres technologies mobiles ? » :p
En exergue donc ici, les effets pervers du lobbying ou quand un fabricant d’OS et d’hardware informatique se met à truster la téléphonie mobile.

Mais les analystes le savent bien, c’est un conflit bien plus large qui se dessine à l’horizon. On pourrait le résumer en ces quelques mots: Desktop vs Browser.
Pour comprendre les enjeux économiques de ce nouveau combat, imaginez un ordinateur où le système d’exploitation ne serait plus qu’une pièce mineure pour faire fonctionner les applications, destitué peu à peu par les services proposés par le navigateur.

Desktop vs Browser

C’est aujourd’hui, une partie du web qui menace le desktop, parce que les RIAs (cf: Photoshop Online powered by tamarin ou la menace potentielle des machines virtuelles en plugin navigateur), les (le devrais-je dire !) moteurs de recherche (cf: Google Operating System ou la prise en otage de l’information) et les réseaux sociaux (cf: Facebook et son écrasante plateforme F8 – prononcez fate – dont le nom de code ressemble à une inquiétante allegorie comme le prophétise ici Techcrunch) pourraient bien remplacer un jour, en partie ou totalement, les applicatifs qui tournent sur nos chers systèmes d’exploitation.

Les fabricants d’Operating System ne se sont pas trompés et ont identifié ECMAScript comme une pièce de plus sur l’échiquier à ne pas négliger. Il leur fallait impérativement déjouer les démarches sournoises d’Adobe et consorts pour éradiquer le fratricide ES4. Aujourd’hui, c’est chose faite !

Mais que peuvent donc bien craindre les développeurs Flash maintenant qu’ES4 est entré au panthéon des morts nés ? Pendant que certains s’interrogent sur l’utilité des standards, d’autres préfèrent sonner l’alarme en qualifiant ActionScript 3.0 d’orphelin ou de langage devenu propriétaire pendant que d’autres encore profitent du tumulte général pour tenter de convertir de nouveaux fidèles à leur paroisse.

Sous des airs de 18 juin, le discours officiel d’Adobe se veut rassurant:
« Moi, Dave McAllister, actuellement à San Francisco, j’invite les développeurs Flash et tous les développeurs qui se trouvent en territoire ECMAScript ou qui viendraient à s’y trouver, avec leurs armes ou sans leurs armes, à se mettre en rapport avec moi.
Quoi qu’il arrive, la flamme de la résistance Adobe ne doit pas s’éteindre et ne s’éteindra pas. »

Les carottes sont cuites… Attention je répète, les carottes sont cuites…

Exit le ton patriarcal, avec un peu de recul cette annonce laisse présager des meilleurs augures pour la technologie Flash. Adobe va pouvoir se libérer du carcan ECMA en termes d’innovation et éviter de reproduire (souhaitons le en tout cas !) certaines erreurs commises dans le passé (cf: le retrait des constructeurs privés dans ActionScript 3.0, une des conséquences fâcheuses du respect strict des normes).

Le conclusion du billet de Mike Chambers va dans ce sens d’ailleurs, et se veut bien plus rassurante encore:
« En bref, ActionScript 3.0 ne va pas changer et nous n’allons pas le faire régresser dans les prochaines versions. Nous allons continuer d’innover avec le Flash Player et continuer de faire progresser le web comme nous le faisons depuis 10 ans déjà. »

Les ingénieurs d’Adobe auraient-ils prévus de mettre les bouchées doubles pour fêter la pseudo indépendance qu’ils viennent d’acquérir à leur dépens ? Rien de si effarant si l’on en juge par les derniers ajouts qu’ils ont effectué dans la beta du player 10 (cf: La classe Vector). La maturité aidant, voici peut-être venu le temps de se poser pour fumer un havane, méditer, puis planifier, pour débarquer en force sous l’occupation estampillée MS avec une nouvelle version d’ActionScript implémentant toutes les features manquantes d’ES4, celles-là même qui ont fait saliver plus d’un développeur Flash cet hiver.

Le temps d’un havane ?

Et tant qu’on est au rayon cadeaux, pourquoi pas ajouter à la wishlist un runtime qui supporterait la covariance des types et l’overloading paramétrique. Pour mémoire, ce dernier fut l’une des vélleités émises par Gary Grossman pendant l’alpha privée d’8ball, juste avant de quitter le navire.
Qui sait même, Adobe entérinera-t’il peut-être un jour son propre standard façon Microsoft avec ECMA-334 comme ce fut suggéré dans un commentaire Vendredi ?

Affaire à suivre !

A mon humble avis, bien plus que les développeurs Flash, c’est la communauté Ajax qui va payer ce manque d’ambition exprimé à Oslo. Il lui restera EJScript pour se consoler et laisser les navigateurs au repos pendant les longues soirées d’hiver. Elle pourra enfin jouer à ES4 comme les grands. Trêve d’ironie, c’est JavaScript qui risque d’être condamné encore longtemps au triste statut de langage amateur.

On apprend en effet que sous les accords cordiaux d’Harmony se cache des nouvelles biens plus austères. Les packages, les namespaces et l’early binding passent à la trappe définitivement. Pression stratégique ou réalité en phase avec les performances des navigateurs comme le suggèrent certains ? Mais surtout, n’est-ce pas seulement le haut de l’iceberg ? Tout le reste des specs, c’est à dire les classes, l’héritage, les generators… sont encore en discussion si l’on en croit les rapports faussement optimistes des principaux concernés.

La prochaine version de JavaScript dans les navigateurs, ne risque-t’elle pas de se limiter à une version ultra-light d’ES4 (avec classes et types) en mode sucre syntaxique, comme le fut ActionScript 2.0 après l’ère du prototypage absolu en ActionScript 1.0 ? On se souvient du grand désarroi qui avait envahi une partie de la communauté à l’époque. Branden Hall avait même choisi de boycotter purement et simplement cette version du langage. Une fois de plus, il est permis de présager le pire pour l’avenir de JavaScript, surtout si l’on met dans la balance les véritables enjeux de ces tractations additionnés aux adieux de SpiderMonkey à Tamarin sans qu’on lui ait laissé le temps de dégainer son grand mouchoir blanc.

Adieu Tamarin ! Je t’aime moi non plus !

Les nostalgiques conserveront en épitaphe l’engouement de Brendan Eich pour ES4 exprimé jadis lors d’une interview.

So, what else is there ?
Une belle déclaration d’Adobe à Microsoft peut-être, une de celles que je pourrais faire à la muse mordorée qui hante mes nuits:

I’ve got a golden ear
I cut and I spear
And What else is there?
Roads and getting nearer
We cover distance still not together

If I am the storm if I am the wonder
Will I have flashlights, nightmares and sudden explosions
There is no room where I can go and
You’ve got secrets too
I don’t know what more to ask for
I was given just one wish

So, what else is there – Royksopp

Sont disponibles :
Player 6 : 79, 65, 47, 29, 23, 21
Player 5 : 41/42, 30