João Saleiro, well known Flex Developer, author of Airgile and technical leader of Webfuel, has published a blog article: After 6 years doing Flex, am I moving to HTML5?. In this post, he is sharing his experience in trying to use the HTML5 stack for building a RIA. I think this is really a must read article.

I will only give some highlights here for quick-reading, without any comment from myself. But I really invite everyone to take the the time to read the original writing.

I completley agree with one of the first statement of João, though not coming from the same background:

We are desktop-developers-working-on-the-web

An important side note, is that I see Webfuel as a team of desktop developers working on the web. In another words, we use desktop development paradigms, best-practices and design patterns borrowed from the JAVA world and we've applied them to build applications that happen to run inside the browser. Our work consists normally in building at least two loosely coupled applications, connected by an RPC API: a client application (running inside the web-browser) and a server application that only exposes services and is not aware of the client application.

How well put is the last sentence, that is indeed how things are!

Then he moves to the point Is "HTML5" ready?

From the point of view of a web-developer - of course it is!!! For a typical web-developer, HTML5 means more tools, more power and much better cross-browser compatibility than what they had before (...)

From the point of view of desktop-developer-working-on-the-web - hell no! (...)

It's quite understandable that a Flex developer feels frustrated. You feel you're going backwards 4 or 5 years.

About cultural differences

I've sent a couple of emails to mailing lists of HTML5 and JS development asking people what they were using for MVC, IoC, Unit Testing, Code Coverage, Compiling, Continuous Integration, etc, etc. The answers were like "WTF dude, IoC? What are you talking about?". I now know that I was doing the wrong questions, as you'll see below.

(...)

The best single advice I got was: "accept web dev for what it is and don't try to change it. Don't do RIAs. Do simple web development. Then improve.". Good advice!.

After covering JS frameworks, IDE, he comes to Javascript

This was probably my biggest pain point. I'll start with the conclusions: accept Javascript for what it is and don't try to mimic your common OOP techniques and classes. There.are.no.real.classes.in.javascript. 

(...)

- Uglyness. I'm used to a HUGE-ULTRA-CLEAN separation between classes, libraries, modules, components and applications. In the webdev world, get ready to see PHP spitting HTML with JS that spits more HTML... Or function a() that creates another function in object b, that knows about object c and changes how c behaves. Things like that. In many known js libraries.

- It's not built for team work. (...)

- Code practices. (...) Enter Javascript. And cry. By some weird reason, people like to write as much code as possible in a single line, making it not only very hard to read, but also very hard to maintain. I've got used to seeing the #('huge').line({of: code, that: function() { looks() }).like('a').train(); . And this practice is everywhere, pretty most all examples, libraries and worse: in books! One of the books I read had one line that took me around 5 minutes to understand! (...)

The good part: no compiling times. Which is actually a very good part... (...)

One thing is for sure: it's being pushed forward and you can't deny that.

Then, he goes through Layouting and the DOM, Optimizations/Preloading content, HTML(5), JS and Mobile, UI Components, before entering into Crossbrowser issues.

Crossbrowser issues exist, they are a PITA and they will consume at least 30% of your time in a project. (...)

Get ready to having to test something in several browsers and to change plans in the middle of the project because your approach doesn't work as expected in one or two major browsers. (...)

We had one crossbrowser issue this week that almost killed our current project. (...)

Finally, he states about productivity:

You'll end up implementing workarounds and hacks (on top of other hacks) constantly. Coming from the Flex world, you'll feel ashamed of your hack - don't be. It's normal. Most of the times, you won't have another choice but to accept the hack and move on. 

Coming from a rapid development environment as Flex, productivity in JS and HTML can be quite frustrating until you get used to the bumps on the road. After you're experienced, it will get better, but I don't expect it to come any close to Flex development in a near future.

Time for conclusions:

The first conclusion is that we'll keep using Flex in long-term enterprise RIAs projects. Neither the open-standards nor we are ready to build the same type of experiences that our clients expect us to do. 

(...)

But I don't think we'll be able to do the same type of RIAs we were doing with Flex at least in the next two years. Also, maintainability and it's cost scares the shit out of me. 

And quoting him again , some final wisdom :-)

Bottom line: ignore the shit storm and the bad PR. Ignore fanboys. Choose your tools based on logic.

But alas:

the perception is what matters on business. You can have the best product of the world, but if people believe it's bad they won't buy it (and they'll even be happy on telling everyone how much your product - that they never used - sucks). But if they think it's good - even if it actually sucks - they'll probably buy it (and complain later). Perception. That's what sells. Perception.

Permalink | Leave a comment  »

Replace * with whatever technology and play!

That's the game proposed by Michael Chaize in his article Flexcursion with Apache commenting Flex SDK given to Apache:

Here is my TOP 5 list of the dead technologies:

“.NET is dead” is the big winner with 576000 search results on Google. Congratulations.

“JAVA is dead” is following with 138.000 results. I can hardly feel this trend from Devoxx and the 3200 Java developers around me 

“PHP is dead” is a little child with only 35.600 results.

“Ruby is dead” is in the same range with 30.700 results.

“AJAX is dead” generates 6500 results.

So we are newbies in this competition as “Flex is dead” only displays 5000 results  I’m kidding of course, it’s a stupid analysis but it highlights that you shouldn’t always trust online articles about technologies lives.

The trend for mobile apps

Regarding the illustration of this article, it was based on the fact that more and more people are using mobile apps than browser to get information:

Two decades after its birth, the World Wide Web is in decline, as simpler, sleeker services — think apps — are less about the searching and more about the getting. 

Read the article...

An evolution that is also described in the article "Mobile Web versus Desktop Web" on The Tech Journal.

Mobile app use trumping web browsing for the first time and time spent with mobile apps per day per person reached an average of 81 minutes compared to 74 minutes on the Web. 

The article on Wired also analysed a trend in technology:

Personaly, I guess there will be another column on the right for multiplatform...

Permalink | Leave a comment  »

Les cétacés (dauphin) sont en fait proches des hippopotames.

Adobe clarifie sa communication

Nous avons vécu en cette mi-novembre, une grosse période de turbulence liée à l'annonce de l'arrêt du développement de nouvelles versions de Flash pour les mobiles (voir mon article "Flash, Flex, AIR, iPhone, mobiles : au secours, j'y comprends rien !"), puis du passage de Flex en open-source.

Adobe clarifie aujourd'hui (16 novembre 2011) les choses dans une mise à jour de l'article "Your Questions About Flex" sur le blog officiel de l'équipe Flex.

L'essentiel de la mise à jour

Je vous invite à vous reporter à cet article pour la présentation complète, mais en résumé :

• Le Flex SDK est donné à la fondation Apache (comme PhoneGap de Nitobi ce qui avait plutôt bien accueilli) sous gouvernance Adobe - Spoon. Son évolution sera assurée par une équipe mixte intégrant des employés d'Adobe, des leaders de la communauté Flex, des intervenants issus de grands clients de l'éditeur ayant des projets stratégiques autour de Flex.
• Adobe se concentre sur son coeur de métier, le développement et la commercialisation d'outil, et continue de développer et vendre Flash Builder, l'IDE basé sur Eclipse.
• Adobe s'engage à maintenir la compatibilité du Flex SDK avec les socles d'exécution AIR et Flash Player.

Plusieurs analyses estiment que cette évolution est judicieuse, voire inéluctable. Le SDK Flex en version 4 a atteint un degré de maturité qui ne justifie plus le travail de fond d'un éditeur pour décider de ses nouvelles implémentations. Bâtir sur l'existant, ajouter de nouveaux composants représentent des tâches qu'une communauté open-source bien gérée peut assumer.

HTML 5 dans 3-5 ans

Adobe clarifie également une phrase qui avait provoqué un émoi certain : "In the long-term, we believe HTML5 will be the best technology for enterprise application development".

En effet, une écrasante majorité de développeurs Flex, quoique partageant cette analyse sur "le long terme" s'inquiétaient quant à eux du présent : aucune alternative présentant la même maturité et un outilllage équivalent à la plateforme Flex n'existant aujourd'hui.

C'est ce que la mise à jour de l'article renforce :

• en clarifiant le constat que le conglomérat de technologies HTML-JS-CSS n'est pas encore mature, même si en très rapide évolution : "it could be 3-5 years from now), we believe HTML5 could support the majority of use cases where Flex is used today." 
• en insistant sur le fait qu'aujourd'hui, au présent, dans la réalité des projets, Flex constitue LA technologie de référence pour les applications d'entreprise "Flex has now, and for many years will continue to have, advantages over HTML5 for enterprise application development" "Our announcements relating to changes in the way Flex SDK is developed do not change the fundamental value-add of Flex or make HTML5 suddenly more capable than it was last week."

Je vous conseille également la lecture de l'article "Moving Forward with Flex and Flash".

Conclusion

Comme le dirait Shakespeare, "Beaucoup de bruit pour rien" ?

Pas si sûr, car si la communication d'Adobe s'améliore et commence à montrer une cohérence de stratégie, beaucoup de dommages collatéraux ont été produits :

• dans la communauté Flex qui voit sa confiance en Adobe très ébranlée,
• et bien plus grave, dans l'esprit de nos clients qui sont abreuvés de raccourcis journalistiques dont la conclusion péremptoire "Flash est mort et Flex moribond" sera difficile à contrebalancer.

Je ne me livrerai pas ici à un jeu de pronostic sur ce qu'il en sortira dans le futur.

Je me contenterai de citer Maxime Du Camp : "Silence sur le passé, bon vouloir pour le présent, espérance pour l'avenir" et de vous renvoyer à l'illustration qui ouvre cet article : je ne peux que souhaiter à Flex une évolution aussi harmonieuse et élégante que celle du dauphin !

Update 2011-11-18 : liens complémentaires

• Annonce officielle d'Adobe sur sa ré-organisation : 

Adobe will continue to support applications built with Flex and Adobe LiveCycle, as well as all future versions of the SDK running in PC browsers with Adobe Flash Player and as mobile apps with Adobe AIR indefinitely on Apple iOS, Google Android and RIM BlackBerry Tablet OS.

• Analyse du Gartner : Adobe Flash Wounded but Death Exaggerated

HTML5 is still in its infancy.(...) Gartner believes this collection will be mature enough for enterprises to use for strategic application development by YE14. (...) The Flash runtime will remain on mobile platforms. Adobe technology can package Flash content into a native iOS executable distributed via Apple's app store. Hundreds of applications already use this technology. Adobe's Creative Cloud launch was accompanied by a half dozen tablet applications for designers. These applications have innovative touch centric user interfaces, were built with Adobe Flash and AIR...

• The Spoon Project, Adobe & Flex : 

The Spoon Project’s mission is to foster a community partnership with Adobe and assist with stabilizing the Flex SDK through fixing bugs, providing for complete coverage of unit tests for the framework, and help contribute to the architecture of Flex going forward.

Permalink | Leave a comment  »

Les annonces se succèdent

• Apple ne veut pas de Flash sur l'iPad !
• Adobe annonce Flex 4.5 pour Mobiles : iOS - Android - BlackBerry TabletOS !
• Adobe abandonne Flash Player sur mobiles !

Hormis les évangélistes d'Adobe qui, quelque soit l'annonce, sont globalement "terribly excited"  et la secte des "viscéralement anti-Flash" qui danse en  chantant "Flash is dead, Steve was right", plus grand monde ne s'y retrouve aujourd'hui dans cette avlanche d'annonces.

Flash, Flex, Air c'est quoi ?

Ça tourne sur mobile ou pas ? sur iPad ou non ?

Ça sert encore à quelquechose ? c'est mort ?

Nécessaire clarification

Un tweet sur le sujet :

rblank9 Seems #Adobe doesn't get that ppl don't know the diff btw #Flash & AIR. If ppl think #Flash on mobile is dead, it's very hard to sell AIR

Effectivement, Adobe a anonncé le 9 novembre 2011 l'arrêt du développement du lecteur Flash pour les navigateurs mobiles. Cependant, il convient de distinguer cette technologie de la réalisation d'applications autonomes pour mobiles avec Adobe AIR qui continue pour sa part de proposer un énorme intérêt !

Comme je viens de sortir un livre sur cette dernière possibilité, je me sens un peu concerné et en devoir de tenter de clarifier les choses !

Par avance je vous présente mes excuses : c'est un peu long :-/

Essayons de repréciser un peu les choses

Flash

Flash est une machine virtuelle s'exécutant dans les navigateurs et permettant d'exécuter des programmes écrits en ActionScript, un langage cousin de JavaScript, mais ayant évolué vers une forme plus robuste et plus proche de la Programmation Orientée Objet telle qu'on la rencontre dans les autres environnements (.Net, Java,...)

Un navigateur embarque nativement différents interpréteurs : html, JavaScript, CSS. Le Flash Player se rajoute généralement après coup sous forme de plugin, mais certains navigateurs, comme Google Chrome, le contienne en standard.

Pas de Flash plugin sur iOS

La première rupture entre le monde du desktop et du mobile se situe ici : depuis l'origine, Apple n'a pas souhaité supporter l'installation de plugin dans les navigateurs de ses mobiles.

Cela interdit sur iPhone-iPad le Flash Player, mais également tous les systèmes d'extensions que l'on peut connaitre sur Firefox, Safari, Chrome. Cela ne permet pas non plus les applets Java et je ne crois pas d'ailleurs que Java en soit mort pour autant à la date d'aujourd'hui.

Quelles conséquences ?

Donc, pas d'exécution de programmes Flash sur un mobile Apple.

Le constat est simple : quelle société ira investir pour créer du contenu mobile avec Flash qui sera dans l'impossibilité de s'exécuter sur iPhone-iPad ?

Réponse : personne. Le marché mobile prédominant aujourd'hui en terme de contenu est encore iOS.

Conclusion : privé d'iOS, le lecteur Flash dans le navigateur ne présente plus aucune pertinence économique.

Que ce soit en raison de l'entêtement d'Apple ou d'un échec technologique d'Adobe importe peu au final. Adobe n'a fait qu'entériner une réalité.

Le problème, comme l'ont souligné nombre de commentateurs (se reporter au lien Adobe Communication en fin d'article), réside dans la déplorable communication d'Adobe et le manque de confiance qui en résulte envers l'ensemble de la plateforme Flash.

Et les applications autonomes ?

Comme je l'ai déjà écrit ailleurs, le marché des utilisateurs de mobiles tranche pour l'instant en faveur des applications autonomes, celles qu'on télécharge et qu'on installe sur son appareil, au détriment des applications dans le navigateur. 

Or, pour réaliser une application native il faut un développement pour chaque plateforme :

• en java pour Android avec le SDK de Google et un IDE comme Eclipse
• en Objective C pour iOS avec le SDK d'Apple et l'outil XCode d'Apple

Conséquences : complexité technologique, problème économique du double développement, évolutivité ralentie.

Un peu d'AIR

Adobe propose justement une technologie multiplateforme apportant une réponse à ces problèmes : le développement d'applications ActionScript packagées en applications autonomes avec intégration du runtime AIR.

Qu'est-ce que cela signifie ?

• on développe dans un seul environnement (Flash Professional ou Flash Builder suivant le type d'application)
• en utilisant un seul SDK, celui d'Adobe qui abstrait les particularités de plateforme
• dans un seul langage, ActionScript.

On voit que l'analyse économique est ici complètement opposée à celle du lecteur Flash pour mobile : avec une seule technologie, on cible au contraire les deux principales plateformes du marché !

C'est que certaines personnes de chez Adobe tentent d'expliquer, un peu noyées dans la masse de buzz suscité par les annonces du 9 novembre 2011 :

Thibaud Imbert : 

"We are not stepping out of the mobile space with Flash, we are just focusing on what makes sense and where Flash looks great, standalone apps with AIR."

Et Flex alors ?

Ok :

• ActionScript un langage de développement,
• Flash un moteur d'interprétation dans le navigateur, la partie abandonnée pour mobile
• AIR un socle d'exécution, permettant de déployer des applications multiplatformes.

Mais qu'est-ce que Flex alors ?

Flex comprend plusieurs aspects : MXML + SDK + outils

• MXML est un langage déclaratif d'éléments d'interface et de composants. Basé sur XML, ce langage très expressif permet de réduire considérablement les lignes de code à écrire pour décrire une interface.
• le SDK (ensemble de classes comme peut l'être Microsoft .Net par exemple, mais en open-source) apporte les fonctionnalités nécessaires aux applications.
• des outils compilateurs, packagers,...viennent compléter l'ensemble.

Schéma récapitulatif

Conclusion

D'un point de vue économique, il n'était plus justifié de continuer à proposer le lecteur Flash pour navigateur mobile puisqu'il ne s'exécutait pas sur iOS : ite missa est. Adobe a officialisé ce constat.

Pour les mêmes considérations économiques, au lieu de développer plusieurs applications autonomes pour les différentes plateformes mobiles, il est raisonnable de rechercher une solution unifiée. Adobe en propose aujourd'hui deux : l'une basée sur Flex-AIR et l'autre sur HTML5-CSS-JavaScript avec PhoneGap. J'estime pour ma part qu'aujourd'hui l'offre Flex-AIR est plus mature, mieux outillée et au final plus efficace que son homologue html5.

D'autres propositions existent démontrant la pertinence de l'approche multiplateforme : Appcelerator Titanium, Alcatel Lucent OpenPlug, etc.

Après cette démarche de clarification, retournons aux projets d'applications mobiles AIR qui nous attendent !

Pour aller plus loin

Sujet déjà abordé dans plusieurs articles de ce blog

2011 l'année des applications mobiles d'entreprise

Proof of concept sur iPhone/Android avec Elips Studio

Du mobile multiplateforme avec Flex 4.5 - 1ère partie -

historique Flex

Du mobile multiplateforme avec Flex 4.5 - 2ème partie -

(posté le 11 février ... avec la première copie d'écran de l'application Westerns, fil rouge du livre "Flex 4.5 pour mobiles")

Dans le livre "Flex 4.5 pour mobiles"

• Avant-propos
• Chapitre 1 : La plateforme Flash

Quelques liens en relation :

• Comparatif de vitesse de quelques fonctions graphiques entre HTML5-CSS et Flash
• A Humbled Adobe Sees Beyond The Browser : " they create two interconnected tracks – the direct to PC track and the direct to mobile track. Each track would presumably start at the same point and the differences in coding and development would be trivial, allowing an Adobe user to make a rich app on the desktop and the mobile device at the same time."
• Adobe Communication "Adobe’s press release (that’s what it essentially is, even though it’s nominally a blog post) sounds sterile, aloof, disconnected and tentative - perhaps even with a note of desperation. I decided to rewrite it."
• Une analyse pertinente de Fred Cavazza

Permalink | Leave a comment  »

Avec l'équipe d'Agile Morbihan, nous sommes en pleine préparation de l'étape Agile Tour Vannes le jeudi 17 novembre (la semaine prochaine à la date de rédaction !).

En revenant de la journée Web et Entreprise à Lorient, organisée par Lorient Technopole Innovations, nous nous sommes dit avec Dominique de Prémorel qu'il serait sympa d'afficher un nuage de mots-clés calculé d'après les tweets émis pendant la conférence Agile Tour Vannes (#atvannes). Il est déjà prévu d'afficher les tweets sur un tweet wall, mais le nuage de mots apporte une dimension graphique et synthétique supplémentaire.

Après une petite promenade sur Google, voici les briques que j'ai rassemblées.

Construire le nuage de points

J'ai utilisé le service www.wordle.net qui utilise une applet Java pour construire le rendu graphique d'après un flux RSS, un nom del.icio.us ou un extrait de texte.  Sur mon Mac, je n'ai pas obtenu de résultat probant avec les navigateurs basés sur WebKit, mais dans Firefox l'applet a fonctionné, quoique crashant le navigateur après chaque utilisation...

Récupérer le flux RSS de Twitter

Étape suivante, il me fallait récupérer le flux RSS d'une recherche Twitter.

Twitter apportant régulièrement des modifications dans son fonctionnement, les premières manipulations retrouvées sur Google se sont révélées obsolètes.

J'ai finalement trouvé la mine d'or : un article paru sur the Sociable qui décrit les différents moyens de récupérer les flux RSS de Twitter. Sur une autre page du site, vous pouvez même trouver des formulaires web vous facilitant la vie pour les différentes opérations !

Au final, pour obtenir un flux RSS des tweets mentionnant atvannes, il suffit de requêter : http://search.twitter.com/search.rss?q=atvannes.

Attention, la chaîne de recherche doit être url-encoded.

Il ne reste plus qu'à fournir cette url au service wordle et le tour est joué. Nous allons pouvoir afficher en direct les tweets et à fréquence régulière l'évolution du nouage de mots-clés correspondant !

En bonus

• Topsy, un site qui propose une recherche dans les tweets.
• Un outil en ligne pour encoder une url sur le site d'Albion Research.
• Un autre service pour retrouver un twitter id depuis un nom d'utilisateur.

Permalink | Leave a comment  »

Il arrive souvent que l'on réalise une application mobile pour smartphone et qu'on la porte ensuite sur tablette.

Comment l'application s'adapte-t-elle à cette nouvelle largeur d'écran ?

iOS

Si l'application n'a pas été adaptée spécifiquement pour l'iPad, iOS propose de la faire fonctionner à sa taille iPhone, centrée à l'écran, sur fond noir. 

C'est ce que l'on constate sur cette copie d'écran de l'application Eurosports (à noter qu'existe une version spécifique iPad).

Une pastille affiche un bouton 2x qui permet de zoomer pour exécuter l'application à la taille de l'écran de l'iPad, au prix d'une pixellisation notable.

Pour Flex Mobiles ?

Le choix de la cible (iPhone et/ou iPad) se paramètre dans le fichier de description de l'application. Voici un exemple de paramétrage pour une application compatible avec les deux cibles de la plateforme iOS :

<iPhone>

<InfoAdditions><![CDATA[

<key>UIDeviceFamily</key> 

<array><string>1</string><string>2</string></array>

]]>

</InfoAdditions>

<requestedDisplayResolution>high</requestedDisplayResolution>

</iPhone>

Le tableau qui suit la clé UIDeviceFamily permet de restreindre ou non le support à une gamme donnée.  La chaine ci-dessous restreindrait à l'iPhone :

<array> <string>1</string> </array>

La chaîne <requestedDisplayResolution>high</requestedDisplayResolution> indique quand à elle si l'application utilise la définition standard 320x480 ou peut s'adapter au 640x960 (tout en continuant à s'afficher en 320x480 sur le 3GS).

Se reporter à la documentation d'Adobe :iOS Settings, http://help.adobe.com/en_US/air/build/WSfffb011ac560372f7e64a7f12cd2dd1867-80...

Et sur Android ?

Étirer ou zoomer

Depuis Android 3.0 (Honeycomb), la version du système de google conçue pour tablette, Android propose un redimensionnement automatique de l'application à la taille de l'écran.

Un article du monde informatique présentait cette fonctionnalité au moment de son annonce : http://www.lemondeinformatique.fr/actualites/lire-google-va-redimensionner-le...

La version 3.2 du système propose le choix entre étirer l'affichage de l'écran pour remplir l'écran (comme en 3.0) ou zoomer (équivalent au mode zoom 2x de l'iPad) :

Pas le choix donc de pouvoir exécuter l'application à sa taille initiale comme sur l'iPad.

Et pour les applications adaptées ?

Si vous avez fait l'effort d'adapter l'application à un écran de tablette, vous souhaitez sans doute vous débarrasser de la possibilité de zoomer.

Il suffit pour cela de rajouter une déclaration supplémentaire dans la section Android du fichier de description :

<android>

<manifestAdditions><![CDATA[

<manifest android:installLocation="preferExternal">

<supports-screens android:xlargeScreens="true" />

...

Cette option est décrite dans la documentation proposée par Google dans la section indiquée ci-dessous :

http://android-developers.blogspot.com/2011/07/new-mode-for-apps-on-large-scr...

Cette chaîne ne figure pas par défaut dans le fichier de description généré par Flash Builder. Cependant, lors de la préparation du package .apk, la totalité de la section manifestAdditions est recopiée dans le fichier attendu par Android pour déterminer les pré-requis de l'application. Il suffit donc de la rajouter manuellement dans votre fichier de description AIR. 

A partir d'Android 3.2, il est également posible de spécifier dans l'élément <supports-screens> un nombre minimal de pixels. Par exemple, android:requiresSmallestWidthDp="600" va imposer un minimum de 600 pixels, ce qui correspond généralement à une diagonale de 7".

L'article Preparing for Handsets décrit très bien les différentes options disponibles ainsi que les techniques de compatibilité d'interface entre smartphone et tablette, mais ceci est une autre histoire !

Conclusion

Il est important de se familiariser avec les différentes sections du fichier de description pour garantir un bon déploiement sur les différents mobiles.

La documentation d'Adobe ne suffit pas forcément, car certaines options proposées par iOS ou Android sont décrites uniquement dans leur documentation respective.

A consulter l'article de Samir Moussouni "Applications Flex/AIR : mode zoom sur tablettes Android".

Permalink | Leave a comment  »

Un service intéressant...

Je maintiens depuis plusieurs mois maintenant un sujet sur Scoop.it! : Développement mobile avec Flex 4.5 (anciennement Flex 4.6). Lors de différents événements, plusieurs personnes m'ont fait part de l'intéret qu'ils trouvaient à ce travail permettant de suivre l'actualité autour de ce thème.

...mais une formule payante dissuasive

A l'occasion de sa sortie officielle, le service Scoop.it! est récemment devenu partiellement payant. Sa formule "biz" est à 79$ par mois. Elle comprend en particulier l'option d'ajouter des sources d'information à un sujet. 

N'ayant pas 79$ par mois à dépenser pour pouvoir ajouter de nouvelles sources d'information, le thème "Développement mobiles avec Flex 4.6" ne va pas pouvoir évoluer.

Déception

Je suis assez déçu de la stratégie consistant à proposer un service en version béta pendant une longue période de manière à ce que les utilisateurs qui y ont investi du temps, et donc contribués au succès du service, se sentent "fortement poussés" à évoluer en version payante lors de la sortie de la version finale.

C'est décevant et démotivant.

Néanmoins, je vais continuer au moins jusqu'à la fin de Flex 4.6 à effectuer la curation sur la base des sources existantes.

Permalink | Leave a comment  »

Je me suis donné comme ligne de conduite de systématiquement essayer d'utiliser un service en ligne lorsque je suis à la recherche d'un outil.

Dans le cadre de l'accompagnement d'une équipe à la migration vers la plateforme Flex, j'ai eu besoin de dessiner un digramme de séquence pour illustrer le refactoring en cours.

J'ai découvert WebSequenceDiagrams.com qui répondait tout à fait à mon besoin avec une interface originale et assez rapide à prendre en main. Une aide en ligne est également proposée.

Le principe de fonctionnement est de décrire les interactions par du simple texte et d'obtenir en dynamique la représentation correspondante.

Voici par exemple la description textuelle du diagramme ci-dessous :

Utilisateur 1->Logiciel de contrôle 1:Ecrire(message)

Logiciel de contrôle 1->Module XBee 1:Envoyer(message)

Module XBee 1->Module XBee 2:Envoyer(message)

Module XBee 2->Module XBee 1:Acquittement()

Module XBee 1->Module XBee 1: EffaceMemoire()

note right of "Module XBee 1"

Communication

sans-fil

end note

Un étudiant en master (François Tessier) a consacré à ce service un article de blog d'où est extrait le diagramme ci-dessus. Je vous invite à lire son billet pour découvrir le fonctionnement du site. 

Connaissez-vous d'autres outils de ce type ?

Permalink | Leave a comment  »

10 ans d'agilité

(photo publié sur Confessions of a ScrumMaster )

L'agilité a 10 ans.

Réunis en 2011 dans un chalet à Snowbird, Utah, 17 spécialistes du projet logiciel s'accordaient sur le manifeste Agile, décliné en 4 valeurs et 12 principes.

Plusieurs méthodes ont popularisés cette révision du processus de développement. En France où le RAD avait ouvet la voie, Extreme Programming (XP) et Scrum sont les plus connues.

Si vous souhaitez vous familiariser avec ce domaine, je vous conseille d'investir une journée dans une étape de l'Agile Tour. Animés par des intervenants très variés, vous y suivrez conférences, ateliers, retours d'expérience.

Je propose par exemple lors de l'étape vannetaise une table ronde sur les 10 ans du manifeste agile afin de faire le point sur l'évolution des mentalités et des pratiques.

Sans rentrer dans le détail, on peut retenir des pratiques agiles quelques fondamentaux comme le fait cet article d'indexel (Méthodes agiles : du dogme au pragmatisme) :

• relation permanente avec les utilisateurs, 
• livraisons régulières de versions de l'application, 
• itérations incrémentales
• mode de travail horizontal, avec une responsabilisation de chaque développeur. 

L'agilité pour réussir la mobilité 

Si l'approche agile gagne de plus en plus de terrain et bénéficie désormais d'une véritable reconnaissance, il apparaît que la révolution apportée par les mobiles connectés et tactiles devrait conforter ce mouvement.

Après la déferlante des applications grand public, les entreprises commencent à investir dans le portage de modules métier vers les tablettes et smartphones.

Pour la plupart des développeurs d'applications métiers, cela représente un saut dans l'inconnu. On ne concçoit pas un programme pour mobile comme une application bureautique traditionnelle. Contraintes de tailles d'écran, de batterie, d'interaction tactile, prise en compte de la fameuse expérience utilisateur : une nouvelle culture est à acquérir. 

De plus en plus de témoignages préconisent l'adoption d'une démarche agile pour faciliter ce processus et limiter les risques d'échec. Je prendrais deux exemples.

Un article paru sur le site de programmez.com : La révolution du mobile d'accord, mais pas sans applications sous la plume de Laurent Henault, Président de W4.

"...proposer des développements mobiles rentables et accessibles. Un tel processus est possible et passe par l’agilité. Plus qu’un simple concept fumeux, ce terme doit permettre à des équipes de toutes tailles de développer aisément sur tout type de plate-forme en maîtrisant leurs temps et coûts de développement."

"Grâce à ces dernières, il apparaît que les cycles de création et de mise en production sont réduits de 30 %, ce qui constitue un élément stratégique dans le lancement de nouveaux projets."

J'ai recueilli l'autre référence lors d'un atelier proposé par ENI Services : Transformez vos applications métiers en applications mobiles.

Dans cette très intéressante demi-journée, David MAURANGE, directeur Technique de la société Adeuza, abordait le thème "Une organisation projet adaptée" :

"Les interlocuteurs ne connaissent pas forcément les possibilités et l'ergonomie de la plateforme cible"

S'appuyant sur ce constat, il préconise également de recourir à une approche agile pour aborder ce nouveau contexte applicatif.

Évolution des pratiques

Ainsi, l'évolution de l'interaction de l'utilisateur avec le système informatique apportée par les terminaux mobiles devrait également se traduire par une modification progressive de la manière même de concevoir le processus de développement logiciel.

Une perspective qui me réjouit !

Permalink | Leave a comment  »

19 octobre 2011, sortie de mon livre "Flex 4.5 pour mobiles"

Voir la présentation en ligne sur le site de l'éditeur DUNOD.

Dans cet article :

• je fournis des liens vers un diaporama de présentation du contenu de l'ouvrage, disponible sous différents formats (PDF, MP4, slideshare).
• Je donne quelques compléments d'information sur le livre et sa couverture fonctionnelle.
• Enfin, j'introduis la formation associée.

Présentation du contenu du livre

Vous trouverez ci-après un diaporama de présentation du contenu du livre sous trois formats différents.

• PDF

PresentationLivre.pdf Download this file

• mp4 (diaporama avec son au format iPad)

PresentationLivre-1.ipad.mp4 Watch on Posterous

• SlideShare (diaporama en libre accès sur le service de partage SlideShare)

Site de ressources en ligne

Vous trouverez sur Flex4.5 pour mobiles des ressources complémentaires :

• bibliographie pour chaque chapitre
• téléchargement des versions à jour des différents projets (avec corrections de bugs après rédaction)
• chapitre supplémentaire au format pdf
• liste des fonctionnalités de l'application westerns
• possibilité de laisser un commentaire par chapitre

Contraintes de pagination

La rédaction de ce livre a commencé fin février en utilisant la version béta de Flex 4.5, nom de code Hero.

Initialement Hero ne permettait de déployer que sur Android, le support d'iOS est apparu assez tardivement et a donné lieu à une ré-organisation assez importante du livre.

Les contraintes de pagination de la collection InfoPro chez Dunod imposaient de demeurer dans les 300-320 pages. Il est malheureusement apparu nécessaire de retirer certains chapitres déjà écrits.

Ont par conséquent disparu de la version finale les trois chapitres suivants :

1) Explorateur de fichiers, un exemple d'application du mécanisme de navigation ViewNavigator à la réalisation d'un explorateur de fichiers.

2) Styles, la présentation de la manière d'appliquer des styles CSS aux différents composants d'une application.

3) Versions de débogage et de déploiement, la description des possibilités de débogage et de déploiement en fonction des différentes plateformes ainsi que les réglages disponibles.

Ce dernier chapitre est fourni au format PDF dans les ressources complémentaires disponibles en ligne.

Pour les deux autres, j'envisage de les adapter ultérieurement pour publication sur ce site.

Ce que le livre ne couvre pas...

Trois chapitres en dépassement, ll fallait faire des choix drastiques sur la couverture fonctionnelle !

Ont donc été écartés du livre :

• les sujets avancés comme l'habillage (skinning) de composant, qui sont traités dans d'autres ouvrages sur Flex 4;
• les sujets non spécifiques à Flex comme la publication des applications vers les magasins en ligne, couverts par nombre d'articles sur le Web;
• la réflexion sur l'architecture à retenir pour des applications multi-écrans. Ce dernier point devrait faire l'objet d'articles complémentaires actuellement en cours de rédaction.

Formation associée

Ce livre est conçu de manière à permettre au lecteur de l'utiliser comme un manuel d'auto-formation en suivant la progression des différents exemples proposés. Pour chaque chapitre sont fournis le projet avant modification et le projet résultat. En cas de problème, il est donc toujours possible de se reporter à la solution.

En outre, je propose une formation de 3 à 5 jours basée sur le contenu du livre et disponible en inter ou en intra.

La durée de la formation dépend des connaissances initiales de la plateforme Flex et de la programmation objet. Pour tout renseignement, me contacter par email : ckeromen[arobase]ckti.com.

Cette formation est également au catalogue de l'organisme de formation ENI.

Le livre en rayon (photo prise par J-F Lafut, éminent relecteur) :

Permalink | Leave a comment  »

Mon besoin

Dans le cadre du développement d'un utilitaire AIR, j'ai eu le besoin de devoir envoyer un mail ou un SMS vers un destinataire. Pour que l'utilitaire ne soit pas dépendant d'une installation sur une machine, je ne souhaitais pas utiliser un serveur de mail local. Pour que l'envoi ne dépende pas de la disponibilité d'un serveur propriétaire, je recherchais plutot un service proposant une API. Et puis, c'est devenu une démarche, je recherche d'abord un service en ligne avant une application à télécharger, installer, paramétrer, etc.

Service Orange

J'ai découvert qu'Orange proposait un ensemble d'API très intéressantes dont un service d'envoi d'emails.

Ce n'est pas une nouveauté, mais pour ma part, je n'ai eu ce besoin qu'hier. Aussi, j'ai pensé à partager cette expérience dans un court billet.

Voici la présentation du service sur leur site :

L'API email est un service Web vous permettant d'envoyer et de recevoir des emails.Orange vous fournit une boîte mail de 500Mo.  Sachez toutefois que votre identifiant (API Access Key) devra toujours être passé en paramètre dans l’URL de votre requête.

Le service web expose une interface dans un style REST-RPC.

Les requètes utilisent indifféremment les méthodes GET ou POST en mode HTTP ou HTTPS.

Le service est gratuit, Orange vérifiant simplement que vous n'êtes pas un vilain spammeur :

Principes de facturation de l'API email :

• l'API email est gratuite
• le nombre de requêtes par utilisateur et par jour est contrôlé

A noter cependant, qu'il s'agit d'une version alpha et que la version finale peut devenir payant. A surveiller.

Retour d'expérience

L'inscription en ligne est très rapide, permet de récupérer l'identifiant nécessaire à l'envoi des requêtes. La mise en oeuvre est ensuite très simple puisqu'il s'agit d'une simple requête HTTP Get avec passage des paramètres dans la quesrystring. 

http://run.orangeapi.com/mail/sendMail.xml?id=[api access key]&from=[votre nom]&to=[adresse email de réception]&subject=[ objet de l'email]&body=[corps de l'email]&cc=[addresse email en copie]&bcc=[adresse email en copie cache]&replyTo=[adresse email de réponse]

En ActionScript, une requête avec URLLoader convient très bien, mais toute application capable d'émettre une requête HTTP peut ainsi bénéficier de cette API.

L'email semble envoyé immédiatement, je n'ai pas noté d'attente dans mes tests.

En revanche, la charte graphique d'Orange rend certaines pages quasiment illisibles (en particulier le gris clair), obligeant à copier-coller la doc vers un autre support. 

Autres APIs

Si mon besoin ponctuel se limitait à envoyer des mails, l'API est plus complète puisqu'elle permet de gérer complètement l'aspect envoi-réception de mails :

Vous pouvez ainsi :

• envoyez et recevez des emails
• gérez votre boîte de réception
• comptez et répertoriez vos emails

Une API identique existe pour les SMS, mais elle est payante (à partir de 1 centime par SMS).

Enfin, toutes les APIs se trouvent sur une page dédiée.

Bref : j'ai pu envoyé mes emails grâce à Orange !

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Plusieurs prévisions intéressantes dans ce rapport de Forrester cité par le monde Informatique http://www.lemondeinformatique.fr/actualites/lmi/lire-selon-forrester-60-mill...

1) l'équipement mobile est majoritairement professionnel

Selon le cabinet, près de la moitié des smartphones et 70% des iPad qui sont utilisés au travail actuellement, sont achetés par les employés. 

Les applications métiers vont devoir s'adapter à cette utilisation professionnelle sur mobile.

2) Penser mobilité

La solution préconisée par le cabinet est de créer des outils mobiles efficaces et de les proposer sous le format d'un service Cloud.

client mobile + services dans le Cloud, l'architecture à mettre en place pour ces applications 

3) un tiercé d'OS gagnant

au moins trois systèmes d'exploitation de mobiles devraient remporter l'adhésion des utilisateurs sur le lieu de travail : l'iOS d'Apple, l'Android de Google et le QNX de RIM. 

L'étude serait-elle commanditée par Adobe ? Ce sont précisément les trois systèmes supportés par Flex 4.5.

Et hp WebOS ?

Permalink | Leave a comment  »

Just noticed these mobile related features in new beta versions : http://www.bytearray.org/?p=3216

Feel free to complete by commenting.

Native Text Input UI (mobile) 

Mobile apps can now take advantage of the native text input controls on mobile platforms, including platform-specific user interaction behaviors such as magnification and text selection. Native text controls are available on Android, BlackBerry Tablet, and iOS operating systems.

Stage Video Hardware Acceleration (new for AIR)

Leverage hardware acceleration of the entire video pipeline to deliver efficient, best-in-class high-definition (HD) video playback experiences. Decrease processor usage and enable smoother video, reduced memory usage, and higher fidelity on mobile*, desktop, and TV devices (*supported on Android 3.1, BlackBerry Tablet OS, and iOS).

Permalink | Leave a comment  »

A l'invitation de Michael Chaize d'adobe, j'ai eu la chance de participer à l'événement Meet the BlackBerry PlayBook.

Co-organisée par RIM et Adobe au Méridien Etoile, l'annonce officielle de la sortie de la tablette BlackBerry PlayBook en France réunissait décideurs et développeurs pour une après-midi de présentations. Retrouvez l'annonce de l'évènement : http://tinyurl.com/43kxu4y.>

Riche après-midi

Devant une salle bien remplie, de 13h à 15h30 se sont succédés des intervenants de RIM (Directeur général, directeur Marketing,...), puis Michael a présenté la stratégie d'Adobe pour les solutions multi-écrans. Il a insisté sur l'importance de la collaboration entre Adobe et RIM dans le cadre de l'Open Screen Project afin d'optimiser les performances du Flash Player sur la tablette du constructeur canadien : http://www.openscreenproject.org/.>

Dans l'assistance, du beau monde Flex : Yann Chevalier de BaaO (notre tonton à tous : http://groups.adobe.com/people/35149/profile), Fred Bardin des Tontons Flexeurs de Limoges (http://ttfxlimoges.com/), PhilFlash (http://philflash.inway.fr/), Stéphane Entem (passionné des surfaces tactiles : www.brainfinger.fr) et bien d'autres...

Coordonnés par Michael, trois témoignages sur Flash/Flex et PlayBook se se sont succédés :

• Alexis Kartmann, CTO KapIT (http://www.kapit.fr), illustrant à la fois le côté professionnel de la tablette et le multiplateforme de Flex par des démos de ses composants de charting dans le navigateur et en appli AIR;
• Nicolas Gans (nicolasgans) de Regart.net (Regart.net) présentant un casual game en Flash (devinez quoi ? massacrer des zombies) et ses techniques d'optimisation;
• moi-même, Christophe Keromen, sur un retour d'expérience Flex 4.5 et Playbook 
  • (voir  FindMovies : Exemple d'application pour Blackberry Playbook  et  FindMovies v1.1 for Android ) sur ce site.
  • Ce fut également l'occasion d'annoncer la parution à la rentrée chez Dunod de mon livre "Développer des applications mobiles avec Flex 4.5".
  • J'ai également mentionné l'aggrégateur d'articles autour du Développement mobile avec Flex 4.5 que je maintiens grâce au projet Scoop.it! : http://www.scoop.it/t/developpement-mobile-avec-flex-4-5 : 1450 visiteurs, 429 articles référencés à la date de rédaction.

Les qualités reconnues au PlayBook

Une tablette puissante et bien dotée

Puissance, qualité de l'OS multitâche (TabletOS), de la vidéo (HDMI), de la prise d'images (deux caméras) sont parmi les éléments techniques qui emportent l'adhésion lors de la découverte de la tablette de RIM.

L'ouverture comme élément de différentiation

Comme le mentionne RIM, par opposition à d'autres constructeurs qui s'enferment dans leur technologie ("désolé, je peux pas échanger avec toi, t'es pas sur iOS 5"), le PlayBook, pas sectaire, ne rentre pas dans les guerres de tranchées technologiques :

BlackBerry Playbook prend en charge les WebKit, Adobe Flash, HTML 5, Java®, Adobe Mobile AIR et est compatible avec les applications Androïd 2.3.

Un positionnement par rapport à AIR original

RIM avec TabletOS propose une intégration avec AIR sans équivalence :

• pré-installation du Runtime AIR dans l'OS
• fournitures d'applications-maison réalisées en AIR
• mise à disposition d'un simulateur performant et sur lequel il est possible de déployer/déboguer en un clic depuis Flash Builder 4.5.x
• disponibilité d'un SDK complémentaire de celui de Flex 4.5.x permettant de prendre en compte les particularités de la tablette (ainsi de certaines gestuelles), mais aussi de mieux s'intégrer à son environnement (contrôles natifs, gestion de la batterie, etc.)
  • le PlayBook est ainsi aujourd'hui le seul mobile qui permette de récupérer l'identifiant du périphérique dans une application AIR, ouvrant la voie à une meilleure identification de l'utilisateur (sécurisation de transactions).

Le premier d'une gamme ?

Je ne sais pas si RIM déclinera dans le futur le Playbook en d'autres dimensions. Quelques annonces ont été faites lors de la conférence, comme la sortie d'une future version 4G s'affranchissant du bridge avec le téléphone BlackBerry et embarquant plus d'applications comme un client de mail.

Cette contrainte d'utilisation du bridge limite aujourd'hui l'intérêt de la tablette pour les utilisateurs d'autres marques de smartphones.

Clairement, RIM se positionne avec un premier produit plein de qualités, présentant des défauts de jeunesse, mais qui servira également à récolter des retours d'expérience pour l'avenir.

Personnellement, je trouve en tout cas très encourageant l'implication du canadien pour l'avenir des ardoises numériques dans le monde professionnel.

Quelques liens pour plus d'infos :

Screencast de la répétition de ma démo : 

View on screencast.com » 

Ma présentation sur slideshare : http://tinyurl.com/3wucddn.

Les photos sont celles du projet "Solar Impulse". J'ai eu la chance d'assister à une présentation de son projet par Bertrand Piccard lors des LeWeb'10 Paris (About | LeWeb'10). Impression très marquante !

Un peu stressé, (ou parce que je n'osais pas sortir de matériel Apple) j'ai oublié de prendre des photos :-(

Permalink | Leave a comment  »

FindMovies is an example of Adobe Flex 4.5 development for mobile. First version has been  designed for Blackberry Playbook with Max pre-relase version of the Flex SDK.

Version 1.1 is a simple adaptation for Android phones with no extra-features, nor taking advantages of later possibilities of the SDK. It's simply a Proof of Concept of having the same application running on several platforms.

Below are some screenshots of the application running on my HTC Desire :

See the full gallery on Posterous

Click on me to upload FindMovies on your Androphone...

Just confirm the following dialog (french version in the screenshot below) to allow the application to get access to the Internet and store information on the SD Card (this version doesn't store anything, but future version will store some user data).

Please let me know in case of problems happening on your particular device.

As soon as possible (aka when the corresponding version is made available by Adobe), I will post the iPhone release.

To go further

I manage a portal dedicated to blog articles and tutorials related to Flex 4.5 mobile development:

http://www.scoop.it/t/developpement-mobile-avec-flex-4-5/

For french readers, I'm preparing a book to be published by Dunod at fall.

Permalink | Leave a comment  »

v2 modified on 2011-04-18

- added 2 other tests results and some moderations

Subtitle: the interest of compression

- César : Compression motocyclette, circa 1970 -

What kind of communication between 4D and Flex?

On 4D-Flex Google group, there was a question about AMF availability for 4D Server. The developer asking for a communication solution between Flex and 4D was referencing WebOrb web site.

Only HTTP and SOAP

Unhappily, there is no support for AMF in 4D, neither from the editor nor from the community. And due to the very nature of 4D language which is not OOP, I'm afraid there is not going to be one.

Apart from HTTP and SOAP support, 4D made an attempt to provide a direct connected SQL driver for Flex : 4D for Flex. Despite an initial interest from the community, it seems that this product didn't find its way to success.

Two main reasons are maybe :

• lack of support from Adobe of encrypted sockets communication in the Flash Player;
• reluctance to embed SQL statements inside Flash app.

So, for 4D we stay with SOAP and XML over HTTP.

 AMF performances?

But, having a glance at webOrb web site after this initial question, I noticed an inline Flex application for comparing HTTP - SOAP- AMF. So, I tried.

And these are the results I got :

Not showing a tremendous superiority of AMF over the two other modes. Some noticeable gains can be expected, mostly for complex types, but for the two other tests, it's not convincing so superior, though results may vary a lot from one test session to another one.

Don't forget that the test are iterated several times, so depending on the kind of request, for a real project the AMF performance may not be really awesome for one request. Especially, if the request doesn't carry large streams.  

In the case of large streams, you can really increase http performances using gzip compression, with no-extra coding effort as it is supported at the browser level.

So, is AMF such a winner?

PhilFlash great blog entry

On the same subject, Philippe Kirsch (philflash), a great French Flex Developer, has published a detailed entry on his PhilFlash blog : Flex HTTPService performance avec MySQL et PHP : XML : 1 - AMF : 0. Though it is written in french, I advise the reader to parse this page. There are code samples and you should get the main facts.

Here is the final chart showing the results of his testing:

If you consider the result for gzipped streams, it appears that the lack of AMF support for 4D Server seems not to be such a big deal.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Cibler la tablette Blackberry Playbook avec Flex 4.5

J'ai déjà développé des exemples d'application iOS avec Openplug Elips Studio, et Android avec Flex 4.5. Je n'avais pas encore abordé la tablette Blackberry Playbook.

C'est désormais chose faite : la vidéo jointe à cet article montre une application développée avec la Preview Hero de Flex 4.5 s'exécutant dans le simulateur de la Blackberry Playbook. 

Téléchargement depuis le site de screencast.com : 2011-03-29_FindMovies

Pour plus d'information sur le développement avec Flex pour la tablette de RIM, le site de Blackberry constitue un bon point d'entrée.

Plusieurs excellents tutoriaux ont été publiés, je liste ci-dessous des valeur sures :

• Riagora de Michael Chaize
• www.flex-tutorial.fr de Fabien Nicollet, LE site de tutoriaux Flex en français
• le blog de Renaun Erickson, Adobe Developer Evangelist
• un article en anglais décrivant tout le processus : PROCRASTINATOR’S GUIDE TO A FREE BLACKBERRY PLAYBOOK

Attention :

• Aux icônes ! Lisez-bien la description de l'icône attendue pour l'application : Designing application icons. Je me suis fait piéger sur la première soumission avec une icône à 86x86. Merci à @dimitri_k pour le lien vers Icon Maker for BlackBerry PlayBook qui permet de générer une icône respectant les guidelines de RIM. Prévoir également une icône de 480x480 pour la soumission !
• Aux copies d'écrans qui ne doivent pas dépasser 640x640. Bien entendu, j'avais également zappé ce détail et tandis que d'une main je soumettais les copies d'écran, de l'autre je les mettais à l'échelle vite fait !

Conclusion de cet essai : 

Pas de problème particulier à signaler, sinon la multiplicité des téléchargements avant de démarrer : SDK, machines virtuelles, images disque, etc.

En particulier, il faut installer VMWare Fusion sur Mac pour exécuter l'image disque du simulateur. Un peu pénible, d'autant plus qu'il s'agit d'une version d'évaluation limitée dans le temps.  Comme j'ai déjà une licence Parallels, je rechigne à faire collection d'émulateurs sur ma machine juste pour charger un simulateur...

Une fois ce moment un peu pénible dépassé, le développement s'effectue avec les habitudes déjà acquises pour les applications Android. Le déploiement dans le simulateur RIM est à une portée de clic et l'application y fonctionne exactement comme dans le simulateur ADL d'Adobe AIR.

Je n'ai eu qu'une seule retouche à faire due à une taille de police un peu différente. La réactivité du simulateur est excellente. La prise en main de la tablette virtuelle déroute un peu au début, pas de bouton physique comme sur Android, on cherche désespérément comment revenir en arrière. Mais on a rapidement envie de pouvoir tester sur le modèle physique. Bonne nouvelle dans la boîte mail ce matin : "Success! You’ve completed the first step toward a free BlackBerry PlayBook tablet." Espérons que les autres étapes se succéderont sans anicroche...

- L'application FindMovies dans le simulateur de la Blackberry -

Rappelons que la tablette Playbook sera en vente mi-avril 2011 et que la version 4.5 de Flex est encore en béta à la date de rédaction. Avec la disponibilité des versions finales, le processus de récupération des différents éléments sera moins fastidieux. Mais le résultat obtenu avec les versions d'évaluation apparait déjà extrêmement encourageant.

Le développement multiplateformes mobiles avec Flex devient chaque semaine de plus en plus prometteur et excitant ! Vivement la version Flex 4.5 pour iOS, comme l'annonce Michael Chaize sur son blog : http://codemoiunmouton.wordpress.com/2011/03/29/flex-sur-ios-iphone-ipad-itouch/

Permalink | Leave a comment  »

Un monde presque parfait

Vous êtes prêts à entendre une terrible révélation ?

Le développement de réelles applications Flex ne se passe pas tout à fait comme dans les exemples fournis par Adobe. L'éminent formateur Yann Chevalier nomme ce phénomène désagréable le passage à "la vraie vie".

Or donc, dans la vraie vie que se produit-il ?

Souvent, on commence comme on l'a appris en formation, lu dans des bouquins et vu sur des exemples : MXML, balises <fx:Script> et code de gestion des événements. Ça marche au début, puis au fur et à mesure des ajouts, ça devient un peu complexe à gérer, puis franchement compliqué à maintenir, et enfin carrément l'angoisse à chaque mise à jour.

Hum..du code spaghetti !

(http://www.flickr.com/photos/jbozanowski/with/4116825468/)

Depuis les origines de Flex, les experts tentent d'apporter une solution ultime à ce problème entropique en vulgarisant l'emploi de Design Patterns ou Motifs de Conceptions.

Pour faire simple, il faut apprendre à structurer ses développements. Plutôt que de réinventer le fil à ouvrir les huîtres (oui par chez moi en Bretagne c'est pas l'eau tiède, allez savoir pourquoi), autant ré-utiliser les bonnes pratiques déjà éprouvées, identifiées et répertoriées. Ces bonnes pratiques proviennent essentiellement de la communauté Java et par capillarité se transmettent à la communauté Flex.

Un des grands principes fondateurs, (Programmation Objet, architecture en couches), consiste dans la séparation des problèmes : Separation of Concerns :

"Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer)."

Certaines initiatives vont plus loin encore et proposent directement des frameworks qui garantissent le respect des bonnes pratiques au travers de la mise en oeuvre des Design Patterns. Cet article va présenter ces différentes notions, tout en listant plusieurs ressources couvrant le spectre allant de la théorie vers la pratique.

Les Design Patterns : la théorie

Beaucoup d'autres ont écrit sur ce thème, mais la référence dans le domaine se nomme Martin Fowler. Sur son site et dans ses livres, vous pourrez décortiquer à loisir toutes les subtilités des différentes architectures applicatives. 

Laissez de côté pour l'instant ce qui touche à l'Agilité et au refactoring. C'est passionnant, Martin Fowler constituant une référence également sur ces sujets, mais sinon on ne vous revoit pas avant plusieurs mois !

Le livre qui se rapporte au thème de cert article se nomme Patterns of Enterprise Application Architecture. Les exemples y sont donnés pour Java et C++. :

• Advanced ActionScript 3 with Design Patterns

• ActionScript 3.0 Design Patterns: Object Oriented Programming Techniques

Les Design Patterns : l'application

Si vous êtes un peu pressés ou rebutés par le format papier, plusieurs bloggeurs ont oeuvré pour proposer des tutoriaux d'introduction aux principaux Design Patterns utilisés pour structurer une application Flex. Je vais lister ci-dessous quelques-uns de ces articles concernant l'architecture Model-View-Controller (MVC).

L'industrie informatique n'a pas attendu Flex pour se préoccuper d'architecture logicielle puisque le concept de séparation des couches en MVC remonte à la fin des années 70. Pour les mordus d'histoire, se référer à Wikipedia.

• Je vous conseille également l'article d'Andrew Trice : The Origins of MVC.

"Model-View-Controller (MVC) is a software architectural pattern where an application is broken into separate layers for the data model, the user interface (view), and the business logic. The logic, model, and views are decoupled, and communicate through an intermediary controller. This pattern enables both abstraction of logic, and reuse of code/components throughout the application."

• Understanding The Architecture of a Rich Internet Application par Andrew Trice

Bon article d'introduction qui a, en particulier, le grand mérite d'exposer clairement que dans le domaine des RIA, on parle de MVC sur le client indépendamment de l'architecture MVC du serveur.

Voici un schéma qui tente de résumer cette notion de MVC Server :

• David Deraedt aborde également ce concept dans une série de quatre articles sur Flex Architecture Fundamentals, en particulier dans l'épisode 3 : Designing the Flex application as a Model View Controller.
• Bogdan Serban a posté sur Adobe Developer Connection / Cookbooks / AIR, Flex, un très bon article Simple MVC for Flex and AIR. Il y fait preuve d'un respectable pragmatisme :

"In reality there is no 100% demarcation between these three layers. Is not that easy to make them completely decoupled and usually we end up making some tradeoffs."

et met en application le modèle sur la réalisation de l'ajout de valeurs à une liste :

Voici un autre schéma décrivant l'architecture retenue par l'auteur dans son exemple :

• Une variante, exposée dans Flex Best Practices – Models, Views, and Controllers, propose que le controleur référence la vue :

<controllers:SampleController id="controller" view="{this}"/>

Autre caractéristique forte de cette variante : "the view NEVER directly accesses the model." Principe qui appliqué dans la "vraie vie" peut amener à des conséquences assez importantes sur ce que le controleur doit ré-exposer comme données du modèle. D'autres auteurs préfèrent appliquer directement la directive [Bindable] sur les variables publiques du modèle ce qui, implicitement, entraîne l'émission d'événements en cas de modification.

Cet exemple soulève une autre interrogation importante :

"Some people will argue that the httpservice should be in the model rather than in the controller.”

Pas si simple de ranger ses affaires !

Vous pouvez trouver une traduction en français sur le blog de Fabien Nicollet : www.flex-tutorial.fr.

• L'approche MVCS, décrite par Joe Berkovitz sur son blog et dans une conférence présentée à Max 2006, répond à cette problématique en accolant au MVC la notion de couche Services, responsable de la communication avec l'extérieur :

"Encapsulates all communication with the outside world. Populates Model objects with remote data"

Encore un expert qui prône le pragmatisme lors de l'application des modèles à la vraie vie :

"Since the original MVCS article I have since built a number of ambitious applications. In each one of them I felt it necessary to substantially modify the plain MVCS approach in order to preserve my notions of “right development practice”. "

Universelleu panacée-éhé ?

(http://www.dailymotion.com/video/x22ung_le-sirop-typhon-richard-anthony_music)

Mon retour d'expérience sur ce sujet :

• Tout développeur qui passe plus de quelques jours sur Flex ressent rapidement la nécessité de choisir une architecture pour son codage ou de se renseigner sur la hauteur des ponts environnants.

• MVC est reconnu comme un Design Pattern de base, jusque là tout va bien. 

- Ah mais non, MVC c'est pas suffisant, regarde MVCS.

- Pas du tout, il FAUT adopter Presentation Model, ...

• Dès que l'on creuse un peu le sujet, on s'aperçoit que chacun a sa propre compréhension du motif de conception MVC. 

- La vue référence-t-elle le contrôleur ?

- MVC passif, actif ?

- ...

• Quand l'heure vient d'appliquer à son propre développement ce qu'on pense avoir compris, on se sent généralement envahi d'une terrible indécision : 

- passe-t-on par des événements ou des membres publics ?

- Où range-t-on nos services, contrôleur ou modèle ?

- Comment expose-t-on le modèle à la vue ?

- Où écrit-on la logique métier ?

- Est-ce que je ne suis pas en train de mettre en place un "machin" complètement surdimensionné ?...

Ça vous évoque quelque chose ?

Architecture propre ou frameworks ?

Si vous êtes convaincus par la nécessité d'organiser votre code, demeure cependant le choix de la démarche :

• définir vos propres conventions (au prix d'interrogations existentielles, se référer au paragraphe précédent),

ou

• adopter un framework prêt à l'emploi.

Comme base de réflexion sur la définition de vos propres conventions, je vous recommande la lecture de deux articles de Fabien Nicollet. Fabien y présente son retour d'expérience sur le développement pour mobiles et explique l'architecture qu'il a retenu pour une réutilisation de composants :

• Flex et composants mobile (AIR pour Android – iOS) – Mon approche
• Développement mobile AIR (Approche Flex Tutorial) – Architecture projet

Si vous préférez la démarche éprouvée d'un framework existant, il vous reste à effectuer votre choix parmi les nombreuses propositions existant dans le communauté Flex. Généralement l'expérience préalable, le contexte de l'entreprise et le type d'applications à réaliser sont déterminants. Suivant que l'on vienne du monde Java ou PHP, la culture jouera un rôle important dans l'adoption du framework.

La plupart des frameworks Flex mettent en oeuvre les principes du MVC. Voici quelques liens absolument non exhaustifs :

• Swiz
• Cairngorm
• PureMVC
• Mate
• Parsley

Aller plus loin

Le net regorge d'articles sur la question. Vous trouverez en particulier nombre d'articles intéressants sur http://www.developria.com/.

N'hésitez pas en particulier à poster en commentaire des liens vers vos propres conventions d'architecture. Je pense que le sujet est loin d'être épuisé !

Permalink | Leave a comment  »