A l’occasion de la what’s next qui se tenait jeudi 26 et vendredi 27 mai au grand rex à paris, le CTO de springsource est venu nous présenter les nouveaux projets et l’actualité de l’éditeur. plus précisément adrian colyer a commencé par nous parler des nouveaux défis de l’informatique, avec la mobilité et le développement android, les réseaux sociaux, et le cloud. tous ces sujets correspondent aux nouveaux besoins identifiés par springsource. il faut désormais déployer nos applications sur tout type de plateforme allant du site web à l’application mobile native, en s’interfaçant avec des réseaux sociaux comme les api facebook connect et twitter par exemple.

Le développement mobile

SpringSource s’intéresse de près à l’essor d’Android et fournit des solutions pour faciliter le développement d’applications pour cette nouvelle plateforme.
Le projet Spring-Android fournit des templates de clients REST pour faciliter la consommation des services du Backend. Il s’agit donc d’une version optimisée du RestTemplate pour l’environnement Android. Ce template permet de configurer facilement HttpClient 4.X avec du Marshalling JSON, XML, ou RSS.
Le deuxième besoin adressé par spring-android concerne l’authentification à des services distants, pour utiliser par exemple l’API d’authentification Twitter, ainsi qu’un service d’authentification propriétaire. Spring-android-auth permet d’une part de persister les informations de connexion et de session dans la base SQLite embarquée par Android, et d’autre part d’établir des sessions web via l’implémentation du protocole OAuth 1 (pour Twitter) et 2 (pour Facebook).
Adrian Colyer nous a aussi parlé du développement de l’application d’exemple GreenHouse développée en open source pour démontrer les capacités des projets mobiles de l’éditeur et pour mettre en avant les bonnes pratiques en la matière. GreenHouse repose sur l’utilisation de spring-mobile, une extension de spring-mvc pour créer des interfaces web destinées aux SmartPhones, spring-social pour s’interfacer avec les réseaux sociaux, et spring-android pour l’application cliente Android.
À vrai dire tous ces projets existent déjà depuis 2010 et ne sont pas vraiment de grandes nouveautés, mais il est tout de même intéressant de noter l’orientation mobile prise par l’éditeur.

Les réseaux sociaux

Après le nomadisme, Adrian Colyer a continué sa Keynote en nous parlant des nouveaux usages des réseaux sociaux et en mettant en avant le fait qu’aujourd’hui toutes les applications se doivent d’être connectées aux différents réseaux. SpringSocial fournit les templates nécessaires pour gérer l’authentification à différents réseaux sociaux et ajouter de nouveaux fournisseurs d’authentification, mais il permet aussi bien sûr d’en utiliser les API. Parmi les API supportées, j’ai retenu :

• Facebook
• Twitter
• LinkedIn
• GitHub

Tout comme le CTO de SpringSource, nous ne nous attarderons pas trop sur le sujet qui n’est finalement pas une nouveauté. Ce projet adresse principalement les développements grand public qui ne sont définitivement pas majoritaires dans notre industrie où l’application d’entreprise règne en maître. Adrian Colyer s’est permis un raccourci pour associer l’utilisation de ces services tiers aux nouvelles problématiques de stockage avec les NoSQL et big-data.

La persistance des données

Les RDBMS n’ont plus l’exclusivité de la persistence des données et SpringSource en a bien conscience. Adrian Colyer nous a donc parlé du projet spring-data dont le but est de faciliter l’utilisation des nouveaux services de persistance comme les NoSQL de tous types. SpringData introduit de nouvelles annotations pour gérer le mapping des beans vers les bases non relationnelles. Elles permettent de gérer finement la configuration du stockage sur des systèmes distribués.
La librairie se découpe en plusieurs sous-projets :

• mapping pour assurer le mapping des beans par des annotations unifiées pour les différents systèmes de données.
• Blob pour les systèmes de stockage sous forme de Blob tel Amazon S3.
• Column Store pour les NoSQL orientés colonne avec Cassandra et HBase.
• Document Store pour les NoSQL orientés document avec un support pour MongoDB et CouchDB.
• Graph pour les bases orientées graphe avec Neo4J.
• Key value store, les bases orientées clé-valeurs, avec le support de Riak, Reddis et Membase.
• Map-Reduce, pour simplifier des frameworks de MapReduce avec le support de Hadoop.

Voici donc une offrequi s’annonce largement étoffée par rapport aux templates déjà disponibles pour JDBC et JPA. Dommage que BigTable ne fasse pas partie du lot.

Le déploiement des applications

Le CTO de SpringSource nous a ensuite parlé de son nouveau cheval de bataille qu’est le déploiement. Rien de très étonnant avec la nouvelle mode DevOps et l’industrialisation des déploiements. Après les réseaux sociaux et leurs SAAS, il met en avant les architectures PAAS comme étant la solution d’avenir pour résoudre les problèmes de déploiement. Parmi les avantages du Platform As A Service, Adrian Colyer retient :

• La rapidité des déploiements
• Le coût de ce type d’hébergement
• La scalabilité des services

Toutes ces facilités permettent de réduire le Time to market tout en augmentant la flexibilité métier. Le discours est assez convaincant. Adrian Colyer nous parle ensuite des différents modes de fonctionnement avec le cloud public, le cloud privé et les services mixant cloud privé et public. À partir de là, il nous parle de ce qu’il appelle le micro cloud. En réalité, il s’agit du déploiement d’une architecture PAAS en local sur la machine du développeur. L’avantage étant de tester les développements directement sur une architecture iso-production, pour éviter les fameux bugs de production par exemple.

CloudFoundry

Nous abordons ici le gros sujet de la présentation en la personne de l’open PAAS (comprendre PAAS open source), avec le dernier né des services SpringSource CloudFoundry. Il s’agit d’un service monétisé de distribution et d’hébergement de type PAAS. Il permet d’obtenir son cloud privé ou public, seul le micro cloud est disponible gratuitement.

La solution fournit différents templates permettant d’intégrer des services applicatifs (frameworks de développement) et des services d’infrastructures (systèmes de gestion des données).
Le système supporte différents runtimes pour le développement:

• Java
• Ruby
• NodeJS

Il est aussi possible de choisir parmi différents services d’environnement:

• NoSQL(MongDB, Reddis) ou SQL (MySQL)
• Bus de message (RabbitMQ)

La solution gère nativement la scalabilité horizontale en définissant le nombre d’instances à lancer et le load-balancing entre les différents frontaux.
Adrian Colyer nous fait ensuite une petite démonstration avec l’outil vmc qui permet d’administrer le cloud sans mal. Avec ce petit utilitaire en ligne de commande, on peut déployer son application à partir du répertoire projet. Parmi les fonctions de vmc on retrouve :

• Déploiement de l’application
• Définition du nombre d’instances lancées
• Consultation de l’état des différents serveurs

L’outil possède sans doute d’autres fonctionnalités, mais elles ne faisaient pas partie de la démonstration. vmc semble vraiment facile à utiliser et permet manifestement de monter des architectures complexes très rapidement. Bien sûr ces affirmations sont à prendre avec des pincettes car nous sommes restés dans les clous d’une démonstration, sans aborder par exemple le problème de la configuration des middlewares ou des architectures un peu plus ésotériques. La solution suscite en tout cas l’intérêt et j’avoue avoir créé mon compte sur le site pendant la présentation.
Pour finir, Adrian Colyer nous parle d’une nouveauté dans la déclaration des beans Spring, qui permet de définir un profil correspondant à l’environnement de déploiement. Ainsi, les ressources d’environnement peuvent être directement déclarées dans la configuration Spring et s’adapter au profil en cours d’exécution. Par exemple cela permet de déclarer les datasources ou les URLs de connexion aux bus de messages.

Conclusion

Au final, il n’y a pas de grande révolution dans les annonces du CTO SpringSource. Le discours est resté très commercial, avec la mise en avant de toutes les solutions déjà au catalogue de l’éditeur. Il n’en est pas moins intérressant d’en tirer les axes de développement de SpringSource, à savoir les réseaux sociaux, le NoSQL et le PAAS. Parmi les termes revenus les plus souvent, nous retiendrons la scalabilité, les applications polyglottes, avec l’entrée de NodeJS sur le devant de la scène. Bref SpringSource, entré dans le giron de VMWare, mise l’essentiel pour ne pas dire tout sur son nouveau service CloudFoundry.

• La présentation sur SlideShare
• Le retour sur le blog de Zenika

Google AppEngine 1.5

Google livre une nouvelle version de sa plateforme de cloud AppEngine. On notera l’arrivée d’une nouvelle API de file de traitement en mode Producteur/Consommateur, les Pull Queues. Les consommateurs peuvent être des composants faisant partie de votre application AppEngine ou externes ; le service fournit une API REST et des librairies pour Java, Python, .NET, PHP et Ruby.

Cette version introduit également un nouveau type d’instance en liaison directe avec la nouvelle API de file de traitement, les instances « Backend ». Les traitements effectués sur une instance de type Backend ne sont pas soumis aux restrictions standards (comme par exemple la limite de durée à 30 secondes). Il est également possible de choisir une classe parmi 4 proposées pour ces instances ; ce qui offre plus de contrôle sur le dimensionnement de l’architecture de déploiement. Une des autres options de configuration est le mode de rétention de l’instance Backend : Resident, son arrêt et son démarrage sont alors manuels ; ou Dynamic, les instances sont alors automatiquement démarrées pour traiter les demandes et sont arrêtées après 30 secondes d’inactivité.

Voici un tableau récapitulatif, pour vous donner une idée des tarifs de ces Backends:

Autre annonce importante, la technologie quittera le statut de preview lors du 2ème semestre de cette année. Le programme « AppEngine for Business » s’arrête et nombre des fonctionnalités est ou sera réintégré dans AppEngine comme : les bases SQL hébergées, les engagements sur les niveaux de service, l’utilisation de SSL avec des noms de domaine externes, etc. Une première version du SLA est consultable ici. Autre modification importante, le modèle tarifaire évoluera également : certaines APIs, dont la consommation est évaluée en temps CPU, seront dorénavant facturées au nombre d’appels. Tout cela conforte l’engagement de Google pour cette technologie.

Rapprochement Android / GWT / AppEngine

La future version 2.4 du plugin Eclipse de Google (actuellement en bêta) permettra un rapprochement entre les technologies Android, AppEngine et GWT. Le plugin autorisera la création de projets « connectés », et générera automatiquement le code de plomberie technique nécessaire pour effectuer les appels aux services GWT depuis une application Android.

Il y a également des nouveautés du côté de l’API Cloud to Device (CD2M) qui est encore dans l’incubateur Google. Sa mise en œuvre sera simplifiée par une intégration au sein même de Google AppEngine. Pour rappel, le but de l’API Cloud to Device est de remplacer les mécanismes de polling que l’on pourrait développer directement au niveau applicatif par un système de notification push. L’intégration de cette fonctionnalité directement au cœur du système permet de mutualiser les notifications, et rend l’ensemble du service plus efficace et moins consommateur en bande passante et en énergie. Un exemple concret d’utilisation est l’extension ChromeToPhone qui permet de diriger vers votre Smartphone Android une page en cours de visualisation dans Chrome.

Avec ce rapprochement, c’est tout un éco-système autour de Google AppEngine qui se dessine peu à peu.

Chrome / HTML 5

Le navigateur de Google se voit doté de fonctionnalités supplémentaires intéressantes comme la reconnaissance vocale. Autre annonce marquante, l’équipe de développement signale que l’optimisation des performances reste un chantier de premier plan. Toutefois, le focus sera mis sur l’accélération matérielle et non plus sur le moteur JavaScript. Enfin, on peut rappeler le lancement mondial du Chrome Web Store accessible dans plus d’une quarantaine de langues.

Nouvelles versions Android

Cette conférence a été l’occasion pour Google d’annoncer 2 versions majeures de la plateforme Android. La version HoneyComb 3.1 et la très attendue version 4 (?!) Ice Cream Sandwich qui va permettre de regrouper la version téléphone et la déclinaison tablette du système d’exploitation. La plus importante nouveauté de ces versions est sans doute l’API Open Accessory qui permet aux appareils Android d’utiliser les appareils connectés via USB ou de se comporter comme un hôte USB (le mode hôte USB n’est accessible que pour HoneyComb).

Android@Home

Le framework Android@Home permet au système d’exploitation d’être utilisé pour la domotique. Votre appareil Android devient la commande centrale pour piloter les appareils sans fil de votre domicile ; les équipes ont également développé un nouveau protocole pour les appareils sans fil non connectés au réseau Wifi. Une démonstration du projet Tungsten permet par exemple de diffuser en streaming de la musique dans l’ensemble de votre domicile.

Google Storage

Google Storage, le service de stockage en ligne de haute disponibilité et accessible via une API REST. Bien qu’encore dans l’incubateur, il est maintenant accessible à tous, dispose d’un quota gratuit d’utilisation (jusqu’à la fin de l’année) et propose 2 zones géographiques de stockage les états-unis et l’Europe.

Chromebooks

Google a annoncé la prochaine sortie de 2 nouveaux « NetBook » utilisant le système d’exploitation Chrome OS. L’originalité vient l’offre de commercialisation puisqu’ils seront disponible à la vente de manière standard, mais aussi dans le cadre d’une souscription étudiante ou professionnelle pour respectivement $20 et $30. L’offre inclue également la mise à jour matérielle.

Le mot de la fin … en attendant Google I/O 2012

C’est ici que s’achève notre petit tour d’horizon de cette très généreuse conférence. Avec plus de 100 sessions réparties sur 2 jours, il y a fort à parier que nous avons « oublié » d’aborder certains sujets. Mais, j’espère vous avoir donné l’envie de parcourir plus en détail les annonces, vidéos et autres matériaux de cette conférence.

Cette journée fut dédiée au développement mobile. Après un échange sur l’actualité, 4 groupes se sont formés autour de thèmes forts :

• Android, animé par Steve Klouvi
• Iphone, animé par Amin Fathallah
• Flex Mobile, animé par Julien Buret
• JQuery Mobile, animé par Alexis Kinsella

Suite à une brève introduction aux différentes technologies challengées, les xebians ont développé une application mobile en Pair Programming à l’aide de l’api JSON du blog de Xebia, proposant des fonctionnalités de listing des auteurs, des categories et des articles, ainsi que des fonctionnalités telles que la recherche. Certaines solutions telles que Windows Phone 7, Palm OS, BlackBerry ou encore BKRender n’ont pu être défendues lors de cette journée faute de participants pour ces challengers, ce qui n’est que partie remise.

Une restitution, suivie d’un débat a permis aux xebians de faire le point sur les différentes solutions testées, et de mettre en avant les forces et faiblesses de chacune des technologies. 

La journée s’est achevée sur deux sessions parallèles :

• L’urbanisation présenté par Nicolas Jozwiak.
• Les bases de la cryptographie et des infrastructures à clés publiques présenté par David Galichet.

Actualité éditeurs / SSII

• Apache Harmony: encore des couacs

Agilité

• Rien ne va plus

Le coin de la technique

• Sortie de MongoDB 1.8

Actualité éditeurs / SSII

Apache Harmony: encore des couacs

On se souvient des déboires récents du projet Apache Harmony: en opposition frontale à Sun puis à Oracle depuis 2007 au sujet du TCK, l’ambitieux projet d’implémentation Java sous licence Apache a vécu une année 2010 plutôt difficile. Jugez-en plutôt: en août 2010, Harmony fait les frais du procès fait à Google par Oracle pour violation de brevets Java au sein de la plateforme Android; la Fondation Apache a eu beau clamer n’y être pour rien, le mal était fait. En octobre, comme nous l’avions signalé ici même, c’est au tour d’IBM de quitter le navire pour rejoindre le très officiel OpenJDK, projet concurrent soutenu par Oracle; un mois plus tard, c’est au tour d’Apple de rejoindre les rangs d’OpenJDK, fragilisant encore davantage Harmony. Puis enfin, après une passe d’armes que nous avions retranscrite ici puis là, nous vous annoncions avec regret, en décembre dernier, que la Fondation Apache, en représailles face à l’immobilisme d’Oracle, venait de claquer la porte du JCP.

Et voilà que la semaine dernière, Tim Ellison, président du PMC (Project Management Committee) du projet Apache Harmony, annonce sa démission, en prétextant le manque de plus en plus cruel d’effectifs et en posant même clairement la question de l’opportunité de déplacer le projet vers le tant redouté mouroir des projets Apache.

Apache Harmony a-t-il un avenir? On peut en effet en douter. Lors de la conférence « TheServerSide Java Symposium 2011 » à Las Vegas mercredi dernier, James Gosling n’a pas mentionné directement Harmony, mais a laissé entendre qu’Oracle avait fait quelques gestes: en direction de la communauté d’une part, avec l’adoption récente des spécifications de Java EE 7; et d’autre part en direction de ses concurrents, en enterrant la hache de guerre avec IBM et Apple.

Ces gestes, bien entendu, auront un prix. Or les intentions d’Oracle face à Google ne sont pas claires. Si les développeurs Android restent imperturbables, il semblerait bien qu’Oracle n’ait pas dit son dernier mot: Adam Messinger, qui s’exprimait aussi pendant la même conférence, a souligné qu’Oracle voyait en grand l’avenir de Java ME; en ligne de mire, on le devine, se trouve la plateforme Android prônée par Google.

Dans ce paysage assombri par les enjeux stratégiques entre poids lourds de l’informatique, et quelle que soit l’issue du différend qui oppose Oracle à Google, Harmony apparaît de plus en plus comme le prix à payer pour que l’on revienne enfin… à l’harmonie.

Agilité

Rien ne va plus

Il y a des semaines comme ça… tout allait bien quand 3 annonces coup sur coup font voler en éclat nos plus profondes convictions. Imaginez qu’enfant on vous apprenne que le Père Noël… Chut ! Ce n’est pas notre rôle de vous le révéler. Toujours est-il que 3 articles sont venus nous secouer récemment. L’agilité que l’on vous vante tant ? Et bien, non, finalement, ce n’est pas le remède miracle. Et Java, notre langage tant aimé ? Finalement, il nous ralentirait plus qu’autre chose ! Mais cela se comprend, c’est la notion même de programmation objet qui ne sert plus à rien ! Voyons de quoi il retourne.

• A la conférence « TheServerSide Java Symposium 2011 », Jon Kern a donné une présentation dont la trame était que l’agilité n’est pas le remède miracle à tous les projets et toutes les situations. Non ?! Et bien si. Il s’en explique d’ailleurs dans une interview donnée quelques jours plus tôt: pour lui, passer à l’agilité requiert un changement dans les mentalités, dans tout le processus projet de l’entreprise. Il évoque aussi la possibilité d’être flexible dans la mise en place de l’agilité mais semble malgré tout d’accord avec John Clifford (dont nous vous parlions récemment) qui mettait en garde contre l’application de seulement quelques morceaux choisis de Scrum et le risque de se croire alors agile.
• Java, notre beau langage, ferait souffrir les entreprises. Il serait trop verbeux, offrirait trop de choix et les projets seraient coûteux et complexes à maintenir. C’est développez.com qui nous rapporte les propos de David Duquenne, DG du groupe Open Wide Technologies. Mais finalement, plus que le langage lui-même, il semble que ce soit l’utilisation qui en est faite, à travers l’incorporation à tort et à travers de multitudes de composants open-source dont on ne maîtrise ni le développement, ni les licences, qui soit à surveiller. Quelques pistes sont évoquées pour éviter ces écueils: l’utilisation de Frameworks (ceux de Open Wide ?!), l’intégration continue, le recours aux approches agiles ou à de nouveaux paradigmes tels que le MDA ou la programmation fonctionnelle.
• La programmation fonctionnelle, parlons-en justement. A l’université de Carnegie Mellon (Pittsburgh), elle remplacera en 1ère année l’apprentissage de la programmation orientée objet, cette dernière devenant optionnelle plus loin dans le cursus. Est-ce un choix raisonnable ? L’article d’InfoQ qui nous apprend la nouvelle ne semble pas complètement d’accord.

Le coin de la technique

Sortie de MongoDB 1.8

MongoDB a annoncé la sortie de la version 1.8 de la base de données NoSQL. La version précédente — 1.6 — datait d’août 2010. Cette nouvelle version ajoute plusieurs fonctionnalités, corrige quelques bugs et améliore nettement certaines fonctionnalités existantes.

Les release notes se trouvent ici. La version 2.5 du driver Java de MongoDB a par ailleurs été publiée la semaine dernière.

La nouveauté la plus attendue et la plus plébiscitée par les utilisateurs de MongoDB est la journalisation: grâce à l’écriture d’un journal des transactions, la récupération après un crash sera beaucoup plus rapide, et la pérennité des transactions sera renforcée au sein du système de stockage.

L’activation de cette option se fait uniquement au démarrage en ajoutant l’option « --journal » à la commande de démarrage. Les fichiers de journalisation seront alors stockés quotidiennement sous le répertoire « journal ». Suite à un arrêt normal du système, ceux-ci seront automatiquement purgés; suite à un crash, en revanche, au redémarrage de MongoDB l’ensemble des transactions décrites dans ces fichiers sera re-exécuté. L’option « repair » ne sera plus nécessaire.

Par ailleurs le sharding, fonctionnalité introduite dans la version 1.6, a bénéficié d’importantes améliorations internes qui permettront une meilleure performance et une meilleure reprise sur erreur, même si ces changements ne seront pas forcément ressentis par tous les utilisateurs.

Et enfin, parmi les autres fonctionnalités, on peut citer le support de l’authentification au niveau des jeux de répliques (replica sets), des nouveautés liées aux index, ou encore la recherche spatiale « sphérique »: jusqu’alors plate, la Terre est enfin redevenue ronde pour MongoDB!

Actualité éditeurs / SSII

• Hudson devient Jenkins
• Tomcat 6.0.30 et Tomcat 7 devient stable

Le coin de la technique

• Hors-série Linux Magazine « Développement Android »

Actualité éditeurs / SSII

Hudson devient Jenkins

La nouvelle n’a sans doute pas échappé aux plus avertis d’entre nous, Hudson, le célèbre serveur d’intégration continue, va être renommé en Jenkins. Ce changement est motivé par la volonté de se protéger contre d’éventuels blocages de la part d’Oracle sur les développements du projet. En effet Hudson a été créé par Kohsuke Kawaguchi, alors qu’il travaillait chez Sun, depuis racheté par Oracle qui juridiquement possède la marque Hudson. Ce dernier point donne la possibilité à Oracle de bloquer ce projet sous ce nom et le renommage permettra de se défaire complètement de cette contrainte.

Andrew Bayer décrit les différentes étapes qui vont suivre cette annonce:

• déposé le nom, créer les comptes twitter…
• migrer les infrastructures du projet en-dehors de serveurs Oracle et renommage des différents composants.
• Andrew Bayer, Kohsuke Kawaguchi et peut-être Winston Prakash, qui a repris le projet chez Oracle, formeront une gouvernance par intérim, le temps d’organiser des élections.

Tout en se détachant de l’emprise d’Oracle, il y a la volonté que l’entreprise reste actif dans le projet. Cet épisode souligne malgré tout la méfiance de la communauté envers Oracle.

Tomcat 6.0.30 et Tomcat 7 devient stable

Après plusieurs versions correctives de la bêta, Mark Thomas a officialisé la version 7.0.6 du célèbre serveur Java, comme la première version stable de Tomcat 7. Avec cette annonce Tomcat rejoint Glassfish 3 dans le cercle fermé des implémentations stables de servlet 3.0. Parmi les nouveautés de cette version, on notera, la présence d’une nouvelle distribution binaire spécialisée pour embarquer le serveur dans d’autres applications. Sans doute une façon de répondre à la forte adoption de Jetty dans ce domaine. Cette version corrige surtout les derniers bugs majeurs comme une importante fuite mémoire dans le connecteur NIO. Elle contient donc une longue liste de corrections accompagnées de menues améliorations (Voir le changelog).
Notez enfin, la sortie d’une version corrective de Tomcat 6 corrigeant là encore un grand nombre de bugs(Voir le changelog).

Le coin de la technique

Hors-série Linux Magazine « Développement Android »

Dans revue de presse, il y a « presse ». Et il est vrai que nous ne parlons pas souvent de la presse classique. Vous savez, celle faite de papier plutôt que de HTML. Celle à qui il manque les hyperliens mais qui en revanche ne tombe jamais à court de batterie. Celle qui sort, début janvier, un magazine labellisé « février/mars »… Et c’est justement le cas du Linux Magazine Hors-série spécial développement Android sorti récemment. Mis au courant par FrAndroid, nous nous sommes rués en kiosque.
Et c’est du costaud ce hors-série! Sur 80 pages, Philippe Prados nous fait découvrir comment réaliser une application Android qui s’intègre dans le système de contact et se synchronise sur un serveur LDAP distant. Pour tout vous dire, il y a du travail.
Vous aurez l’occasion de revenir sur les notions spécifiques d’Android que sont les termes d’activités, de Content Provider, d’Intent… Les IPC, souvent peu abordés sur Android sont aussi expliqués. Ainsi, l’application contacts classique d’Android, se trouvera augmentée d’un mécanisme d’aller-retours avec l’application présentée qui fournira le contenu LDAP, lui-même obtenu depuis un fournisseur de contenu. L’intégration à la recherche globale Android est aussi de la partie, ainsi qu’un wizard de création de compte pour le fournisseur d’authentification nécessaire à la synchronisation des contacts avec LDAP.
Et encore, tout ceci n’est qu’un petit aperçu de ce qui vous attend dans le magazine. L’auteur a essayé un maximum de s’intégrer dans le système, et il semble que bien souvent, c’est grâce à la disponibilité des sources des applications standards qu’il a pu comprendre certains mécanismes peu documentés.
Un petit grief tout de même: la lecture est assez ardue et il faut attendre la toute fin (page 73) pour savoir où se procurer les sources… Et se rassurer en prenant connaissance de leur disponibilité qui n’est pas clairement annoncée dès le début. Bref, une lecture inestimable pour qui veut produire plus qu’une banale application et s’intégrer complètement au système de Google.

Actualité éditeurs / SSII

• Amazon Appstore
• Jackson 1.7

Le coin de la technique

• Ecosystème Groovy/Grails
• Version majeure de JRuby : 1.6 en release candidate

Actualité éditeurs / SSII

Amazon Appstore

Amazon a annoncé le lancement du portail Appstore Developper – https://developer.amazon.com/ – qui ouvre la voie au prochain Appstore pour Android (à terme d’autres plateformes seront peut-être aussi supportées). Amazon se lance pour avoir sa part du gâteau dans le marché des applications mobiles. Contrairement à Google, qui laisse la liberté de soumettre n’importe quelle application et de la vendre, Amazon vérifiera si le contenu est approprié et validera selon des standards de qualité minimale. Ce modèle se rapproche de celui d’Apple pour l’AppStore, par exemple le contenu très explicite pour adultes seront interdits.

Ce processus de validation affectera le délai de mise en vente, mais Amazon promet de ne pas dépasser une semaine pour le délai d’approbation des applications. D’après Amazon, l’objectif principal du filtre est d’améliorer la qualité des applications qu’on peut acheter sur le portail en offrant un minimum de garanties aux utilisateurs.

La différence majeure par rapport à ses concurrents, Google et Apple, est le système de prix qui sera similaire à celui des livres et restera sous le contrôle d’Amazon. Les développeurs pourront choisir le prix de départ de l’application dans une liste, mais celui-ci variera dans le temps, pour s’adapter au marché et afin de rentabiliser au maximum ses ventes et bénéfices. L’un des aspects le plus attractif pour le développeur est la façon dont Amazon propose aux utilisateurs des produits auxquels ils pourront être intéressés grâce à leur système de suivi.

Concernant les prix du service, la première année est gratuite pour le développeur et passe ensuite à 99 dollars / an. L’Appstore Amazon ouvrira d’abord aux Etats-Unis, et même si aucune date d’ouverture n’a été annoncée, tous les yeux sont rivés vers cet été 2011.

Jackson 1.7

Quelques mois après la sortie de la version 1.6, cette nouvelle mouture apporte quelques petites évolutions techniques et elle est totalement compatible avec la version précédente. La grande nouveauté vient de l’abstraction des modules qui facilite l’ajout de serializers/deserializers. Pour cela il suffira d’étendre la classe abstraite Module:

public abstract class Module
{
    public abstract String getModuleName();
    public abstract Version version();
    public abstract void setupModule(SetupContext context);
}

Outre la personalisation des serializers/deserializers, le module pourra modifier ou ajouter ses propres annotations ou avoir accès à des configurations de sérialisations. Voici quelques idées de librairies qui pourrait être de bons candidats à une adaptation spécifiques, proposés sur le site de Jackson:

• Joda Time
• Google guava pour sa partie sur les collections surtout
• Hibernate, pour par exemple gérer le lazy loading
• Apache commons
• des types de donnée propre à des langages de la JVM hors Java comme Scala, Groovy ou Clojure

Une page regroupe certains de ces modules. De plus il est possible en ajoutant le jar jackson-xml-databind d’utiliser le format XML pour la sérialisation grâce au nouveau mapper XmlMapper.

Reconnu comme l’outil le plus performant sur le format JSON, Jackson tente d’étendre ses fonctionnalités et d’améliorer sa modularité, et c’est plutôt une bonne nouvelle.

Le coin de la technique

Ecosystème Groovy/Grails

Pour ceux qui suivent l’actualité Grails, beaucoup de mouvements cette semaine. Burt Beckwith, committer sur le projet, en fait une liste exhaustive sur son blog. Plus d’une vingtaine de plugins ont été mis à jour, parmi lesquels :

• Liquibase
• Fixtures
• Webtest
• JQuery
• et d’autres …

Vous trouverez également un tutoriel vidéo pour recoder un Twitter-like en 90 minutes, et un autre pour coder un gestionnaire de contact en 8 minutes, le tout grâce à Grails.

L’outil de build Gradle est sorti en version 0.9.1, vous trouverez sur ce blog une stratégie intéressante pour migrer vos scripts ant en douceur et ainsi apporter plus de flexibilité à votre processus de construction de projet.

Pour plus de détails sur l’activité Grails de la semaine, faites un tour sur le blog de Burt.

Version majeure de JRuby : 1.6 en release candidate

Information de dernière minute : JRuby vient de sortir en version 1.6 RC1 ! Il s’agit là d’une version majeure à plusieurs égards puisqu’elle apporte la compatibilité avec Ruby 1.9.2 ! Le support des extensions Ruby compilées en C est également disponible, mais en mode expérimental. Pour plus de détails, voir les release notes. Plus de 265 problèmes solutionnés depuis la dernière version en 2000 commits sur 9 mois, soit une moyenne de 10 commits par jour ouvré ! Un grand bravo à l’équipe pour ce joli bébé !

Il va maintenant falloir tester tout ça pour permettre de valider la version. La compatibilité avec Ruby 1.9.2 est l’effort de test le plus grandement recherché par le projet. Avis aux amateurs…

La revue de presse hebdomadaire proposée par Xebia vous souhaite une bonne et heureuse année 2011.

Actualité éditeurs / SSII

• JBoss AS 6 est disponible

Agilité

• Comment impliquer votre client dans un projet ?

Le coin de la technique

• La JSR 310 devient « Project ThreeTen »
• PhoneGap, une autre approche du développement d’application mobile

Actualité éditeurs / SSII

JBoss AS 6 est disponible

Un an après la sortie de la spec finale JEE6 en simultanée avec son implémentation de référence, Glassfish V3, c’est au tour de JBoss AS (pour Application Server) de montrer le bout de son nez en version 6.
JBoss, c’est le poids lourd des serveurs JEE. Poids lourd par la part de marché, car, d’après une récente étude de ZeroTurnaround (ceux de l’excellent JRebel), il représente tout de même près du quart des déploiements de serveurs Java. Mais poids lourd aussi par ses fonctionnalités. Il implémente en effet la totalité de la spécification JEE6 en partie JEE6 dont  le « Web Profile » en totalité (pour visualiser ce que représente Web Profile, ce graphique sur le site de Caucho est représentatif). Nous ne reviendrons pas sur JEE6 déjà largement évoqué ici.
Sur DZone, Mitchell Pronschinske a listé les composant remarquables. Reprenons les un par un:

• JBoss Embedded AS, le serveur est embarquable directement depuis Maven, utile pour les tests
• Single POM Dependency for all the AS runtime, permet comme expliqué ici de fournir une intégration facilitée aux utilisateurs de Maven. Une dépendance unique « tire » toutes les dépendances du serveur embarqué.
• ShrinkWrap, l’API permettant d’assembler aisément des JAR, WAR ou autres EARs
• JBoss Switchboard et JBoss-injection prennent en charge l’injection de ressources JNDI
• HornetQ, la solution de messaging JBoss, récemment vantée pour ses performances
• VFS 3, le système de fichier virtuel uniformise l’accès aux différentes ressources et est censé apporter une vitesse accrue pour lire depuis les fichiers jars
• JBoss OSGi integration
• les Servlets en version 3.0, avec notamment la configuration par annotations, la modularisation grâce aux webfragments et l’exécution asynchrone. Plus de détails sur notre blog
• JPA 2.0, implémenté comme il se doit par Hibernate
• RESTEasy 2.0 qui propose une implémentation de la JSR 311, JAX-RS dont le principe est évoqué sur le Touilleur Express
• Microcontainer 2.2, un peu le coeur du systeme, qui nous est décrit dans une série de 6 articles par Ales Justin de JBoss.
• Le déploiement de la console de management seulement à la demande pour ne pas pénaliser le temps de chargement
• Les EJB 3.1 avec toutes les fonctionnalités apportées par la JSR 318 (Singleton Session Beans, packaging WAR, EJB lights…)
• La stack JBossWS en versions CXF/Metro/Native
• La spécification EE 6 « Web Profile » est bien sûr de la partie, permettant des développement plus légers
• Weld 1.1, implémentation de référence de la JSR 299 autrement connue sous le nom de Context & Dependency Injection

Au final, ce n’est bien sûr pas un serveur sorti de nulle part que JBoss nous sert là. C’est un assemblage cohérent basé sur des composants éprouvés et disponibles pour la plupart depuis un moment. Il sera donc intéressant d’observer les retours des premiers utilisateurs et voir si les prévisions de JBoss ont des chances de se réaliser.

Agilité

Comment impliquer votre client dans un projet ?

c’est la question à laquelle Vikas Hazrati répond dans cet article sur InfoQ.

Selon Vikas, les signes du manque d’engagement de la part d’un client sont :

• peu ou pas de retours sur le travail effectué,
• un retour sur les erreurs tardif, qui révèle généralement que le client teste ou s’intéresse au dernier moment au projet,
• notre interlocuteur n’est pas le bon et nous ne sommes finalement pas en contact avec le client réel.

Ce manque d’implication peut provenir d’une mauvaise formation aux processus de développement agiles ou encore d’un problème de temps ou de ressource disponible. Différentes stratégies peuvent être employées afin de remédier à ce problème d’implication :

• identifier un interlocuteur unique faisant l’interface avec les autres clients,
• utiliser des techniques comme celle des personas afin d’améliorer la compréhension mutuelle,
• planifier les réunions en prenant au maximum compte des contraintes de vos clients,
• motiver votre client en notant ses efforts et en l’encourageant dans cette voie,
• et enfin la communication avec votre client est primordiale, lui garantissant un bonne connaissance de l’actualité du projet, même en phase de développement.

L’implication des clients dans le projet est un élément important de sa réussite et elle ne doit donc pas être négligée. Rappelez-vous, la collaboration avec le client est une des quatre valeurs fondamentales du manifeste agile.

Le coin de la technique

La JSR 310 devient « Project ThreeTen »

La JSR 310, la fameuse JSR « Date and Time API » attendue comme le messie pour remplacer l’implémentation défaillante des dates dans le JDK n’en finit pas d’être retardée. Nous vous en parlions déjà en 2008, puis l’API fut planifiée avec des réserves pour le JDK 7… Aujourd’hui, Stephen Colebourne, le spec lead annonce sur son blog diverses informations.

• tout d’abord, il ne semble vraiment pas satisfait de la façon dont Oracle a pris en main la communauté mais il désire tout de même continuer son travail sur l’implémentation de référence.
• cette implémentation de référence a d’ailleurs maintenant un nom: elle est portée par le projet ThreeTen (ThreeTen, 310… vous voyez le rapport ? ).
• la cible est maintenant Java 8 et non plus Java 7. Il va falloir patienter encore.
• une nouvelle mailing liste, encore bien vide, est en place et un repo SVN est disponible sur Sourceforge.

Une autre particularité est aussi mentionnée et peut faire réfléchir. Stephen indique en effet se réserver la possibilité d’écrire des spécifications pour le projet ThreeTen séparées de la JSR 310. Concrètement, il parle de pouvoir fournir une terminologie commune et un comportement de plus haut niveau pour pouvoir collaborer avec d’autres langages ou librairies comme XML ou SQL. Sur le principe c’est une excellente idée: faciliter la collaboration de Java avec « l’extérieur » en prenant une base solide pour socle semble une bonne chose. Mais il ne faudrait pas que cette nouvelle perspective ne vienne retarder une fois encore le projet… Cela serait vraiment dommageable pour tous ceux qui préfèrent se reposer sur les API standard du JDK plutôt que sur une librairie tierce comme Joda Time (malgré ses qualités) et qui sont en attente de cette implémentation.

PhoneGap, une autre approche du développement d’application mobile

Aujourd’hui, dans le domaine du développement mobile, le choix se résume encore entre développer une application native ou une application Web Mobile. PhoneGap est un framework qui permet le développement d’applications mobiles multi-plateformes en combinant ces deux mondes.

L’approche retenue est de développer votre application en utilisant les technologies HTML 5 et JavaScript. L’accès aux fonctionnalités de la plateforme (système de fichiers, géolocalisation, notifications, appareil photo, accéléromètre, …) s’effectue via des APIs JavaScript. Le framework prend en charge le code de liaison nécessaire, et fournit également un modèle d’application native pour chaque plateforme. Il sert entre autre à démarrer une version embarquée du navigateur web. Le navigateur est donc utilisé comme environnement d’exécution standard. Cette approche est possible car les navigateurs des plateformes iOS, Android, BlackBerry OS et WebOS sont tous basés sur le moteur WebKit. Même si l’expérience utilisateur peut varier entre les plateformes, le résultat reste dans l’ensemble cohérent.

PhoneGap est encore en phase de développement. Les supports des plateformes iOS et Android sont les plus avancés, mais il faut y ajouter les plateformes BlackBerry OS, WebOS et Symbian. C’est, au final, une alternative intéressante au développement natif pour les plateformes mobiles. La dernière version en date (0.9.3) est sortie le 23 décembre.

Lors du dernier XKE, nous avons eu la visite de Michaël Chaize qui est venu nous présenter les nouvelles solutions Adobe. Fort d’une matinée plutôt réussie, j’arrive à ce slot un peu blasé et fatigué en me demandant un peu l’intérêt d’une telle présentation. Allez c’est reparti, je vais encore avoir le droit au discours technico-commercial que j’ai eu chez mon cher client quelques semaines auparavant.
Et bien que nenni ! Bien au contraire ! Je suis sorti de celui-ci avec une folle envie d’essayer de suite les technologies qu’il nous a présenté, en particulier celles qui touchaient à la mobilité.
Avant ce slot, j’avais bien entendu parler ici et là de l’émergence d’une telle solution, mais rien ne m’avait donné l’envie de m’y essayer. C’est maintenant chose faite !

La plateforme Air propose donc :

• une machine virtuelle multi-plateforme
• un langage adapté à la mobilité
• une solution pas tout à fait sèche
• un ticket d’entrée relativement faible

Write once, run everywhere ?

Les applications Air s’exécutant sur une machine virtuelle, toute plateforme disposant de celle-ci est à même d’exécuter vos applications. Adobe vous propose ici, d’adopter un framework – Flex – et une base de code unique pour toutes les plateformes que vous ciblez. L’API Air vous permet d’interagir avec le hardware de votre téléphone. Vous pouvez contrôler programmatiquement la présence de tel ou tel composant.

Sur Android, seuls quelques téléphones disposent de la machine virtuelle pré-installée. Pour les autres elle est disponible sur l’Android Market pour peu que vous disposiez d’un firmware récent (>= 2.2). Lorsque vous installez une application Air, si vous ne disposez pas du moteur d’exécution, un message vous propose son téléchargement et vous renvoie sur le market, contrairement à la version iPhone où le moteur est embarqué dans les applications (il est donc forcément téléchargé).

Si Air peut s’exécuter sur toutes ces plateformes, l’outil Flash Builder 4.5 preview, connu aussi sous le nom de Burrito, ne permet pour le moment que le développement Android. Bien que certaines vidéos montrent une compatibilité Blackberry, l’option n’est pas encore disponible dans la version de Flash Builder que j’ai téléchargé.

La taille du runtime n’est pas négligeable, sur mon Nexus One il prend 16 Mo après installation. L’option d’installation sur la carte SD n’est pas activée, inutile de bidouiller votre téléphone pour déplacer le runtime, les performances de celui-ci n’en seraient que dégradées.

Sur le papier, cette technologie permet de ne plus avoir à faire le choix d’un développement iPhone, Android ou Blackberry. En pratique, du nous sommes en pleine guerre de chapelle pour savoir où et comment seront installés les runtimes. Par exemple, à ce jour, il manque un d’incontournable dans la liste des partenaires de l’Open Screen Alliance. Air sans Apple, c’est un peu comme une forêt sans écureuil comme disait Asterix dans l’un de ses albums.

Quoi qu’il en soit, la perspective du write once, run everywhere est alléchante Wait & See…

Flex, un framework adapté à la mobilité !

Flex a été conçu dans l’optique de créer des composants riches. Il mêle description XML des composants graphiques (boutons, checkbox, listes …) – le MXML – à un langage de scripting – l’Actionscript 3 – permettant de donner vie à vos composants. Faisant moi même du Flex depuis 6 mois, je suis persuadé que ce langage est parfaitement adapté au développement d’applications mobiles.

À titre de comparaison, dans une application Android développée en Java l’écriture des écrans est relativement pénible :

• en full java, la syntaxe est lourde à manier (setters complexes, listener volumineux …),
• en XML, vous devez récupérer vos éléments graphiques par leur ID à partir du Java pour leur rajouter du comportement.

En résumé, le développent Android c’est faire du client lourd avec un langage peu flexible.

Flex est un langage pensé et conçu pour effectuer des actions asynchrones. Le langage permet l’ajout de comportements à des composants très simplement grâce à différents mécanismes dont :

• le passage de fonctions en paramètre, pratique pour passer des handlers sur des événements.
• le databinding, qui permet de notifier la mise à jour d’un model aux composants qui le désirent.

De plus, dernière bonne surprise, les composants graphiques utilisables dans une application mobile sont exactement les mêmes que ceux que vous utilisez dans une application Flex classique. L’apparence et le comportement ont simplement été adaptés pour les applications mobiles grâce à un nouveau Skin pour mobile dans la librairie Spark.

Pas encore production ready…

C’est bien joli tout cela, mais la peinture n’est pas complètement sèche.

Les outils ne sont disponibles qu’en version preview. Pourtant, l’intégration du développement mobile à Flash Builder est vraiment bien avancée :

• une vue design permet l’élaboration rapide d’écrans,
• un éditeur de composants bien pratique,
• un gestionnaire d’appareils vous permet de lancer des simulateurs, il contient d’ailleurs bon nombre de périphériques pré-configurés,
• l’installation sur un téléphone physique fonctionne tout aussi bien.

Mais il reste des progrès à faire au niveau des performances. Si l’exécution d’applications mobiles Air est bluffante sur l’émulateur, j’avoue rester un peu sur ma faim lors de l’exécution d’une même application sur mon Nexus One. (il en était de même lors de la démonstration sur tablette Android lors du XKE). Le scrolling des listes, par exemple, n’est pas aussi performant que sur une application native, la solution Flex rame encore un peu. Et plus généralement, une application Air Mobile consomme plus de CPU et de mémoire qu’une application native classique.

Mais surtout, les accords de distribution des moteurs d’exécution Air n’étant pas encore terminés, rien ne vous garantit que vous puissiez réellement profiter de votre application mobile Air sur toutes les grandes plateformes mobiles du moment.

Ne soyez pas timide, lancez-vous !

Que vous soyez développeur mobile ou non, que vous soyez flexeur ou non, n’hésitez pas à vous lancer pour vous faire un avis. Pour cela rien de plus simple, tout est disponible gratuitement sur les Labs Adobe : Adobe Flash Builder en version 4.5 preview (Burrito) (pendant 60 jours) et Adobe AIR Launchpad.

Si vous désirez essayer votre projet sur votre mobile Android (disposant d’Android 2.2 a minima), installez sur celui-ci le Runtime Air. Une fois cela fait, vous devriez mettre moins de 15 minutes pour exécuter votre première application Air sur votre mobile.

En guise de conclusion, je vous ai préparé une petite vidéo qui présente :

• la génération d’un projet Air mobile avec AIR Launchpad.
• l’utilisation de Flash Builder pour lancer votre application Air sur une plateforme Android.

Cliquer ici pour voir la vidéo.

Adobe Air pour iOS

Pour le développement d’applications iPhone, Apple avait émis une restriction pour interdire l’utilisation d’outil de développement en dehors de ceux autorisés par Apple. Suite à la levée de cette restriction, Adobe peut donc enfin réaliser des applications pour iPhone à partir de ses outils. Parmi les fonctionnalités d’Adobe Air, vous trouverez un packager pour iOS qui permet de transformer une application Air en IPK (format des package pour l’iPhone). Ce packager est aussi disponible dans la Creative Suite 5. Le packager permet de générer une application native pouvant être exécutée pour iOS. Attention, certaines APIs n’ont pas été implémentées dans le packager.

Les nouveautés dans Air 2.5

La grande nouveauté de Air 2.5 est la possibilité de développer des applications mobiles. Pour ce faire, deux nouvelles classes héritant d’Application sont disponibles : MobileApplication et TabbedMobileApplication. Un nouveau skin a été créé pour les applications mobiles et certains composants en bénéficient comme Button, CheckBox, DataGroup, Label, List, Scroller … Parmi les nouveaux composants dédiés, vous trouverez le MobileItemRenderer et le MobileIconItemRenderer pour les rendus de listes .

Flash Builder « Burrito »

Burrito est le petit nom du dernier Flash Builder. Il prend en charge toutes les nouveautés disponibles dans Flex 4. La fonctionnalité mise en avant est la possibilité de développer des applications mobiles à partir de votre Flash Builder !

Flash Builder « Burrito » est disponible en version d’évaluation (pour une durée de 60 jours) ; vous pouvez le récupérer ici. Pour ma part, très curieuse de voir ces nouvelles fonctionnalités je l’ai téléchargé et effectivement, on peut créer des applications flex mobiles.

Une fois votre projet créé, vous pouvez visualiser dans la partie Design de nouvelles options associées à votre vue.

Vous pourrez sélectionner une configuration de téléphone, vous aurez le choix entre plusieurs téléphones android.

Vous pourrez également modifier l’orientation du téléphone pour vérifier le bon positionnement de vos composants.

   

Une fois votre application réalisée, vous pouvez l’exécuter. Celle-ci sera affichée dans une fenêtre au format du téléphone que vous avez sélectionné. Elle propose aussi un menu contenant les actions disponibles pour le téléphone que vous avez sélectionné (changement de l’orientation, menu, retour arrière …).
Il est également possible d’exécuter votre application directement sur votre Android si bien évidemment vous en avez un . Une simple connexion USB suffit pour cela. Malheureusement, je n’ai pas pu tester cette partie mais espérons que le père Noël m’apporte un Android 2.2 le mois prochain.

Ce n’est pas tout. Vous avez développé votre application et l’avez testée. Vous voulez maintenant la partager ? Il suffit simplement de préparer le package pour le déposer sur Android Market. Et avec Flash Builder « Burrito » rien de plus simple, exportez votre projet et sélectionnez Release Build. La seule plateforme disponible pour le moment est Google Android. Après avoir donné votre certificat et mot de passe, Flash Builder vous génère un APK contenant une application native Android que vous pouvez déposer sur Android Market.

Le déploiement semble simple et pourrait motiver de nouveaux développeurs à réaliser des applications pour mobile.

Cet article a pour but de vous présenter quelques-unes des solutions les plus répandues pour répondre à ce besoin. Pour cela, nous allons créer un camembert de 3 manières différentes :

• Google Chart API
• Achartengine
• ChartDroid

Cet article est une adaptation libre du billet de l’un des mes collègues indiens Yogesh Kapoor, l’original est disponible en anglais sur le blog de Xebee.

Google Charting API

L’utilisation de Google Charting est très simple. Cette API permet de créer des graphiques par l’intermédiaire d’une URL. Vous n’avez qu’à passer les bon arguments à celle-ci pour récupérer votre graphique. Comme ce service est basé sur une URL, vous devez disposer d’une connexion internet pour que celle-ci fonctionne. Si votre application s’exécute hors ligne, passez votre chemin.

L’appel à l’API Google Charting s’effectue par l’intermédiaire d’URL ressemblant à celle-ci :

http://chart.apis.google.com/chart?cht=p3&chs=250x100&chd=t:30,60,10&chl=cars|bikes|trucks

Dans cet exemple, voici comment lire les paramètres :

• cht=t3, type du graphique, t3 = camembert 3D,
• chs=250×100, la résolution,
• chd=t:30,60,10, les données,
• chl=cars|bikes|trucks, les libellés.

Le google code du projet est plutôt bien fait, il vous permet de créer différents types de graphiques en vous inspirant d’une multitude d’exemples.

Vous pouvez intégrer un graphique de ce type dans une application Android par l’intermédiaire d’une simple WebView. Difficile de faire plus simple.

@Override
public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  WebView webView = new WebView(this);
  webView.loadUrl("http://chart.apis.google.com/chart?cht=p3&chs=250x100&chd=t:30,60,10&chl=cars|bikes|trucks");
  setContentView(webView);
}

La méthode onCreate() est appelée à la création d’une activité. Dans l’exemple ci-dessus, nous avons créé une WebView, chargé l’url de notre graphique dans celle-ci et affecté notre vue comme composant principal de l’activité.

Pour que cela fonctionne, comme vous avez besoin d’un accès internet, vous devez ajouter la permission suivante dans votre AndroidManifest.xml.

<uses-permission android:name="android.permission.INTERNET" />

Et c’est tout ce que vous avez à faire ! Notez au passage que vous n’êtes pas obligé de passer par une WebView, vous pouvez également télécharger cette image et l’afficher comme n’importe quel autre drawable dans n’importe quel composant (imageView, boutons, backgounds …)

Voici un capture d’écran du résultat obtenu, le graphique est plutôt joli. Il vous est possible de modifier les couleurs, ajouter une légende, changer le type de graphique en ajoutant des paramètres supplémentaires.

Si votre application n’a pas besoin d’accéder à internet, ce type de graphique n’est pas adapté. Continuons notre tour d’horizon avec une autre solution … hors ligne.

achartengine

achartengine est un projet permettant de générer différents types de graphique pour Android. Cette API utilise le mécanisme d’Intent, des messages configurables qui permettent de lancer l’exécution d’une activité tierce. Elle ne nécessite aucune connexion internet..

Qui dit Intent dit nouvelle activité. Les graphiques sont affichés sur des activités dédiées. Contrairement à Google Chart API, vous ne pourrez donc pas intégrer vos graphiques directement dans vos activités.

Pour l’utiliser, télécharger la dernière version du jar du projet sur le Google Code du projet, puis ajoutez le à votre projet Android.

Voici l’exemple d’une classe contenant une méthode qui créer un Intent configuré pour afficher un camembert :

public class MyChartExample {
  public Intent createIntent(Context context) {
    int[] colors = new int[] { Color.RED, Color.YELLOW, Color.BLUE };
    DefaultRenderer renderer = buildCategoryRenderer(colors);
    CategorySeries categorySeries = new CategorySeries("Vehicles Chart");
    categorySeries.add("cars ", 30);
    categorySeries.add("trucks", 20);
    categorySeries.add("bikes ", 60);
    return ChartFactory.getPieChartIntent(context, categorySeries, renderer);
  }
  private DefaultRenderer buildCategoryRenderer(int[] colors) {
    DefaultRenderer renderer = new DefaultRenderer();
    for (int color : colors) {
      SimpleSeriesRenderer r = new SimpleSeriesRenderer();
      r.setColor(color);
      renderer.addSeriesRenderer(r);
    }
    return renderer;
  }
}

La récupération de l’Intent bien configuré s’effectue par l’intermédiaire de la méthode createIntent. À l’intérieur de celle-ci, un SimpleSeriesRenderer est créé pour chaque part du camembert. Ces renderers sont ensuite ajoutés à un DefaultRenderer global au graphique.

À ce stade, la structure du graphique est configurée, il nous reste plus qu’à déclarer les valeurs des différentes parts de notre camembert. Pour cela, nous créons un CategorySeries avec les mêmes libellés et valeurs que nous avons utilisé dans l’exemple précédent.

Pour finir, nous fabriquons à partir de tout cela (renderers + series) un Intent correctement configuré en utilisant la factory prévue à cet effet.

Notre Intent créé, il ne nous reste plus qu’à l’utiliser pour lancer une nouvelle activité contenant le graphique. Il s’agit du mécanisme habituel pour lancer une nouvelle activité.

  Intent achartIntent = MyChartExample.createIntent(this);
  startActivity(achartIntent);

Après avoir exécuté ce code, voici ce qui devrait s’afficher.

Chartdroid

La dernière solution présentée dans cet article est plus contraignante d’utilisation. Elle utilise le même mécanisme d’Intent que la solution précédente, mais ici les activités ne sont pas directement intégrées à votre projet. Pour que les Intents fonctionnent, vous devez installer une application tierce : ChartDroid. Notez qu’il vous est cependant possible de faciliter cette installation en proposant programmatiquement un lien sur le market pour la récupérer (ce mécanisme n’est pas présenté dans cet article, il fonctionne, une fois encore, via un Intent).

Pour utiliser cette solution, vous devez créer un ContentProvider. C’est un mot qui peut faire peur au premier abord, mais il s’agit d’un des mécanismes proposé par Android pour communiquer entre application. Un ContentProvider est utilisable après la création d’un Intent, il permet de récupérer des données à partir d’un type et d’un URL.

public class ChartDroidDataProvider extends ContentProvider {
  static final String AUTHORITY =  "com.xyz.contentprovider.chardroid";
  @Override
  public String getType(Uri uri) {
    return "vnd.android.cursor.dir/vnd.com.googlecode.chartdroid.graphable";
  }
  public static final Uri PROVIDER_URI = new Uri.Builder().scheme(ContentResolver.SCHEME_CONTENT).authority(AUTHORITY).build();
  @Override
  public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder)
    // Fetch the actual data
    MatrixCursor c = new MatrixCursor(new String[] {
      BaseColumns._ID,
      "COLUMN_AXIS_INDEX", "COLUMN_SERIES_INDEX",
      "COLUMN_DATUM_VALUE", "COLUMN_DATUM_LABEL"
    });
    c.newRow().add(1).add(0).add(1).add(30).add(null);
    c.newRow().add(2).add(0).add(1).add(10).add(null);
    c.newRow().add(3).add(0).add(1).add(60).add(null);
    return c;
  }
  ...
}

Notez que nous avons supprimé du code précédent les méthodes qui sont générées par défaut par nos IDEs et que nous n’avons pas eu besoin de modifier.

La méthode query est en fait chargée de fournir les données nécessaires à la construction du graphique. Ce listing est l’un des exemples les plus minimalistes nécessaire à l’API pour générer un camembert. Nous utilisons un MatrixCursor afin de passer les valeurs de notre graphique. Au premier abord, la manière de récupérer les données ne semblent pas très claire, la syntaxe n’est pas des plus conviviale. Au final, on dit souvent que la première impression est souvent la bonne

N’hésitez pas à consulter le site officiel pour plus d’informations sur ce projet.

Maintenant que notre content provider est crée, il ne nous reste plus qu’à démarrer l’activité ChartDroid pour afficher notre graphique. Cela s’effectue par un Intent :

Intent chartDroidIntent = new Intent(Intent.ACTION_VIEW, ChartDroidDataProvider.PROVIDER_URI);
chartDroidIntent.putExtra(Intent.EXTRA_TITLE, "Chart droid");
chartDroidIntent.addCategory("com.googlecode.chartdroid.intent.category.PIE_CHART");
startActivity(chartDroidIntent);

Dans le morceau de code précédent, la ligne category est importante car elle définie le type de graphique à afficher.

Après exécution, vous devriez avoir un résultat qui ressemble à cela :

Conclusion

Pour conclure, la solution Google Chart API est la plus aboutie, je vous la recommande vivement. Les graphiques sont obtenus très facilement et sont plutôt jolis. Si vous n’êtes pas prêt à dépendre d’une connexion internet, je vous recommanderais la deuxième solution : achartengine. Bien que cela ne se voit pas sur les captures d’écran ci-dessous, les graphiques obtenus par achartengine sont généralement un peu moins jolis que ceux obtenus par chartdroid. C’est la contrainte d’avoir à installer une application tierce qui cause du tord à la troisième solution.

Pour finir, notez que toutes les solutions n’ont pas été présentées dans cet article. Je pense en particulier aux nombreuses petites surcouches jfreechart qui émergent (et meurent) ici et là. Je ne les ai pas présentées car la majorité d’entre elles ne sont que très peu actives.

Avec la popularisation des smartphones, une nouvelle course démarre. Le nombre d’applications et de sites mobiles explose. Avant de jaillir des starting blocks, prenons le temps de connaitre les spécificités du parcours de cette nouvelle course.

Lorsque je navigue sur le web, je suis installé chez moi. Je suis assis sur une chaise ou un fauteuil confortable. Je dispose d’un écran de taille conséquente qui me permet d’afficher un grand nombre d’informations. Je peux prendre le temps que je désire pour effectuer chacune de mes actions. Je cherche, je farfouille, je compare, je prends des notes. Bref, j’ai directement à disposition tout ce que je désire pour me faire un avis pertinent sur ce que je consomme. La taille de mon écran et la puissance de mon ordinateur me permettent d’ouvrir de nombreuses applications simultanément. Mon confort, mon matériel et ma bande passante me permettent de parler à plusieurs personnes en même temps, d’effectuer des recherches sur internet, tout en écoutant le dernier album en ligne d’un nouvel artiste que je viens de découvrir sur mon forum spécialisé préféré.

Lorsque j’attrape mon smartphone, le contexte est complètement différent. Je suis souvent hors de chez moi et je compte utiliser celui-ci dans un but précis. Bien qu’il soit multitâche, les caractéristiques de mon téléphone ne me donnent pas forcément envie d’effectuer simultanément plusieurs tâches complexes. La taille de mon écran n’est pas adaptée à la lecture ou visionnage de vidéos durant plusieurs heures. Par contre, mon téléphone est un petit bijou technologique ; il dispose d’une puce GPS, d’un détecteur de mouvement, d’une boussole, d’un appareil photo, j’en passe et des meilleures, et surtout, d’une connexion internet mobile. Tout ce matériel ne sert qu’à une seule chose : fournir un maximum d’informations sur le contexte dans lequel j’utilise mon téléphone. Si on appelle ça un smartphone, c’est qu’il y a une raison

Le contexte ! C’est la clé ! Cette information n’a jamais été aussi précise qu’avec un téléphone, il est temps d’en profiter !

Votre ordinateur ne délivre que très peu d’informations sur son contexte d’utilisation. Bien que certaines fonctionnalités piquées de votre mobile arrivent peu à peu sur votre poste fixe (géolocalisation, …), nous restons encore bien loin des possibilités offertes par votre téléphone. La force première de la mobilité est … votre mobilité

Une conclusion découle directement de ce constat : vous avez tout intérêt à créer une application pensée pour la mobilité plutôt que d’essayer d’en adapter une. Essayer d’adapter un site web pour le mobile en n’en modifiant que le look and feel n’apporterait que de la valeur minorée à celui-ci. Penser une version mobile comme une version light de votre application en ligne vous fera passer à côté de ce que recherchent vos utilisateurs. Lorsqu’on utilise son téléphone, on s’attend à trouver de l’information en fonction de son contexte. Utiliseriez-vous l’application de recherche de stations Velib sur votre vélo si celle-ci n’était pas capable d’afficher les stations les plus proches de vous ?

Malgré toute la valeur métier que vos services peuvent fournir, vous ne tirerez vraiment partie de ce nouveau média que si vous prenez en compte le contexte de vos utilisateurs. Pour approfondir ce sujet, je vous suggère la lecture de « Mobile Design and Development » qui y consacre l’un des ses chapitres.

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Oracle poursuit Google pour violation de brevets

RIA

• Bean Validation pour Flex.
• Annonce de jQuery Mobile

SOA

• La NASA ouvre les sources de son cloud privé

Le coin de la technique

• Continuous Delivery, le livre le plus important de 2010 ?

Actualité éditeurs / SSII

Oracle poursuit Google pour violation de brevets

Jeudi dernier, Oracle a lancé une action en justice contre Google pour violation de brevets quant à l’utilisation de Java pour la plateforme Android. L’information a rapidement fait le tour du web et de la twitosphère provoquant à l’encontre d’Oracle son lot de commentaires indignés, notamment dans les communautés Java et libristes (On retiendra le billet peu amène de James Gosling : « The shit finally hits the fan…. »).

Dans sa plainte, Oracle précise que « Android [...] et les appareils qui utilisent Android violent un ou plusieurs brevets parmi les suivants: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; et 6,061,520″. Les brevets en question portent sur l’implémentation de machines virtuelles, l’outillage et les compilateurs.
Google, certainement pour garder les coudées franches, a fait le choix d’implémenter sa machine virtuelle Dalvik sans utiliser OpenJDK (la version GPL2 de Java). Cette implémentation n’est pas pleinement compatible Java et est exécutée sur des terminaux mobiles. Or, lorsque Sun avait « open sourcé une partie de Java » au travers d’OpenJDK, les garanties d’être à l’abri d’attaques pour violation de brevet ne protégeaient que les implémentations pleinement compatibles Java pour desktop et serveur uniquement (pas les implémentations pour terminaux mobiles).
Pour étayer son accusation selon laquelle Google a sciemment violé les brevets relatifs à Java, Oracle avance que Google était, de longue date, au courant des brevets détenus par Sun. Eric Schmidt (CEO de Google) et Urs Hölzle (Senior VP of operations chez Google) ont en effet joué un rôle significatif dans le développement de la technologie Java lorsqu’ils étaient chez Sun.
La réponse de Google à l’attaque d’Oracle (au travers d’un communiqué de presse) est sans surprise : Google estime que la plainte est sans fondement. D’autre part, Google considère qu’avec cette plainte, Oracle n’attaque pas seulement Google, mais aussi la communauté Open Source Java.

A priori, l’objectif d’Oracle n’est pas de « tuer » Android mais de profiter de son succès en imposant à Google de lui reverser une part des revenus de la plateforme. En effet, Java ME est une source non négligeable de revenus pour Sun (Oracle) puisque cette technologie équipe de très nombreux terminaux. Mais le succès fulgurant d’Android sur le marché des smartphones est sur le point de tarir cette source de revenus.
D’autre part, Oracle souhaite sans doute envoyer un message clair quant à sa conception de l’utilisation de la technologie Java là où le silence de Sun vis à vis d’Android pouvait être perçu comme un blanc seing.

Ce genre d’affaire est généralement synonyme de feuilleton judiciaire à rallonge (comme dans le cas emblématique de SCO vs. Linux). Il y a donc peu de chances que le cas Google / Oracle se règle rapidement. La complexité du dossier (notamment en ce qui concerne les tenants et aboutissants techniques) laisse présager de longs débats. Même si l’issu d’un procès reste incertaine Google était certainement préparé à une telle attaque (et est de taille à y faire face) et sa défense sera bien préparée.
Tant que l’affaire ne sera pas réglée, l’ensemble de l’écosystème Android (constructeurs, développeurs, utilisateurs, …) va retenir son souffle, mais l’engouement pour la plateforme Android ne devrait pas trop en pâtir. D’une part, Google continuera de développer la technologie Android. D’autre part, gageons que Google prendra ses responsabilités sur le sujet de la propriété intellectuelle et jouera son rôle de pare feux vis à vis des constructeurs équipant leurs terminaux de l’OS Android.

La fin d’Android est très peu probable. Oracle n’y a aucun intérêt et ce pour plusieurs raisons. D’abord parce qu’Oracle a tout intérêt à ce que Java soit présent sur le marché des smartphones. Or cette présence passe par Android, pas par Java ME et Oracle n’a, aujourd’hui, ni la volonté, ni la capacité d’innover dans ce sens. Ensuite parce que l’essor des smartphones sous Android favorise le développement d’applications utilisant des backend (serveurs) mettant en œuvre des serveurs d’applications Java et des bases de données, augmentant ainsi la taille d’un marché sur lequel Oracle se taille la part du lion. Enfin parce qu’Android réunit une large communauté Java.
Il semble donc que cette affaire ne puisse avoir que deux issues :

• Google sera contraint à verser une partie des revenus d’Android à Oracle. Soit parce qu’Oracle aura gagné un procès, soit parce que Google aura préféré négocier un accord à l’amiable.
• Ce sera le status quo. Soit parce qu’Oracle aura perdu un procès, soit parce qu’Oracle retirera sa plainte suite aux négociations qui vont s’entamer (au cours desquels Google pourrait commencer à utiliser ses brevets comme arme de dissuasion).

Ce qui est sûr, c’est que l’image de Java ne sortira pas grandie de l’initiative d’Oracle (qui semble d’ores et déjà avoir perdu la bataille de l’image).

Pour ceux qui souhaitent approfondir le sujet, l’excellent billet de Charles Nutter « My Thoughts on Oracle v Google » fait longuement le tour de la question et propose des perspectives très intéressantes.

RIA

Bean Validation pour Flex.

Le framework GraniteDS continue à offrir des fonctionnalités riches pour Flex, en parallèle des offres de Adobe, BlazeDs (open source) et LifeCycle ES (commercial).
La version 2.2 (actuellement en bêta publique) ne faillit pas à la règle et amène une rafraichissante innovation : l’implémentation de la JSR 303 (BeanValidation) pour Flex. Toutes les contraintes standard de la JSR sont implémentées via des annotations AS3 et le générateur de code maison (GAS3) permet la conversions des annotations des beans Java.
La validation s’appuie sur une nouvelle fonctionnalité de réflexion.
Autre avancées, peut être moins spectaculaire, la prise en compte des types ‘big numbers’ de Java dans les sérialisations offertes par le framework.
GraniteDs, dont certains avait décrété la mort à la publication de BlazeDs, est toujours bien vivant et comble, en open source, certains manques laissés par Adobe.

Annonce de jQuery Mobile

C’est une nouvelle qui va à coup sûr faire du bruit dans un monde du développement mobile déjà bouillonnant, puisque vient d’être annoncée la sortie pour la fin d’année de la version mobile du framework jQuery. Et ce n’est pas par la petite porte que le célèbre framework web souhaite faire son entrée, puisque contrairement à ses concurrents déclarés, tels que jQTouch ou bien Sensha Touch, jQuery Mobile se veut être un framework JavaScript ciblant la quasi totalité des plateformes mobiles web actuelles (Blackberry, Windows Mobile, iOS pour l’iPhone et l’iPad, Android, Symbian, Bada, …), et permettant de développer des interfaces riches capables de faire rougir bon nombre d’interfaces graphiques natives.

Avec l’avènement d’HTML5 (WebStorage, WebSockets, Vidéo, Géolocalisation, …), du CSS3, et des navigateurs mobiles dernière génération proposant des moteurs JavaScripts performants, la guerre du web semble se trouver un nouveau terrain de bataille, et le web mobile aura sous peu toutes les armes nécessaires pour déstabiliser le business modèle à peine naissant des Markets, tel que l’iTunes App Store ou bien l’Android Market. Le marché des applications mobiles semble donc suivre la voie de son grand frère, celui des applications PC, et proposera à terme de nombreuses applications riches directement par le web.

L’annonce parue sur le site de jQuery Mobile indique que l’un des objectifs du framework est de pouvoir développer une application unique pour toutes les plateformes mobiles. Ce concept, ne semble pas nouveau puisque l’objectif de J2ME sorti il y a 10 ans déjà était bien de développer une solution unique, rappelez-vous: « Write Once, Run everywhere ». Le slogan semble être ici: « Write Less, Do More », mais l’objectif de fond est bien le même.

Palm avec sa plateforme WebOS et Firefox sont déjà sponsors du projet. Bien qu’encore en développement intense, la première sortie est prévue pour fin 2010. Ce framework pourrait bien être une des grandes surprises mobile de 2010 et devenir très rapidement un incontournable pour le développement web d’applications riches pour mobile.

Pour en apprendre plus sur cette déclinaison de jQuery, vous pouvez suivre les liens suivants et apprécier les designs présentés :

• Site officiel de jQuery Mobile
• La device support grid de jQuery Mobile
• Les designs concepts

SOA

La NASA ouvre les sources de son cloud privé

La NASA a récemment annoncé son intention d’offrir le code de son cloud privé Nebula au projet OpenStack en partenariat avec Rackspace. Il s’agit d’une implémentation d’une IaaS orientée vers le calcul scientifique et le stockage de données. Par ailleurs OpenStack est un projet actuellement supporté par plus de 25 firmes, dont Dell et Intel. Il offre une pile logicielle ouverte permettant de créer et exploiter un cloud privé sur la base d’infrastructures matérielles standards. Il est disponible sous la licence Apache 2.0. D’après la présentation du projet, la création d’un nouveau Framework ouvert pour le cloud est motivée par deux raisons principales :

• Le paysage du cloud est actuellement composé d’offres propriétaires, incompatibles entre elles et manquant de transparence, freinant ainsi l’expansion de cette nouvelle industrie. La création d’un framework Open Source permettrait donc une adoption plus massive.
• La plupart des autres projets Open Source existant ne pouvaient satisfaire les énormes besoins de scalabilité exprimés par Rackspace. Seule Nebula, semblait correspondre au besoin.

Pour l’instant le projet est disponible en « Developer preview ». Une première release sera disponible respectivement mi-septembre pour « OS Compute » et mi-octobre pour « OS Storage ».

Le coin de la technique

Continuous Delivery, le livre le plus important de 2010 ?

Continuous Delivery, le livre de Jez Humble et David Farley, est disponible en version finale, en édition papier ou électronique (chez vos revendeurs habituels). Il traite d’un sujet qui tient à cœur de plus en plus d’acteurs de l’écosystème JEE : comment améliorer et dédramatiser les processus de build, de livraison et de déploiement d’un produit. Ce livre recueille déjà de nombreux lauriers. Dont ceux de Martin Fowler (directeur de la collection, donc forcément un peu partial), qui en fait le livre technique le plus important de 2010.

De ce que nous avons pu en lire (par exemple, en RoughCuts ici), ces louanges sont justifiées : ce livre traite de tous les problèmes qui devraient animer n’importe quel consultant au démarrage d’un projet. Collaborer entre équipes, développer de manière incrémentale, tester, automatiser, déployer, tout cela dans un seul but, maximiser la qualité du produit délivré.

Ce livre donnera lieu a un grand nombre de présentations en conférence, qui, si ce n’est déjà fait, devrait vous donner envie d’en faire votre livre de chevet avant la rentrée littéraire.

Pour en savoir plus, consultez le blog Continuous Delivery

Agilité

• L’agilité à la sauce Pixar
• Evitez le multi-tâches dans les équipes de développement

Le coin de la technique

• Développez vos applications Android sans écrire une ligne de code
• Mettez à jour votre JVM

Evènements de notre communauté en France et à l’étranger

• Le programme du Devoxx 2010 se dévoile

Agilité

L’agilité à la sauce Pixar

C’est une question d’actualité avec la sortie de Toy Story 3 : mais comment Pixar fait-il pour cartonner à chaque nouveau film ? InfoQ lève une partie du voile : la cohérence construit la confiance. Derrière cette maxime ‘à l’américaine’ se cache un processus créatif original : Pixar construit des équipes pluri-disciplinaires, qui travaillent ensemble (éventuellement durant plusieurs films) et qui créent des liens de confiance inaliénables. Chaque jour, l’équipe se réunit pour discuter du travail effectué la veille : critiques, remises en cause, les équipes travaillent dans un processus d’amélioration constante. Chaque membre de l’équipe est encouragé à donner son avis, même ses membres les plus juniors.
Ce mode de fonctionnement laisse la place à l’erreur. Comme chacun est impliqué, chacun peut se tromper. Les erreurs sont mêmes une des clés du processus créatif. L’essentiel est de se tromper rapidement, pour pouvoir corriger le tir.

Changez maintenant de point de vue, et regardez cet article sous l’angle du développement logiciel. N’y retrouve t’on pas un fort goût d’agilité ?

Evitez le multi-tâches dans les équipes de développement

Toujours sur InfoQ, Roger Brown nous met en garde contre les méfaits du traitement simultané de projets (tâches, user stories …) par une personne.
Le changement de contexte lorsque l’on passe d’une tâche à l’autre peut prendre plus ou moins de temps en fonction de la complexité de la tâche, du temps et de la nature de l’interruption. Le traitement d’un appel téléphonique, par exemple, pourra engendrer un délai d’un quart d’heure pour se remettre dans le contexte de la tâche précédente. D’autres types d’interruptions (travail sur une autre tâche de développement par exemple) peuvent nous faire perdre beaucoup plus de temps.
L’auteur nous explique que le travail en parallèle sur plusieurs projets implique généralement un surcoût induit par les changements de contexte pouvant représenter de 20% à plus de 50% du temps de travail lorsque nous travaillons simultanément sur plus de deux projets. Il est donc préférable de terminer une tâche (User Story par exemple) avant d’en commencer une autre, plutôt que de fragmenter son travail.
Les méthodes agiles comme Scrum ou le Kanban préconisent un nombre limité de User Stories ou de tâches en cours, et de ne pas en commencer une autre avant d’avoir atteint le statut « Done ».
Le cerveau humain ayant tendance à vouloir traiter plusieurs tâches en parallèle, Roger Brown préconise quelques techniques telles que le pair-programming afin d’aider les développeurs à rester concentrés sur leur tâche et à gagner ainsi en efficacité.
On peut aussi citer le pomodoro qui est une discipline consistant à se ménager un laps de temps de 25 minutes sans interruption, permettant de se focaliser sur une tâche et ainsi de gagner en efficacité.
L’auteur conclut en ajoutant que non seulement le traitement séquentiel des projets (tâches, user stories …) permet de gagner du temps, mais il permet aussi de créer des synergies entre les différents membres de l’équipe qui peuvent ainsi travailler de concert sur le projet.

Le coin de la technique

Développez vos applications Android sans écrire une ligne de code

Google Labs vient d’annoncer l’arrivée d’App Inventor, un éditeur d’applications pour Android destiné aux non-développeurs. L’objectif est de permettre à tout androphile de dessiner sa propre application depuis le logiciel, puis de la transférer sur son smartphone.

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Pour le moment, il n’est pas possible de s’inscrire. Vous pouvez seulement montrer votre intérêt en remplissant un formulaire dans lequel vous exprimerez votre enthousiasme pour l’utilisation d’AppInventor dans un cadre universitaire. Si vous n’avez rien à voir avec quelconque formation, vous pouvez toujours laisser les réponses vides.

En épluchant le site, on constate la forte volonté d’installer cet éditeur dans le monde universitaire, voire scolaire. En effet, il est fait mention à plusieurs reprises des possibilités de développements de jeux, d’applications communautaires ou d’outils d’interaction entre étudiants. Malgré tout, Google n’oublie les autres… le particuliers lambda, ou le collègue que nous sommes en précisant:

The App Inventor team has created blocks for just about everything you can do with an Android phone, as well as blocks for doing « programming-like » stuff.

Nous nous posons tout de même quelques questions à ce sujet:

• Google préfèrerait-il que nous apprenions à utiliser son logiciel plutôt qu’écrire du code propre personnalisé?
• Ne se cache-t-il pas un envie de maîtriser le code généré? (en y ajoutant des statistiques par exemple…)
• N’y a-t-il pas un risque de voir proliférer sur le market des applications réalisées en 5 minutes, pleines de pubs et pauvres sur les plans fonctionnel et graphique? (comme HelloPurr, cf. vidéo de démo)

Le futur nous le dira…

Du côté de la technique, les outils utilisés sont OpenBlocks et Kawa Language Framework. Le premier est le fruit de la thèse de Ricarose Roque (MIT) : une librairie Java permettant de programmer des systèmes à l’aide de blocs visuels. Le second est utilisé par le compilateur pour traduire en bytecode les blocs graphiques.

En attendant d’avantage d’informations et pourquoi pas un article plus complet sur l’outil, vous trouverez déjà quelques tutoriaux sur le site.

source : site de l’éditeur

Mettez à jour votre JVM

Après une dernière release qui corrigeait un problème de sécurité, Oracle nous invite à télécharger la release 21 qui, outre la correction de bugs (mais pas de correction liée à la sécurité), apporte des améliorations sur la JVM HotSpot et VisualVM.

Sur la Java HostSpot VM, les améliorations portent sur la compression des pointeurs d’objets, escape analysis (qui améliore la gestion des piles), la gestion du cache sur le byte code, sur le garbage collector CMS (Concurrent Mark-Sweep) et G1. Pour rappel, G1 est le nouveau garbage collector en préparation pour la JDK 7 mais déjà utilisable dans la version 6 depuis la release 17. Pour l’activer il faut passer les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC.

La version 1.2.2 de VisualVM, sortie il y a quelques mois, est à présent incluse dans la distribution de Java SE. Elle apporte beaucoup d’améliorations sur l’analyse de la mémoire et sur le profilage.

Enfin pour les développeurs de RIA java, un listener a été ajouté pour suivre l’évolution du chargement de l’application. Plus de détails ici.

Evènements de notre communauté en France et à l’étranger

Le programme du Devoxx 2010 se dévoile

J’espère que vous avez créé une règle sur votre outil de mailing préféré qui décline toute demande de réunion sur la période du 15 au 19 novembre 2010 car c’est … Devoxx!
À moins d’être parti 8 ans en mission dans l’océan arctique sur un brise glace, vous ne pouvez pas ne pas connaître Devoxx. C’est LA conférence européenne spécialisée sur LA technologie (i.e. Java) qui se déroule tous les ans à Anvers en Belgique.

Tout le gratin des meilleurs speakers et spécialistes sera présent dont certains français: Antonio Goncalves, Guillaume Laforge, Emmanuel Bernard pour ne citer qu’eux, mais aussi des incontournables comme Heinz Kabutz, John Smart ou bien Michael Cote.
Mais ce n’est pas tout! En effet, un BoF (Bird of Feather) organisé par les JDuchess se prépare.

Le programme commence à prendre forme. Vous pouvez commencer à saliver sur des conférences plus intéressantes les unes que les autres avec quelques titres accrocheurs:

• JAX-RS, Java EE 6, and the future,
• Reflection Madness,
• Improve the performance of your Spring app,
• HTML 5 Fact and Fiction,
• Comparing JVM Web Frameworks,
• Groovy update, ecosystem, and skyrocketing to the cloud with App Engine and Gaelyk,
• Restfulie: quit pretending, use the web for real,
• Women in IT an unconference,
• etc.

Dans le programme de cette année, c’est surtout la présence de plus d’une dizaine de sessions dédiées aux technologies NoSQL et Cloud que l’on retiendra. On se souvient en effet que l’édition 2009 de cette conférence n’avait proposé qu’une trop courte session d’introduction à NoSQL suivie d’un BOF. Cette augmentation sensible de la part accordée à ces technologies témoigne de leur popularité croissante en 2010. Une fois de plus Devoxx s’affirme comme le baromètre de notre écosystème !

Qu’est ce qu’un KawaCamp ? C’est un BarCamp dédié aux sujets qui gravitent autour de l’écosystème Java ! Et qu’est-ce qu’un BarCamp alors ? Pour résumer voici la définition de Wikipedia. Nous allons nous retrouver entre passionnés pour discuter de sujets qui nous tiennent à coeur autour de tables rondes/ateliers durant lesquels chacun participe et donne son point de vue.

Les sujets sont choisis grâce aux centres d’intérêts que chacun exprime sur la page d’inscription. Cette session s’oriente vers les sujets d’actualité avec beaucoup de HTML5 et d’Android sans oublier NoSQL, TDD, Agilité, …

Si vous aimez les discussions passionnées autour d’un verre, le KawaCamp vous comblera en organisant nos débats !

Informations pratiques :

• La page d’inscription : Kawa Camp Paris 2.
• Les organisateurs : Luc Bizeul et Philippe Antoine.
• La date : Jeudi 27 Mai 2010 à partir de 19h00.
• L’adresse : Xebia – 156 boulevard Haussmann, 75008 Paris.

Ils en parlent :

• FrAndroid – Barcamp : KawaCampParis2 .
• Le Calendrier des JDuchess.

Actualité éditeurs / SSII

• (VMware + Spring) + SalesForce = VMforce
• Refonte de jBPM chez JBoss
• Josh Bloch : le futur de Java, sous la houlette de Oracle

Le coin de la technique

• Scalate : un moteur de template pour Scala
• Le multitâche sur Android

Evènements de notre communauté en France et à l’étranger

• Scaladays 2010 intégralement disponible en vidéo !

(VMware + Spring) + SalesForce = VMforce

Le 27 avril dernier, Paul Maritz (CEO de VMware), Marc Benioff (CEO de SalesForce) et Rod Johnson (GM de SpringSource) ont fait une annonce conjointe pour le lancement d’une nouvelle solution cloud: VMforce.

Jusqu’à maintenant SalesForce était un des acteurs majeurs des SaaS (Software as a Service), spécialisé dans les CRM. Mais la montée en puissance de concurrents dans le cloud a poussé l’entreprise à revoir sa stratégie. Pour créer ou personnaliser des applications de SalesForce, les développeurs devaient s’appuyer exclusivement sur la plateforme de développement Force.com et sur son langage maison, l’Apex Code, relativement confidentiel. Il faut donc voir ce partenariat, avant tout, comme une ouverture des services de SalesForce au monde Java et en particulier celui de SpringSource.

Concernant Java, il est intéressant de constater que ce langage devient celui de référence pour toute solution cloud qui veut se populariser ou se standardiser. Il y a plus d’un an, Google avait subi de fortes pressions de la part de la communauté pour pouvoir utiliser Appengine avec Java en plus de Python. Encore plus étonnant, la solution cloud Azure de Microsoft propose également des ponts vers Java.

D’après Rod Johnson Spring sera vraiment au cœur de cette nouvelle offre. Son serveur tomcat, tcServer, constituera l’environnement d’exécution. SpringSource Tool Suite jouera un rôle important pour faciliter l’interopérabilité avec Force.com. On nous promet, entre autres, du drag and drop pour déployer directement des applications. Cela peut prêter à sourire mais ce genre de détail peut parfois faire basculer certains DSI, la véritable cible de cette nouvelle offre, qui cherchent les solutions les mieux intégrées aux environnements utilisés par leurs développeurs.

De son côté Force.com apporte un accès à sa base de donnée relationnelle et à de nombreux services de rapport et de partage. De plus le développement de services orientés réseau social, avec des interfaces par exemple avec Twitter ou Facebook, de ponts vers les API Google ou de portage vers les téléphones mobiles, constitue une des originalités de SalesForce et un des points forts par rapport à ses concurrents.

Cette annonce peut en étonner certains qui avaient suivi celle de l’intégration de SalesForce dans Google AppEngine, d’abord dans sa version Python puis Java. Le peu d’écho qu’elle a eu semble souligner le peu de synergies qui existent dans l’association de ces deux solutions et VMforce a, sur le papier, tout pour remplacer AppEngine comme PaaS (Platform as a Service) de référence. Bien sûr tout cela reste encore à confirmer car le lancement véritable est attendu cet automne (vous pouvez vous pré-inscrire sur cette page). Est-ce que l’intégration dans STS tiendra ses promesses ? Est-ce que cette solution arrivera à convaincre les entreprises d’externaliser une partie de leur système d’information ?

Refonte de jBPM chez JBoss

Tout commença il y a un mois par une lettre ouverte à la communauté jBPM pour annoncer le départ de JBoss de Tom Baeyens et Joram Barrez, respectivement project leader et core developer du projet de gestion de workflow de l’éditeur. Quelques jours plus tard, Tom Baeyens explique qu’ils souhaitent développer, avec Joram Barrez, leur propre plate-forme BPM, qui supportera BPMN 2.0, adoptera une licence Apache 2.0 et sera adaptée « aux nouvelles infrastructures IT ». Le flou de cette dernière mention s’éclaircit en partie lorsque nous croisâmes Tom Baeyens à la conférence NoSQL Europe de Londres ; il nous expliqua s’intéresser de près aux problématiques de persistance liées au Cloud Computing. Cette vision rafraichissante du BPM sera particulièrement intéressante à suivre…

Du coté de JBoss, l’affaire a entrainé un vaste projet de refonte. Ainsi Alejandro Guizar, nouveau project lead de jBPM, a publié deux semaines plus tard l’annonce du développement de jBPM 5 qui consistera en une fusion de jBPM et de Drools Flow. Ceci aboutirait donc à un rule driven process engine, nom donné aux moteurs BPM fusionnés avec un moteur de règles. Cette vision constitue la tendance depuis quelques temps déjà sur ce marché, mais jBPM et Drools n’avaient pas su prendre ce virage pour cause d’avis divergents entre les deux équipes. Cet évènement semble donc avoir été l’occasion d’une remise en question globale. Mark Little, CTO de JBoss, s’exprimait il y a une semaine sur l’avenir de la brique BPM de JBoss. Il reprenait ces faits en ajoutant une nouvelle importante : jBPM 4 ne deviendra pas un produit supporté par JBoss au sein de sa plate-forme commerciale SOA. Ce sera le rôle de jBPM 5.

jBPM est le moteur BPM Open Source majeur sur le marché. Ce changement de plan est donc important tant pour la communauté qui a déjà commencé à investir sur jBPM 4, sorti il y a 10 mois, que pour JBoss qui avait fortement investi dans jBPM 4. Ce dernier avait d’ailleurs connu une période de gestation particulièrement longue. Bien sûr ces investissements de part et d’autre ne sont pas perdus pour autant puisque cette nouvelle version s’appuiera pour partie sur l’existant, mais elle peut remettre en question certains choix stratégiques pour les entreprises.

Josh Bloch : le futur de Java, sous la houlette de Oracle

Pour InfoQ, Josh Bloch, l’auteur du fameux « Effective Java », fait part de ses préoccupations au sujet du futur de Java. Tout d’abord, il constate que son évolution a ralenti ces derniers mois, pour deux raisons principales :

• le manque d’implication de Sun dans les travaux autour de Java 7, qui a conduit à sans cesse repousser sa date de sortie.
• la confusion qui règne autour des différentes licences utilisées par le JCP, qui amène parfois des séparations étranges comme celle qui a eu lieu entre OpenJDK et Harmony. De plus, le support de certains éditeurs (Google a choisi Harmony comme base aux librairies Android) ne fait qu’ajouter à la confusion et à la discorde.

Oracle, en meilleure santé financière que Sun, peut sortir le JCP de l’impasse en soutenant des réformes de fond, et en portant un regard neuf sur un certain héritage un peu ‘poussiéreux’. En particulier, Oracle a déjà proposé en 2007 de réformer les règles de propriété intellectuelle du JCP pour qu’elles deviennent plus permissives pour tous les composants de base (avec une licence de type Apache ou BSD).
Pour cette raison, Josh Bloch aimerait voir Oracle réclamer le bâton de commandeur qui était la propriété de Sun.

D’autre part, les statistiques montrent une baisse de l’utilisation de Java, au profit de C. Malgré cela, aucun des « nouveaux langages » (Scala, Ruby…) n’émerge suffisamment pour apparaitre dans ces statistiques et expliquer ce désamour. Cependant, ils restent des vecteurs d’innovation qu’il faut surveiller.
Et contrairement à ce que disent les statistiques, Josh Bloch ne pense que pas Java, aussi bien en tant que langage qu’en tant que plate forme, soit sur le déclin. Il voit certes un risque de déclin, mais il compte sur Oracle et sur la communauté pour l’enrayer. D’ailleurs, il ne voit pas émerger d’alternative crédible au langage et à la JVM. D’autant plus qu’Oracle ne devrait pas prendre le risque de tenter de mettre la JVM sous licence.
En ce qui concerne la fusion JRockit / Hotspot, elle est sur le papier intéressante, mais Sun n’est jamais parvenu à réaliser une telle fusion, ne serait ce que pour les JVM client et serveur. Pour le moins, ses coûts seront élevés.

Pour finir sur une note positive, Josh Bloch rappelle que Java a connu quelques succès retentissants ces derniers mois : Google Collections, Guice, les nouveaux langages de la JVM, et Android. En comptant sur des actions décisives d’Oracle, et la coopération d’une communauté élargie, le futur de java s’annonce (malgré tout ?) brillant.

Le coin de la technique

Scalate : un moteur de template pour Scala

Voilà une bonne occasion de vous parler d’un framework qui monte dans le monde Scala, à savoir Scalate. James Strachan a annoncé sa sortie fin de semaine dernière en version 1.1. Le détail des nouveautés se trouve ici.

Scalate, pour Scala Template Engine, est un moteur de template qui s’appuie sur Scala 2.8 et permet de générer plusieurs type de documents (texte, balises…). Il est actuellement utilisable :

• de manière standalone,
• dans des Servlets,
• dans Jersey,
• dans Play! Framework grâce au projet Play-Scalate,
• et dans Apache Camel,
• avec prochainement l’intégration à Lift.

Scalate supporte les templates de type SSP pour Scala Server Pages dont Velocity ou bien encore JSP. Ainsi Scalate supporte ${ }, <%= %>, <% %> ou bien encore #for, #if et #{ }. L’autre format géré est le Scaml pour Scala Markup Language qui est un dialecte (haml) pour simplifier la description d’un document web. Petit exemple :

// ssp template
<p>
   <%= List("hi", "there", "reader!").mkString(" ") %>
   ${ "yo "+(3+4) }
</p>
// ssp rendering
<p>
   hi there reader!
   yo 7
</p>
// scaml template
%gee
   %whiz
      Wow this is cool!
// scaml rendering
<gee>
   <whiz>
      Wow this is cool!
   </whiz>
</gee>

Il n’y a plus qu’à jouer avec !

Le multitâche sur Android

Qui aurai cru il y a encore peu que nous disposerions aujourd’hui d’équipements de poche ayant les capacités de faire tourner plusieurs applications riches simultanément, en Java qui plus est, malgré sa réputation de glouton en mémoire ? Ce temps là est révolu et Android montre combien un système basé sur Java peut se montrer performant. Néanmoins, pour atteindre cet objectif, il aura fallu que Google mette au point de nombreuses techniques. C’est ce que nous explique cet article du Android Developers blog, le blog Google de référence sur le sujet.
Les objectifs (simplifier la vie de l’utilisateur au maximum en supprimant la notion de « fermer » une application…) et les contraintes (pas de swap…) sont expliqués ainsi que leurs conséquences sur la gestion de la mémoire dans les applications et l’OS.

on découvre certaines spécificités qui peuvent sembler étonnantes au commun des programmeurs. ainsi, des applications qui apparaissent en cours d’exécution peuvent n’avoir en fait aucun processus en cours ! Un autre point très intrigant est que les applications sont généralement tuées brutalement ! L’astuce consiste à garder la trace des parties de l’application visibles, les Activity, pour les redémarrer avec les infos de leur dernier état si besoin. si l’utilisateur n’y voit que du feu, le programmeur expérimenté sera lui surpris par ce fonctionnement peu orthodoxe mais visiblement efficace.

L’article va ensuite plus loin en explorant la façon dont sont gérés les services, à travers les notions de Broadcast Receivers et de Services. Les premiers permettent de réagir ponctuellement et brièvement à des stimuli externes alors que les seconds effectuent des opérations longues mais sans garanties aucune quant à leur survie: Android peut les tuer en cas de besoin.

Rassurez-vous, tout n’est pas complètement nouveau dans Android et certains concepts restent identiques à ce que l’on connaît en Java desktop. Sur developpez.com Davy Leggieri nous offre 2 bons articles: l’un sur les threads composants une application Android et l’autre plus précisément centré sur l’UI Thread. Cela rappellera des souvenirs aux développeurs Swing qui, avec son Event Dispatch Thread, impose des contraintes similaires. Les environnements changent, mais certains fondamentaux restent !

Evènements de notre communauté en France et à l’étranger

Scaladays 2010 intégralement disponible en vidéo !

Si comme moi vous n’avez pas pu vous rendre au Scaladays 2010 de Lausanne, réjouissez-vous : toutes les vidéos sont déjà disponibles à cette adresse !
Du discours d’ouverture de Martin Odersky en passant par les Parallel Collections ou bien encore une session sur Scala at LinkedIn, redécouvrez les grands moments de cette première grosse conférence sur Scala. Les vidéos sont disponibles en basse et haute qualité et, pour les nomades, des verions .mp4 sont téléchargeables.
Je sais déjà ce que je vais regarder dans le bus dans les prochaines semaines
Et pour un petit résumé de ces deux jours, je vous renvoie vers le blog de François pour un article qui ne peut que faire regretter de pas y être allé…

Étonnamment, ce besoin ne semble pas intéresser plus que cela la communauté Android. En consultant la liste des demandes d’évolutions, seule une fiche fait référence à ce type de besoin. Cette demande me paraissant pourtant légitime, j’en ai discuté avec Romain Guy, l’un des développeurs Android. Selon lui, la plateforme Android ne permet pas de répondre directement à cette problématique. Tournons-nous donc vers nos outils de builds.

Cet article présente une manière de configurer un build Maven sur une application Android. Après la lecture de cet article, vous saurez comment construire et déployer un projet Android en utilisant Maven, mais également comment découper vos applications pour partager du code entre votre application Android et sa partie serveur, et comment partager du code et des ressources entre différentes applications Android. Le contenu de cet article est largement inspiré de la traduction officielle du chapitre Android du Maven Reference Guide que je viens tout juste de terminer.

Le plugin Maven Android

Le plugin Maven Android permet de construire, déployer et publier des applications Android avec Maven. Vous pouvez ainsi tirer parti des fonctionnalités Maven dans une application Android. Voyons comment utiliser un projet multi-module et la gestion des dépendances pour arriver d’une part à factoriser du code entre l’application Android et ses services web côté serveur, d’autre part à externaliser les assets/ressources communs entre plusieurs projets Android.

Pour installer ce plugin, récupérez-les sources du projet sur google code et installez les artefacts dans votre dépôt :

git clone git://github.com/jayway/maven-android-plugin.git
cd maven-android-plugin
mvn clean install

Préparez votre environnement Android pour Maven

Avant de pouvoir utiliser Maven pour construire vos applications Android, quelques tâches préalables sont nécessaires :

• Installation du SDK Android
• Installation des jars de l’API Android dans un dépôt (local et/ou distant)
• Configuration de Maven pour simplifier l’utilisation du Maven Android Plugin

Installation du SDK Android

Le plugin Android Maven nécessite la présence du SDK Android dans votre environnement de développement. La variable d’environnement ANDROID_HOME doit être configurée pour pointer vers le répertoire d’installation du SDK Android. Ce SDK doit être installé en suivant les consignes disponibles sur le site officiel Android Developer.

En plus du SDK, vous devez également installer les différentes versions des plates-formes dont vous avez besoin pour votre développement. Il s’agit des différentes versions des runtimes Android dont vous désirez vous servir. Par défaut, vous pouvez choisir de toutes les télécharger. Pour en savoir plus à ce sujet, rendez-vous également sur la documentation officielle.

Enfin, afin de faciliter l’utilisation des outils du SDK en ligne de commande, vous pouvez rajouter le répertoire ANDROID_HOME/tools à votre PATH.

Installation des artefacts Android dans votre dépôt

Une fois que le SDK est installé, vous devez mettre à disposition les différents JARs d’API dans un dépôt Maven. L’outil Maven Android SDK Deployer permet d’effectuer cette tâche. Une fois l’outil téléchargé, rendez vous dans son répertoire et tapez la commande mvn clean install. Par défaut, cette commande installe les JARs android.jar et maps.jar dans votre dépôt local. Cet outil vous permet de n’installer qu’une partie des plateformes dans votre dépôt ou de les déployer dans sur un serveur distant, si ces fonctionnalités vous intéressent, rendez-vous à l’adresse suivante

Configuration de Maven pour Android

Afin de pouvoir utiliser les goals du plugin Maven Android à partir de la ligne de commande en utilisant la version courte du nom du plugin ‘android’, vous devez ajouter l’extrait de configuration suivant dans votre fichier settings.xml.

<pluginGroups>
   <pluginGroup>
     com.jayway.maven.plugins.android.generation2
   </pluginGroup>
</pluginGroups>

Utilisation du Maven Android Plugin dans un projet simple

Une fois que votre environnement est correctement configuré, vous pouvez configurer Maven pour construire vos applications Android. Pour cela, ajoutez ce pom.xml à la racine de votre application.

<?xml version="1.0" encoding="UTF-8"?>
  <project xmlns="http://maven.apache.org/POM/4.0.0"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
      <modelVersion>4.0.0</modelVersion>
      <groupId>fr.xebia.android.demo.simple</groupId>
      <artifactId>simple-android-project</artifactId>
      <version>1.0-SNAPSHOT</version>
      <packaging>apk</packaging>
      <name>Simple Android Project</name>
      <dependencies>
          <dependency>
              <groupId>android</groupId>
              <artifactId>android</artifactId>
              <version>2.1_r1</version>
              <scope>provided</scope>
          </dependency>
      </dependencies>
      <build>
          <sourceDirectory>src</sourceDirectory>
          <plugins>
              <plugin>
                  <groupId>com.jayway.maven.plugins.android.generation2</groupId>
                  <artifactId>maven-android-plugin</artifactId>
                  <version>2.2.3-SNAPSHOT</version>
                  <configuration>
                      <sdk>
                          <platform>2.1</platform>
                      </sdk>
                      <deleteConflictingFiles>true</deleteConflictingFiles>
                     <undeployBeforeDeploy>true</undeployBeforeDeploy>
                  </configuration>
                  <extensions>true</extensions>
              </plugin>
              <plugin>
                  <artifactId>maven-compiler-plugin</artifactId>
                  <configuration>
                      <source>1.5</source>
                      <target>1.5</target>
                  </configuration>
              </plugin>
          </plugins>
      </build>
  </project>

Ce pom.xml est tout à fait traditionnel excepté les points suivants :

• Il dispose d’un nouveau type de packaging ‘APK’
• Deux plugins sont configurés dans le build : Maven Android et Maven Compiler

Le type de packaging APK permet d’activer le cycle de vie spécifique à Android. Il fait le lien entre Maven et les outils du SDK Android, permet la gestion des ressources, la conversion du bytecode Java en code exécutable Dalvik …

La dépendance vers le JAR de la plateforme doit utiliser la version de la cible telle qu’elle a été publiée dans le dépôt Maven par l’Android SDK Deployer. Il récupère les versions à partir des valeurs Platform.Version et Pkg.Revision renseignées dans le fichier de propriétés source.properties qui se trouve dans le dossier de la plateforme du SDK Android.

La configuration du plugin Maven Compiler dans le build est également nécessaire, car Android utilise les fonctionnalités Java 5 (annotations, boucles simplifiées…).

Pour construire l’application et l’exécuter sur un émulateur déjà lancé, lancez la commande :

mvn clean install android:deploy

Ajoutez des tests à votre application Android

Le test du code d’une application Android peut-être effectué à la manière d’un test unitaire traditionnel junit dans le cadre du SDK Android, mais aussi par l’intermédiaire de tests d’intégration. Ces derniers sont appelés ‘instrumentation tests’.

Exécution des tests unitaires d’un projet Android via Maven

Le plugin Android Maven lance l’exécution des tests unitaires à la manière du plugin Surefire. Comme le chemin par défaut des classes de tests dans Eclipse et dans l’Android Development Toolkit ne respecte pas la convention Maven, vous devez configurer spécifiquement le dossier d’accès au code de vos tests unitaires.

<build>
  <testSourceDirectory>test</testSourceDirectory>
  ...
</build>

Gérez vos tests d’instrumentation Android avec Maven

Les tests d’instrumentation sont des tests d’intégration packagés dans une application qui est lancée dans un émulateur (ou un téléphone) et qui interagit avec une autre application pour tester son comportement. Pour exécuter les ces tests d’instrumentation, vous devez disposer de deux projets distincts : l’un pour l’application, l’autre pour les tests d’instrumentation. Ces modules sont liés par l’intermédiaire d’un pom parent.

La configuration du plugin Maven Android pour l’application contenant les tests d’instrumentation est la même que pour celle de l’application principale avec une seule différence : l’ajout d’une dépendance vers l’application principale. Il est important d’ajouter le type apk sur cette dépendance pour permettre au plugin Maven Android de trouver le package de l’application.

<dependency>
      <groupId>fr.xebia.android.demo.simple</groupId>
      <artifactId>simple-android-project</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>apk</type>
</dependency>

Rajoutez des Add-On à vos applications Android

Pour la majorité des applications, l’artefact du SDK (android.jar) suffit, il arrive pourtant que certaines applications nécessitent des Add Ons. L’un des Add-Ons les plus connus est celui de Google Maps. Cet Add-On a été déployé dans votre dépôt Maven par l’outil Maven Android SDK Deployer. Afin de pouvoir utiliser cette API, vous avez besoin d’ajouter une dépendance à votre application :

<dependency>
  <groupId>com.google.android.maps</groupId>
  <artifactId>maps</artifactId>
  <version>7_r1</version>
  <scope>provided</scope>
</dependency>

Découpez vos projets Android avec Maven

Le plugin Maven Android peut être utilisé sur un projet multi-module de manière transparente, voici comment je vais découper mes projets :

Le socle contient :

• Une application contenant le code et les ressources Android communes à toutes mes applications Android

Chaque application contient :

• Un projet pour le code Java réutilisé côté serveur. Cela permet de partager du code entre une application Android et une application Web.
• Une application web de type WAR contenant la partie serveur de l’application. C’est cette partie qui fournit les services distants à l’application Android.
• L’application Android proprement dite est un projet Maven de type APK qui possède une dépendance sur le modèle et une dépendance sur le socle. C’est son pom qui configure le plugin Maven Android. Notez le type particulier de la dépendance vers le socle : apksources, les sources et ressources incluses dans cette dépendance sont poussées dans l’application courante avant sa construction.

<dependency>
      <groupId>fr.xebia.android.demo.socle</groupId>
      <artifactId>socle-sample</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>apksources</type>
</dependency>
<dependency>
      <groupId>fr.xebia.android.demo.simple</groupId>
      <artifactId>simple-model</artifactId>
      <version>1.0-SNAPSHOT</version>
</dependency>

• Un dernier projet contenant les tests d’intégration qui dépend de l’application précédente.

<dependency>
      <groupId>fr.xebia.android.demo.simple</groupId>
      <artifactId>simple-android-project</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>apk</type>
</dependency>

Notez cependant que ce plugin Maven Android est toujours en cours de développement, j’ai rencontré de nombreux bugs. Le dernier en date, et pas des moindres : la fonctionnalité ‘apksources’ ne fonctionnait plus. Utilisez ce genre de fonctionnalité que si vous n’avez pas peur de mettre les mains dans les sources du plugin en cas de problème. Tout cela sent encore la peinture fraîche, reste à savoir si elle va tenir.

La solution Maven ne vous a pas séduit ? Il est vrai qu’elle reste lourde et relativement compliquée, mais il existe bon nombre d’alternatives Ant, AndroidAnt, Eclipse Linked Source, ln -s …

Agilité

• Quand Toyota se met au Lean

Le coin de la technique

• Ehcache 2.0 : un renouveau ?
• Scalaj Collections
• Sonar 2.0
• MySQL + Memcached vs Cassandra

Evènements de notre communauté en France et à l’étranger

• Kawa Camp Paris mardi : HTML 5, Android, NoSQL

Agilité

Quand Toyota se met au Lean

Tout le monde le sait, le Lean est l’adaptation du système de production de Toyota au développement logiciel. Et pourtant, qui est en train de s’inspirer du Lean pour améliorer son développement logiciel ? … Toyota!
Dans cet article, Henrik Kniberg (l’auteur de « Scrum and xp from the trenches ») nous raconte comment il a découvert avec stupeur que Toyota utilisait encore le « bon » vieux cycle en V pour le développement logiciel. Conscient des problèmes rencontrés il semblerait cependant que les équipes de développement de Toyota s’orientent vers les méthodes agiles. La boucle est ainsi bouclée!

Le coin de la technique

Ehcache 2.0 : un renouveau ?

Ehcache est une solution de cache Open Source qui est longtemps restée très basique : aucun mécanisme de réplication n’était proposé. Le projet se limitait alors une table de hachage enrichie d’une logique d’éviction et d’offload sur disque. La réplication du cache sur plusieurs nœuds par RMI est apparue tardivement, et fut suivie d’autres technologies de réplication telles que JGroups ou JMS. Plus récemment, l’acquisition du projet par Terracotta fut assez logiquement suivie de l’introduction d’une réplication par Terracotta en version 1.7.

Ces dernières années ont donc vu un enrichissement (ou une complexification) croissant d’Ehcache. Une nouvelle version 2.0 vient d’être annoncée par Terracotta et les nouveautés incluses créent une nouvelle fois la rupture avec les versions précédentes :

• Support de JTA : Ehcache se comporte maintenant comme une ressource transactionnelle XA. Ce support de JTA place ainsi EhCache face à JBoss Cache, maintenant renommé Infinispan, qui se démarquait jusqu’alors parmi les caches Open Source par ses capacités transactionnelles.
• Write-behind : Ehcache est maintenant capable d’écrire de manière asynchrone et planifiée dans la ressource dont il est la façade.

Les autres nouveautés concernent diverses améliorations liées à la configuration dynamique d’Ehcache ou à l’utilisation de Terracotta.

Il s’agit donc bien d’une version majeure pour Ehcache qui propose désormais de nombreuses fonctionnalités dédiées aux architectures distribuées. Le poids de la distribution s’en ressent puisqu’il est passé de 300 Ko pour la version 1.0 a 14 Mo pour la version 2.0 : une vraie rupture…

Scalaj Collections

Voici une petite librairie fort sympathique qui permet de convertir une collection Java vers une collection Scala et inversement (vu sur le Coderspiel).

La librairie enrichit certaines classes existantes comme List, Map et Set côté Scala ou ArrayList côté Java. Une fois l’objet créé et si besoin initialisé avec certaines données, il suffit d’appeler la méthode asJava ou asScala pour modifier le type l’objet. Il est aussi possible d’appeler la méthode foreach sur une liste Java. Les méthodes map, filter et flatMap sont en cours de développement. Quelques exemples :

List(1, 2, 3).asJava   // returns java.util.List1
Map(1 -> "a", 2 -> "b", 3 -> "c").asJava   // returns java.util.Map1
val list = new java.util.ArrayList1
list.add(1)
list.add(2)
list.asScala   // returns scala.Seq[Int]
list.foreach(print)   // prints "123"

Le projet est hébergé sur GitHub. Vous pouvez récupérer le jar à cette adresse ou par maven :

<dependency>
  <groupId>org.scalaj</groupId>
  <artifactId>scalaj-collection_${scala.version}</artifactId>
  <version>1.0.Beta1</version>
</dependency>

Sonar 2.0

Dans cette première release de 2010, l’équipe Sonar élargit le champs d’analyse de leur outil en y ajoutant un septième axe d’analyse de qualité logiciel. Pour rappel, les six premiers axes déjà supportés par Sonar sont:

• La couverture de code par les tests unitaires
• La distribution de la complexité (par classe et par méthode)
• La recherche de bugs potentiels (avec FindBugs)
• La détection des codes dupliqués
• L’insuffisance des commentaires
• Le respect des normes du langage

Le septième et dernier axe, propose d’évaluer la conception objet à l’aide:

• D’une matrice de dépendance des classes, équivalente à la DSM de IntelliJ Idea
• Des métriques de Chidamber & Kemerer (DIT, NOC, RFC, CA, CE, LCOM4)

Ces nouveaux outils vont nous permettre, d’une part, de détecter et résoudre les cycles de dépendances, et, d’autre part, de surveiller l’étendue des responsabilités de nos classes. L’équipe Sonar reste donc très active, elle prévoit d’ailleurs une nouvelle version pour le courant du mois de mai avec notamment la détection de code mort dans la roadmap.

• L’annonce sur le blog Sonar
• La release note
• La roadmap

MySQL + Memcached vs Cassandra

Après Twitter il y a un mois, c’est maintenant Digg qui vient d’abandonner sa solution de persistance basée sur MySQL et Memcached au profit de Cassandra. Les raisons invoquées pour l’abandon de leur précédente solution de persistance restent les mêmes :

• Complexité induite par le partitionnement de MySQL
• Manque de scalabilité de l’ensemble
• Maintenance délicate du cluster MySQL

Le choix de Cassandra parmi l’ensemble des base de données NoSQL disponibles était quant à lui dirigé par les qualités que l’on reconnait souvent à ce projet :

• Sa nature column-oriented apporte une persistance plus structurante qu’une simple solution clé-valeur
• Son architecture peer to peer ne présente pas de single point of failure assurant donc la haute disponibilité
• Le projet bénéficie d’une large communauté, gage de pérennité de l’investissement

Les difficultés à gérer de très larges volumes de données dans les bases de données relationnelles sont ainsi régulièrement mises en avant. Ainsi Philip Tellis publiait il y a quelques mois son retour d’expérience sur un projet nécessitant la persistance de quelques 40 millions d’enregistrements par jour dans une base de données MySQL partitionnée : on se rend rapidement compte des nombreux efforts nécessaires à la mise en œuvre d’une telle architecture en comparaison à la solution clé en main proposée par Cassandra.

Face à cette opposition, il est intéressant de se souvenir que Facebook, le créateur de Cassandra, est également le plus gros utilisateur de Memcached au monde. Il y est utilisé conjointement à MySQL montrant ainsi que l’un des contributeurs majeurs du mouvement NoSQL a su tirer le meilleur de ces deux mondes.

Evènements de notre communauté en France et à l’étranger

Kawa Camp Paris mardi : HTML 5, Android, NoSQL

Le Kawa Camp Paris 1 se déroulera demain mardi 23 Mars à partir de 19h00 au Quigley’s Point. Les thèmes qui suscitent le plus d’intérêts sont cette fois HTML 5, Android et NoSQL. Déjà 32 participants confirmés et 11 autres qui tenteront de venir.

Les Barcamp Java sont un très bon moment pour discuter de technique comme de carrière et d’entretenir son réseau.

Actualité éditeurs / SSII

• Innovation permanente chez Google
• Java SE 5 en fin de vie, JDK 7 en approche

SOA

• 10 mythes au sujet des SOA

Evènements de notre communauté en France et à l’étranger

• Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l’actualité cette semaine avec la mise à disposition d’un nouveau langage de programmation et d’un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu’il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d’abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d’expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu’il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d’entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n’est pas adapté au Web moderne. En particulier il n’est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d’en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d’annoncer un gain moyen de 55%.

L’entreprise américaine continue donc d’impressionner par son innovation permanente, n’hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l’arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s’est concrétisée au fil du temps. Ainsi aujourd’hui, on ne compte plus qu’une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l’adoption était indispensable pour profiter des technologies d’entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu’elle a connue.

L’arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d’autres préfèreront se tourner vers l’offre Java for Business de Sun qui permet de continuer de bénéficier du support de l’éditeur.

Une autre possibilité pourrait se trouver dans l’arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d’un à deux mois, ce qui permettrait donc l’arrivée d’une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s’est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d’annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d’ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l’évènement SOA in Action, dix mythes communs (et la réponse qu’il faut leur apporter) sur la mise en place d’une SOA.
Là où l’article porte à sourire, c’est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

• Les services sont portés par l’IT et propagés vers les acteurs fonctionnels.
  Pour Yefim Natis, une SOA est un moyen pour l’IT de mieux comprendre et appréhender les problématiques métier.
• Les plate formes orientées services reposent sur des briques pré-fabriquées.
  Les SOA ne reposent pas uniquement sur des applications ‘services’, mais aussi sur des batchs et des applications héritées.
• Partager et réutiliser sont les principaux apports d’une SOA.
  C’est en effet un des bénéfices attendus, mais c’est loin d’être le seul. On peut citer : meilleure exploitation, meilleure montée en charge …
• Mettre en place une SOA permet de s’abstenir de réaliser une phase d’intégration.
  Même si la SOA permet d’introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d’intégration, bien au contraire.
• Une SOA réduit les coûts du SI.
  Sur le long terme, peut être … Mais dans un premier temps, une SOA peut s’avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir…

Pour les allergiques, la liste est la suivante :

• Une SOA introduit une grande complexité et de nouveaux problèmes.
  La plupart des problèmes liés à la mise en place d’une SOA sont des problèmes existants partout ailleurs dans le monde de l’informatique distribuée. La mise en œuvre d’une SOA ne fait souvent que mettre en exergue des problèmes existants.
• SOA n’est pas nouveau, c’est juste un effet de mode.
  Il faut voir au delà de l’aspect technique : certes SOA repose sur les principes de l’informatique distribué, mais c’est l’ensemble de la démarche qui est nouvelle et qui a au moins l’avantage de crystaliser certaines bonnes pratiques.
• Une SOA est vouée à l’échec, parce que les Web Services sont un standard trop instable.
  SOA et SOAP sont deux choses complètement différentes. Les Web Services sont ‘juste’ un moyen d’exposer des services.
• Il est difficile de vendre une SOA, car les acteurs fonctionnels n’en voient pas les bénéfices.
  Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
• SOA est déjà dépassé, il faut passer à la suite.
  Le challenge d’une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

Evènements de notre communauté en France et à l’étranger

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L’occasion de découvrir, démonstration à l’appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L’objectif est aussi de présenter l’architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l’organisation de la soirée dans les locaux d’EPITECH, vous devez vous inscrire ici.

Actualité éditeurs / SSII

• Google essuie les plâtres et met à jour l’Android NDK
• MIDP 3 et MSA 2 pour sauver J2ME ?

Agilité

• Départs de la Scrum Alliance : bruits de couloirs

RIA

• Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le coin de la technique

• Les roadmaps des implémentations de JPA 2.0
• Web Beans est mort ! Longue vie a Weld !

Actualité éditeurs / SSII

Google essuie les plâtres et met à jour l’Android NDK

Pour rappel, le NDK est un environnement de développement complémentaire au SDK qui permet d’utiliser des langages autres que Java pour développer sur Android. Ce NDK est principalement dédié au développement C et C++. Parmi les nouveautés de la version 1.6, vous trouverez :

• Les librairies OpenGL ES 1.1 qui rapprochent encore un peu Android de l’IphoneOS.
• Ciblage de version Android pour garantir le fonctionnement de votre application.
• Possibilité de mélanger les sources Java et le code natif dans un même projet.

Mais la semaine passée fût aussi l’occasion d’une joute entre Google et certains développeurs Android. Sujet de la discorde, le CyanogenMod une version libre, modifiée, d’Android. Google n’a pas apprécié le fait que son développeur ait la riche idée de distribuer avec son mod, les applications propriétaires qui lui sont chères. Citons par exemple : GMail, YouTube, Maps et Market. Nul besoin de dire que le système perd de son intérêt quand il est privé de ces outils estampillés Google…

Le spécialiste de la recherche a donc demandé l’interruption de toute distribution de ce mod, en attendant que le développeur trouve un moyen de livrer de l’Android sans aucune des G-Apps. C’est un baptême du feu pour ce système que Google a voulu ouvert. D’aucun disent que Google avait la possibilité de créer une alternative libre au jardin d’Eden d’Apple entouré de hauts remparts, à la place ce sera un autre jardin avec des murs un peu plus bas.

MIDP 3 et MSA 2 pour sauver J2ME ?

Mobile Information Device Profile (MIDP), associé à Connected Limited Device Configuration (CLDC) constitue l’API de base de J2ME, c’est cette architecture qui constitue le parc de 2 milliards de devices revendiqués par SUN.

La JSR-248 (Mobile Service Architecture), quant à elle, définit un ensemble d’APIs additionnelles pour les environnements MIDP J2ME apportant chacune un service particulier permettant souvent d’accéder à des fonctionnalités matérielles sous-jacentes (Bluetooth, GPS, Camera, …).

Ces deux piliers de J2ME sont en train d’évoluer avec la finalisation de MIDP 3 et MSA 2. Tandis que le premier apportera un rafraichissement de l’API de base de J2ME, le second poussera plus loin les possibilités d’intégration des applications mobiles J2ME.

Alors que les valeurs montantes du moment dans le monde du développement mobile sont clairement les plates-formes Android et iPhone, le rafraîchissement des APIs J2ME vieillissantes est le bienvenue et viendra épauler JavaFX Mobile dans son hypothétique ascension. On peut toutefois douter que cela suffira à inverser la tendance même si J2ME, fort de son parc colossal, n’est clairement pas menacé à court terme.

Agilité

Départs de la Scrum Alliance : bruits de couloirs

Vous le savez surement, la fin de l’été a marqué un tournant au sein de la Scrum Alliance.
Le 15 Septembre, dans un communiqué laconique (et très américain – nous remercions … blablabla pour son excellent travail … blabla), il nous était annoncé le départ de deux éminents membres de la Scrum Alliance, Ken Schwaber (son CEO) et Jim Cundiff (son Managing Director).
Après une enquête acharnée et au détour de quelques indiscrétions de sources (que nous ne citerons pas), il s’avère que Ken a eu un grave accident de vélo et que Jim a été démissionné compte tenu de ses manquements dans la refonte du processus de certification dont il était en charge.

RIA

Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le Denim Group regroupe dans 13 Things a Web Applications Attacker Won’t Tell You les principales failles de sécurité de nos applications web :

1. Transformer une requête GET en POST ne cachera pas les paramètres même s’ils n’apparaissent plus dans la barre d’adresse du navigateur (vérifiez avec Charles Proxy ou Fiddler si vous en doutez).
2. Utiliser un champ de formulaire hidden ne permet ni de cacher une information ni d’empêcher sa modification.
3. Idem pour les cookies (voir #1).
4. Contrôler les données coté client avec du javascript ne m’empêchera pas de modifier leur valeur.
5. J’aime vous entendre dire « Cela n’arrivera jamais en production ».
6. Et j’adore quand vous dites « Un pirate ne ferait jamais ça ».
7. Je déteste les validations strictes cote serveur.
8. Cette page d’erreur avec le message détaillé me facilite tellement la vie.
9. La plupart des bannières « Sécurité Garantie ! » ne me servent qu’a voir que vous n’avez pas compris les bases de la sécurité.
10. Ce scanneur d’application web que vous avez lancé, il n’a rien trouvé. Il n’a même pas effleuré les failles de votre application.
11. Ce scanneur réseau que vous avez lancé, il n’a même pas commencé a tester la sécurité de votre application.
12. Je connais AJAX (et toutes les nouvelles technologies a la mode) mieux que vous et mieux que vous ne pouvez imaginer.
13. Le plus astucieux vous vous croyiez, le mieux je me sens.

Moralité, soyons humble et rigoureux, nous ne pourrons pas dire que nous ne savions pas, ces conseils sont répétés par la plupart des tutoriaux de frameworks web .

Le coin de la technique

Les roadmaps des implémentations de JPA 2.0

Alors que la JSR-317 (Java Persistence API 2.0) vient de diffuser une Proposed Final Draft 2 et que sa finalisation approche, nous souhaitions faire un tour d’horizon des principales implémentations en préparation. Comme c’est souvent le cas avec les JSRs, les développeurs n’attendent pas la finalisation des spécifications pour commencer à les implémenter. Ainsi, on se souvient que JPA 1.0, intégré à la JSR-220 (Enterprise JavaBeans 3.0) avait fait l’objet d’implémentations alpha chez JBoss dès la diffusion des early drafts, ce qui avait permis la stabilisation du conteneur peu après la finalisation de la JSR.

• Hibernate : l’équipe de développement Hibernate a annoncé fin aout la disponibilité d’une version 3.5 beta 1 qui implémentait la majorité des nouveautés de JPA 2.0. Aucune indication n’était alors donnée sur la date de finalisation, mais le bon avancement permet de supposer qu’elle arrivera rapidement. A noter toutefois que certaines optimisations importantes telles que la compilation des requêtes criteria n’arriveront que dans une version ultérieure.
• EclipseLink : la fondation Eclipse avait annoncé fièrement en début d’année 2008 qu’EclipseLink serait l’implémentation JPA 2.0 de référence. Une roadmap mise à jour en avril dernier fait état d’une version 2.0 d’EclipseLink implémentant JPA 2.0 pour l’automne 2009.
• Apache OpenJPA : le projet OpenJPA maintient une roadmap très rigoureuse tablant sur un démarrage de phase release candidate pour la fin de l’année. Il s’agira de la version 2.0 d’OpenJPA, elle est actuellement développée sur le trunk du projet.

La première version de la spécification JPA a été un succès puisque de nombreux développeurs ont reconnu sa légitimité et l’ont adopté dans leurs projets plutôt que de se reposer sur l’API propre à leur framework de persistance. Toutefois, pour certaines fonctionnalités telles que les requêtes criteria ou des options de mapping évoluées, il était jusqu’alors nécessaire de contourner JPA. Dès lors, on imagine aisément que JPA 2.0, comblant les manques de son ainée, bénéficiera d’une large adoption. La disponibilité des moteurs JPA 2.0 qui seront utilisés par JBoss AS, Glassfish et WebSphere autour de la fin de l’année devrait par ailleurs accélérer l’omniprésence de cette nouvelle API.

Web Beans est mort ! Longue vie a Weld !

Apres les bruits de couloir de la Scrum Alliance, nous continuons la rubrique people avec une fois encore Web Beans. Après le changement de nom de la JSR 299 en Java Contexts and Dependency Injection, voici que la Reference Implementation se rebaptise Weld.
Pendant ce temps, la JSR 330: Dependency Injection for Java continue son chemin avec son implémentation partielle dans Spring Framework 3.0 RC1 et son intégration dans Google Guice.

• Plus de plate-formes : un prototype de téléviseurs montré à JavaOne, le support (partiel) de Linux et Solaris, et la promesse de voir les téléphones de LG, HTC et Sony arriver bientôt sur le marché public
• Plus de composant UI, tous skinnable à l’aide de CSS
• L’ajout de layouts
• De meilleures performances
• Un meilleur accès et un meilleur usage des données

Etrange top 5 à vrai dire, puisque quelques uns de ses points ne sont que partiellement implémentés.

Mais Sun met en avant son produit, et les démonstrations effectuées par D. Coward restent relativement impressionnantes (table de photos FlickR, arbre fractal en mouvement, et même PacMan !)

Plusieurs conférences permettaient de prolonger l’expérience avec le RIA de Sun. Ainsi, nous avons pu suivre une démonstration mêlant deux des stars de Jazoon, à savoir Glassfish et JavaFX. En effet, le back-end d’administration de Glassfish V3 est exposé en REST et pilotable par les quatre verbes. Il a alors été facile pour Ludovic Champenois de récupérer la configuration de son serveur local pour l’injecter dans les samples de JavaFX 1.2. Ce qui donne un « livre » qui dévoile au fil de ses pages des domaines, des serveurs et des datasources… L’expérience s’arrête là, et il n’est pas (encore) question de créer une console Glassfish en JavaFX.

Autre sujet abordé, celui du casual gaming. C’est ce segment de marché qui pourrait permettre aux mobiles FX, ainsi qu’au Java Store, de décoller. La présentation très succincte a tout de même donné un aperçu des facilités apportées par JavaFX pour le développement des jeux. Etant donné la fragmentation du marché mobile, cela donne un avantage non négligeable à JavaFX. Cette présentation nous a donné envie d’en voir plus, à travers ce blog.

Dernière conférence, deux développeurs discutent à la machine à café de qui est le meilleur entre Android et JavaFX Mobile. Ils se lancent un défi de développer la même application sur 2 terminaux mobiles. Cela vous rappelle quelque chose ? Et pourtant, il s’agit d’une conférence donnée par deux ingénieur de Canoo (les grands esprits se rencontrent dit on…).
L’application JavaFX a profité des fonctionnalités d’échange avec Photoshop pour avoir un design très léché. L’application Android a tiré le meilleur parti de l’application framework et des composants gaphiques « out-of-the-box » (qui n’ont pas d’équivalent chez Sun). Au final, on obtient un match nul en terme de résultat (pas vraiment en terme de courbe d’apprentissage, ni de temps de développement, clairement plus courts sur la plate-forme de Google).
Pour le dernier slide de la conférence, l’assistance a été mise à contribution. Elle devait voter pour l’un des choix suivant :

• 1. JavaFX Mobile va signer l’arrêt de mort d’Android
• 2. Android va signer l’arrêt de mort de JavaFX Mobile
• 3. Les deux technologies vont cohabiter pacifiquement
• 4. Sun (ou une autre firme) va proposer un portage JavaFX sur Android
• 5. Sun va poursuivre Google en justice pour non-respect du contrat de licence

La seconde proposition a remporté très largement l’adhésion de la salle, ce qui prouve que malgré le déploiement médiatique, et les nettes améliorations proposées de version en version, Java FX Mobile peine encore à convaincre.
Pour conclure, on pourra réfléchir à la remarque taquine d’un des membres de l’assistance : « il manque un numéro 6 dans les votes : Apple a déjà gagné la guerre »…

Dans le cadre de nos XKE (formations internes), beaucoup d’entre nous ont émis le souhait d’étendre leur champ de compétence au développement d’application sur téléphone mobile. Nous avions plusieurs technologies dans nos bagages : l’installé iPhone (à première vue pas vraiment compatible avec des développeurs Java), l’étoile montante Android, et l’outsider JavaFx.
Mais pour voir au-delà des promesses marketing, il nous fallait nous mesurer à ces technologies dans le cadre de leur utilisation réelle, sur un projet de la ‘vraie vie’. Ainsi est née l’idée de ce contest : 3 technologies, 3 développeurs Java (Amin Fathallah sur iPhone, Erwan Alliaume sur Android, Pablo Lopez sur JavaFx), et un mois (sur notre temps libre) pour traiter d’un sujet choisi par nos collègues : afficher sur le téléphone mobile l’ensemble des photos Flickr à proximité de l’utilisateur géolocalisées sur une carte. Chaque technologie a donné lieu à une démo en live et une analyse du ressenti lors du XKE suivant.

Résultats et commentaires

Commençons par un survol des démos : JavaFx très poussif, sur émulateur. Pas un franc succès. Android sur un G1 flambant neuf, très convaincant, notamment par les divers ajouts hors cahier des charges. Large vainqueur à l’applaudimètre, l’iPhone, avec une UI très soignée et des effets graphiques à la hauteur de la réputation du célèbre terminal.

Dans le même ordre, voici l’analyse de chacun des développeurs.

Java FX Mobile (SDK 1.1)

Mes premières heures de développement de l’application m’ont confirmé mes a priori : cela n’allait pas être facile. Il n’existe pas à ma connaissance de composant JavaFx permettant de simplement se géolocaliser sur une carte, qui plus est si la source cartographique est gratuite (type Google). On croise quelques API J2ME offrant ce service, mais rien de bien convaincant en open source.
Direction donc le capot et c’est parti pour une séance de ‘mains dans le cambouis’ : en utilisant l’API statique de Google et quelques astuces J2ME pour récupérer les coordonnées GPS, on peut s’en sortir.
Un petit tour ensuite sur les tutoriels officiels qui expliquent clairement comment récupérer des images flickR et les binder sur des composants JavaFx.
Et là commencent les ennuis réels, à savoir la gestion de l’affichage. J’ai eu la désagréable impression de revenir aux tous premiers temps de Swing : pas de layout (j’ai volontairement (faute de temps) laissé de côté les quelques frameworks open source proposant quelques composants graphiques de haut niveau) et donc tous les éléments doivent être ‘positionnés à la main’ (entraînant toutes les éventuelles problématiques de resize…). Un simple exemple pour illustrer mon propos : pour encadrer une miniature flickR, il faut récupérer les dimensions de la miniature et dessiner programmatiquement ‘sous’ celle-ci un rectangle de quelques pixels plus grand… Pas idéal.

Ajoutez à cela des plugins pour NetBeans et Eclipse défaillants (pas d’auto-complétion, mauvaise gestion des imports, marquage d’erreurs inexistantes, et pas de composition graphique…)

Peut être est ce la faute à une fonction de refactoring inexistante, mais mon code est rapidement devenu fouilli, et j’avais parfois du mal à m’y retrouver entre déclarations, binds et implémentations des fonctions.

Malgré tout, l’objectif est en partie atteint : l’application géolocalise l’utilisateur (en passant par la couche J2ME ‘pure’), affiche la carte et les miniatures, et permet de les zoomer / dézoomer, même si tout cela reste très artisanal.

Enfin, et à mon grand désespoir, contrairement à ce qui était sous-entendu dans nombre d’interviews des dirigeants de Sun à la sortie du Sdk 1.1, les terminaux mobiles du marché ne sont pas prêts à accueillir JavaFx. Il n’existe à ce jour aucun moyen de déployer des applications sur les téléphones du marché. Pour cela, il faudra attendre les terminaux ‘JavaFx ready’ que l’on nous promet pour JavaOne.
Faute de mieux, j’ai dû réaliser ma démo sur l’émulateur (qui soit dit en passant est bien réalisé et très agréable à utiliser), avec toutes les interrogations que cela comporte (pas de limitation mémoire par exemple…)

Pour conclure, on entrevoit nettement les possibilités offertes par le langage de Sun, mais de nombreux obstacles (pitié, un environnement de développement digne de ce nom) viennent rapidement ternir le tableau et laisse JavaFx sur le bord de la route, loin derrière ses concurrents directs sur mobile.

	Des possibilités intéressantes De nombreuses ressources (officielles ou non) Un émulateur fonctionnel
	Langage loin d’être production ready Pas d’API / de composants graphiques de haut niveau Un environnement de développement réduit au strict minimum

Android

Il n’aura fallu que 3h (si si) pour répondre au cahier des charges : afficher des photos FlickR géolocalisées sur une carte. Entre la MapView, directement disponible dans le SDK Android et le wrapper Java de l’api FlickR téléchargeable sur internet, très peu de code fut nécessaire pour développer les bases de cette application. Et c’est là toute la force d’Android !

D’autre part, contrairement à mes camarades, je n’ai pas eu à me préoccuper de toutes les connexions réseau. La carte se met à jour automatiquement et la communication vers le site de FlickR s’effectue par simple choix de protocole (REST ou SOAP).

Une fois ce POC terminé, seul un gros travail d’enrobage restait à effectuer :

• L’affichage des photos sur la map a nécessité la création d’un Overlay spécifique, la récupération des coordonnées GPS est passée par l’intermédiaire du LocationManager
• La création du menu est aussi simple que d’ajouter des éléments dans une liste
• L’édition des préférences s’effectue par simple description XML des écrans associés. Android se charge de sauvegarder celles-ci et de les rendre disponibles au reste de l’application
• Externalisation de la recherche et récupération des informations des photos FlickR dans un service exécuté en background de l’application. Ainsi, l’UI ne reste pas bloquée lors de la récupération des photos. La communication entre le service et le front s’effectue par l’intermédiaire de messages : les Intent
• Ajout de messages Toast, popup et notifications système en faisant vibrer le téléphone en rythme, juste histoire de jouer un peu avec le SDK
• Affichage d’une preview vidéo de l’appareil photo du G1 sur un canvas, il s’agit d’un point de départ à une fonctionnalité d’upload de photos FlickR

La communauté Android est assez active, il est aisé de trouver une solution à la plupart des questions et problèmes que vous pouvez rencontrer. De plus, la documentation officielle est plutôt bien fournie, même si elle souffre de quelques lacunes : certaines notions fondamentales comme les ‘Intent’ y sont par exemple mal expliquées.

Tout cela fait que les développeurs Java ne devraient avoir aucun mal à se lancer dans l’aventure. D’ailleurs suite à la première présentation Android effectuée lors du XKE de mars, quelques-uns d’entre nous se sont essayés à écrire leurs propres applications : programme TV, Tetris…

	Environnement et programmation full Java SDK puissant et relativement simple à utiliser Utilisation possible d’api java existantes Licence développeur donnant l’accès au market peu onéreuse (25 €)
	Technologie naissante Widgets et vues moins beaux que sur l’iPhone Premiers mobiles qualifiés par certains de ‘moches’

iPhone

Il m’a fallu attendre 2 semaines pour répondre au cahier des charges. L’api MapKit n’est pas accessible par les développeurs dans les versions 2.x.x du SDK d’iPhone. Heureusement, la nouvelle version 3.0 en beta est sortie avant la présentation des résultats. J’ai passé pas mal de temps pour comprendre l’utilisation des composants MkMapView et MkAnnotationView. Le résultat est impressionnant. Une carte très fluide annotée avec plus de 300 photos téléchargées en mode asynchrone.

D’autre part, à l’instar des concurrents, j’ai développé plus de fonctionnalités pour 50 heures de travail :

• Localisation des coordonnées GPS (longitude, latitude) de l’utilisateur.
• Téléchargement des photos en mode asynchrone.
• Cache des photos téléchargées.
• Affichage des photos en liste.
• Affichage des détails d’une photo (nom, auteur, commentaires).
• Affichage des photos en taille réelle.
• Affichage de toutes les photos au format tableau.
• Affichage de la position de l’utilisateur sur la carte.
• Annotation de la carte avec plus de 300 photos.

La récupération des photos et de leurs informations de FlickR s’effectue par le protocole REST en mode asynchrone.

Une fois le développement terminé, j’ai passé beaucoup de temps pour déployer l’application sur l’iPhone. Plusieurs étapes sont nécessaires pour créer un profil développeur et pour générer les certificats nécessaires pour le déploiement de l’application sur l’iPhone.

Les développeurs Java auront du mal à se lancer dans l’aventure. La prise en main de l’iPhone SDK nécessite beaucoup de temps. Il faut apprendre un nouveau langage (Objective-C) et de nouveaux outils pour se lancer dans le développement (Xcode, Interface builder, Instruments, Shark).

La richesse des frameworks dépasse de loin celles des concurrents. La maturité des frameworks Cocoa utilisés comme couche basse de l’iPhone OS donne aussi un grand avantage à l’iPhone SDK.

	Un téléphone sexy Multi-Touch Technologie mature Outils de développement complets et simples d’utilisation SDK puissant, complet et relativement simple à utiliser Beaucoup de composants graphiques de haut niveau
	L’iPhone SDK nécessite un MAC OS X 10.5.4+ Langage de programmation complexe Licence développeur payante (99$)

Conclusions

Bien qu’il soit difficile de tirer de grands enseignements généraux sur des technologies ayant un vécu et un parcours si différent on retiendra :

• l’iPhone est définitivement le grand gagnant de l’expérience utilisateur. Mais la prise en main du langage peut constituer un très grand frein à l’adoption de cette technologie par les développeurs Java.
• le Google Phone constitue la bonne surprise de ce contest. Le développement en full Java parle aux techniciens que nous sommes, et l’expérience utilisateur, même si elle n’est pas à la hauteur de celle que peut proposer l’iPhone, est très convaincante.
• l’hypothétique JavaFxPhone reste sur le bord de la route. Même si les possibilités entrevues sont prometteuses, le manque de maturité de l’ensemble le condamne à rester dans l’ombre de ses concurrents, dans l’attente d’une version plus aboutie et plus riche.

Dans cet article, je vais donc revenir sur les annonces et points marquants de ces deux jours de conférences.

D’autre part, les vidéos des keynotes sont disponibles, vous pouvez consulter celle du premier jour (html5, android, web components …) ou celle du second jour (google wave).

Google I/O 2009, voici ce que j’en ai retenu :

• Le futur du Web, avec les premières démonstrations émoustillantes HTML 5.
• Google Wave, le prochain outil de communication et collaboration made in Google.
• La réconciliation de Google avec GWT et la sortie de GWT Query.
• Le futur d’Android, avec l’annonce de la branche Android 2.0 : Donut.
• Java sur Google App Engine en GA.
• Google Web Elements, comment intégrer les services Google dans vos pages web.
• Les macros dans Google Document, avec Google Apps Script.
• Arrivée des extensions dans Chrome.

HTML 5, le premier whaou effect

C’est la première fois que HTML 5 me fait rêver. C’est en effet un sacré coup de pouce que Google à donné afin de faire taire les tergiversions. Google a pris position, et nous en a mis plein la vue ! C’est ainsi qu’a débuté le premier jour de conférence avec une vidéo d’introduction de 5 minutes présentant des applications écrites avec HTML 5. Application ai-je dit ? Eh bien oui, il semble bien loin le temps de la page web statique. Il semble bien loin le temps des hacks Javascript, arrêtons la bidouille et commençons le développement d’applications riches : c’est en tout cas ce que nous promet Google avec le HTML 5. Tout cela sans nécessiter le moindre plugin … pour peu que vous ayez un navigateur compatible.

Pour Google, le navigateur a encore de beaux jours devant lui. Installé sur prêt d’un demi-milliard d’ordinateurs, il reste le moyen le plus simple et répandu pour accéder à Internet. Google l’a bien compris et a participé à la course aux performances des moteurs JavaScript. En un an, les performances des moteurs JavaScript ont été multipliées par 5 ! Vous n’êtes pas fan de JavaScript, il faudra pourtant vous y faire. Comme nous vous pourrez le constater dans la suite de cet article, ce langage est l’un des points centraux de la stratégie Google.

Sans le savoir, vous possédez peut-être déjà l’un des navigateurs compatibles avec certaines fonctionnalités HTML 5, si tel est le cas vous pouvez lancer certaines des démonstrations présentées directement depuis celui-ci.

Les principales nouveautés apportées par HTML 5 sont :

• Les canvas, zone sur laquelle il est possible de dessiner et d’effectuer des transformations : agrandissement, rotations, translations sur différents types de figures.
• Des balises audio et video, qui permettent d’intégrer des médias dans le document sans nécessiter un plugin externe. Elles disposent de fonctionnalités similaires aux lecteurs Flash ou Silverlight vous permettant de contrôler le comportement de vos médias.
• Les sections permettent de diviser vos pages en parts sémantiques. Elles se différencient des balises div qui ont pour rôle principal la présentation. Une section est complétée par un header et un footer.
• Un nouvel attribut async pour les balises script, il permet d’exécuter un script indépendamment de l’affichage de la page. Ces scripts pourront s’activer à la demande selon la disponibilité de ressources.

HTML 5 vous propose donc de transformer vos pages web en application riche, ce nouveau balisage vous permet de tirer pleinement partie de contenu multimédia sans nécessiter de plugin extérieur.

Google Wave, la grosse annonce de la conférence

Sans conteste la grosse annonce de Google durant ces 2 jours, Google a annoncé la sortie prochaine de Google Wave. Il s’agit d’un nouvel outil Open Source de communication et de collaboration, initié à l’origine par les deux frères Rasmussen, déjà à l’origine de Google Maps. Leur point de départ, à quoi les emails ressembleraient s’ils avaient été inventés aujourd’hui ? Après nous avoir parlé d’HTML 5 et d’applications riches, Google dévoile comment ils comptent tirer parti de ces nouveautés. A la vue du résultat, difficile de croire que l’application fonctionne sur un simple navigateur. Je vous encourage vivement de regarder la démonstration, le moins que l’on puisse dire est qu’elle donne envie d’essayer le produit. Pour ma part, même si j’avoue bien volontiers avoir été moins époustouflé qu’à la sortie de Google Earth il y a quelques années, il faut bien admettre qu’une fois encore Google est moteur d’innovations. Tout comme la sortie de Gmail, fort est à parier qu’une multitude de concurrents essayeront en vain d’égaler cette nouveauté. Et si une page était en train de se tourner dans le développement d’applications Web ?

Là où les emails permettaient un échange point à point, Google Wave centralise et met à disposition le contenu. On n’envoie pas une Wave, on y participe. L’historique des modifications des conversations (texte, média, widget) est stocké sur un serveur. Ainsi, tout nouveau participant pourra rejouer intégralement celle-ci.

Google Wave est un mixte entre email, messagerie instantanée, réseaux sociaux, partages de documents. Il se base sur un protocole spécialement créé pour l’occasion. Celui-ci permet la transmission d’incréments de données et permet, entre autres, l’affichage caractère par caractère d’une conversation au fur et à mesure de la rédaction par son auteur.

Bien plus qu’une application, Google Wave est également contrôlable via une API spécifique. Vous pourrez donc y utiliser ces services à votre guise pour modeler vos propres solutions. Du coup, fort est à parier que Google Wave sera également disponible sous la forme de widget à utiliser sur vos blogs, sites web …

Pour plus d’information sur le sujet, vous pouvez consulter cette page sur laquelle l’auteur à centralisé les informations, définitions et fonctionnalités de Google Wave.

GWT, au cœur de la stratégie Google ?

L’autre grosse surprise avec l’arrivée de Google Wave, l’utilisation de GWT à grande échelle dans un produit Google !

Jusqu’ici, il était drôle de constater que si GWT avait bien été créé intégralement en interne chez Google, au final, aucun produit phare n’utilisait cette technologie. Et bien, ceci sera bientôt du passé ! Non seulement le client Wave a été écrit en GWT, mais Google continue à investir beaucoup sur cette technologie. Certes GWT à tout de même dû subir pour l’occasion quelques modifications, mais force est de constater que GWT semble plus que jamais au centre de la stratégie Google. GWT permettra également la création d’applications pour Android et iPhone. C’est comme si Google voulait nous faire oublier nos applications locales/desktop aux bénéfices d’applications légères/riches.

Google I/O, c’est également l’annonce de la sortie de Gwt Query : un clone de jQuery pour GWT. Cette nouvelle Api permet d’ajouter du comportement côté client sans rencontrer les lourdeurs des Widgets. À ce stage GWT Query reprend 98% des fonctionnalités de jQuery.

Android 2.0 Donut, recherches et filtres

A l’heure où les premiers téléphones Android arrivent tout juste en France, Google a annoncé la création de la branche 2.0, appelée Donut. Sortie prévue : fin 2009.

Comme le communiquent certains, 2009 sera probablement l’année d’Android. Si à ce jour seuls deux mobiles sous ce système sont timidement sortis en France, Google attend la sortie d’une vingtaine d’appareils (pour une dizaine de fabriquants) en 2009.

Google I/O a donc été l’occasion de faire un point sur la roadmap de cette nouvelle version, celle-ci est prévue pour fin 2009 :

• Recherche globale : un champ de recherche commun pour le web, la musique, les contacts… C’est en effet, l’un des défauts de la version actuelle, le market nous encourage à installer toujours plus d’applications, il s’avère pour le moment peu pratique de retrouver celle que l’on cherche. J’avais d’ailleurs l’idée de développer une application ‘launcher’, je vais donc pouvoir nettoyer ma todo-list. Cette recherche globale vous permet donc d’effectuer des recherches aussi bien en local sur votre téléphone qu’en connecté sur le web. Démonstration de la fonctionnalité après la 3e minute de cette vidéo.
• Contrôle par la voix : Android 1.5 (Cupcake) a introduit les embryons de Google Voice Search, vous permettant de lancer des recherches Google par la voix. Donut va davantage utiliser cette fonctionnalité qui vous permettra aussi bien d’appeler un contact que de contrôler vos applications à la voix. Ces fonctionnalités seront intégrées aux applications Google, mais pas seulement. Vous pourrez les utiliser dans vos applications via la nouvelle API. Révolutionnaire ? par forcément, j’ai utilisé cette fonctionnalité pour la première fois sur Pocket PC il y a 3 ans avec Microsoft Voice Command.
• Synthèse vocale : vous contrôlez votre téléphone par la voix, celui-ci sait également vous parler. Donut offrira également des fonctionnalités de text2speach multi-langues, la présentation à été portée par une application de traduction plutôt réussie.
• Contrôle par le geste : votre téléphone sera capable également de reconnaître via l’écran tactile des formes complexes. Cela vous permettra entre autres de filtrer une liste de contacts en dessinant la première lettre du nom recherché.

Pour clôturer ce sujet, notez l’ouverture d’un nouveau concours mondial de programmation sur Android : Android Developper Challenge 2 avec de belles récompenses à la clé.

Java sur Google App Engine, ouvert à tous

Bien qu’aucune annonce n’ait encore été faire sur le blog officiel, il semblerait que Google ait annoncé officiellement le support Java sur Google App Engine, ce qui veut dire : ouvert à tous. En effet, en avril dernier, Google avait déjà pré-ouvert sa plateforme aux langages Java et Groovy aux 10 000 premiers inscrits.

Google Web Elements, widgets pour vos sites internet

Google Web Elements vous permet d’utiliser les services Google sous la forme de widgets sur vos blogs ou sites web. Ces widgets nous permettront par exemple d’afficher facilement nos présentations PowerPoint sur le blog, les sites du type Slideshare doivent grincer des dents…

Le fonctionnement est très simple :

• Rendez-vous sur le site de Google Web Elements pour choisir votre type de Widget.
• Configurez-le en ligne via un simple formulaire permettant de générer le code HTML et JavaScript représentant le widget.
• Copier-collez le code sur votre site ou blog.

Huit applications sont disponibles pour le moment: Calendar, Presentation, Conversation, Custom Search, Maps, News, Spreadsheets et Youtube News.

Google Apps Script, scriptez vos Google Documents

Google IO c’est du grand spectacle, comme nous l’avons vu durant les keynotes, mais aussi des annonces plus terre-à-terre : Google Apps Script en est un bon exemple. Avec cette fonctionnalité, il vous sera donc possible prochainement d’ajouter des fonctionnalités de scripting dans vos documents. Le développement de ces ‘macros’ s’effectuera entièrement en JavaScript à partir d’un éditeur intégré aux différentes applications Google Document. Je vous invite à consulter une vidéo de démonstration durant laquelle le présentateur effectue une macro d’envoi d’email.

Chrome, arrivée des extensions

Comme certains le savent déjà, Chrome, le navigateur internet made in Google, proposera prochainement un système de gestion d’extensions. Il vous est d’ailleurs déjà possible de commencer à écrire vos propres extensions en utilisant le dernier build developper, je m’y suis d’ailleurs essayé comme vous avez pu le lire sur mon twitter. Si cela vous intéresse, jetez un coup d’œil au howto vous permettant de créer votre premier plugin en 30 secondes chrono.

Les extensions sont des archives ZIP contenant du HTML, des CSS et du JavaScript. Chaque partie d’UI d’une extension se présente sous la forme d’une simple page internet. Du coup, vous utilisez les mêmes outils, même debugger, mêmes librairies JavaScript et les mêmes techniques de programmation que pour créer vos pages web. Google a particulièrement bien travaillé son API pour la rendre aussi simple que possible.

Chrome dispose depuis sa première version d’une gestion des processus bien ficelée : chaque onglet dispose de son propre processus rendant de ce fait difficile de planter le navigateur à cause d’une des pages web. Les extensions fonctionneront sur un principe similaire et disposeront donc également de leur propre processus.

Les extensions seront distribuées sous la forme de fichier CRX composé de :

• Une signature, pour éviter les attaques du type Man In The Middle.
• Un manifeste, contenant les informations générales (nom, version …).
• Un fichier zip avec le contenu.

Tiens tiens, cela n’est pas sans nous rappeler le packaging des applications Android…

Actualité éditeurs / SSII

• Google App Engine pour Java et Groovy

SOA

• Le statut de JBI 2 en question

Mobilité

• Preview d’Android 1.5

Le coin de la technique

• Lucene continue d’innover
• ServiceMix 4 et son kernel OSGi

Évènements de notre communauté en France et à l’étranger

• Les Cast Codeurs, le podcast Java en Français

Actualité éditeurs / SSII

Google App Engine pour Java et Groovy

Google App Engine, solution de Cloud Computing proposée par Google supporte depuis la semaine dernière (en plus du langage Python disponible depuis un an) le langage Java. Cette solution permet dorénavant de déployer son application web à base de servlets (sous forme de war) sur un serveur virtuel hébergé sur l’infrastucture de production de Google (Google a donné la semaine dernière un compte Google App Engine Java aux 10 000 premiers inscrits).

Google met en avant les avantages suivants :

• La facilité d’utilisation via un SDK très documenté et des plugins Eclipse.
• La scalabilité gérée de manière transparente et automatique
• La fiabilité et la performance fournies par les infrastructures de Google
• Enfin, App Engine est gratuit si votre serveur n’excède les 500 Mo de stockage et 5 millions de page visualisées par mois

Google fait une entrée de manière fracassante dans le marché du cloud computing « Java » (Amazon EC2, etc.. ) et propose une offre séduisante où chacun peut créer, tester et déployer son application facilement. La création d’un projet App Engine sous Eclipse via le plugin est simple et le déploiement sur App Engine s’effectue en un seul clic.

Quelques liens utiles :

• vous pouvez trouver une description très complète de la solution (en Français) sur le blog de Frank Arnulfo
• David Gageot a mis en ligne une feuille Google Spreadsheet qui liste les librairies et frameworks Java supportés par Google App Engine
• Groovy est également supporté, retrouvez l’annonce sur le blog de Guillaume Laforge

SOA

Le statut de JBI 2 en question

La JSR-312 : Java Business Integration 2.0 (JBI) a été initiée début 2007 pour pallier les défauts de la première version de ce standard (JSR-208 : JBI). Cette dernière souffrait en effet de nombreuses critiques, portant principalement sur sa lourdeur excessive et son indépendance vis-à-vis des autres standards existants (SCA, EJB3, JAX-WS, …).

Le projet était alors ambitieux mais la perspective d’un tel standard ne manquait pas d’intérêt. Toutefois, deux ans après sa création, le statut de cette JSR, tel qu’affiché sur sa page du JCP, reste toujours inchangé et la JSR est maintenant classée « inactive ».
Ron Ten-Hove (co-spec lead de la JSR), vient toutefois d’apporter une information discrète quant à l’activité de l’Expert Group associé sur la mailing list du projet OpenESB. Il indique que le développement de la JSR n’est pas interrompu et que la classification d’inactivité est uniquement due à une nouvelle règle du JCP qui étiquette ainsi les JSRs dont le statut n’a pas évolué depuis 18 mois. Ceci ne refléterait donc pas le niveau d’activité au sein de l’Expert Group. Aucune date ni évolution de planning ne sont par contre indiquées.

Le standard JBI 1.0 est boudé par un grand nombre de produits commerciaux et Open Source qui préfèrent épouser la vague des « lightweight ESB » dont nous vous parlions déjà il y a un an. Toutefois l’arrivée tardive d’un standard faisant consensus n’est pas forcément un frein à son adoption comme l’a montré EJB 3 remplaçant avec succès ses très lourds prédécesseurs ; la voie reste donc ouverte pour JBI 2.0 et l’avenir nous dira si la tâche n’était pas trop lourde.

Mobilité

Preview d’Android 1.5

En attendant la sortie finale d’Android 1.5 (Cupcake) à la fin du mois, Android Developers Blog annonce la sortie d’une pré-version du SDK 1.5 pour les développeurs d’applications Android.
Parmi la liste complète des nouveautés d’Android 1.5, cette pré-version du SDK propose notamment:

• le clavier virtuel
• le développement de widgets pour l’écran d’accueil (à l’image de l’horloge ou du widget de recherche qui existent déjà dans Android)
• la fonctionnalité live folders
• la reconnaissance vocale

Ce nouveau SDK propose également une avancée intéressante : la possibilité de gérer plusieurs versions du SDK en parallèle, par exemple ici les versions 1.1 et 1.5. Les développeurs pourront donc tester leur application sur plusieurs environnements sans manipulations fastidieuses.
Afin de commencer à tester vos applications sur cette nouvelle version d’Android, vous pouvez télécharger ce SDK 1.5 en cliquant ici.

Le coin de la technique

Lucene continue d’innover

Le projet Apache Lucene reste une source d’innovation importante au fil des années. Il compte en effet huit sous-projets, chacun apportant son lot d’outils et d’APIs additionnelles permettant de mettre en œuvre un moteur de recherche toujours plus élaboré.Ces sous-projets vont parfois au-delà du simple environnement de Lucene, comme cela a été le cas avec Hadoop, qui gagne actuellement en popularité et dont le moteur MapReduce est réutilisé par de nombreux autres projets.

Dernière preuve en date de cette activité, le sous-projet Mahout, créé en Janvier 2009 et qui vient d’être annoncé en version 0.1, a pour but de fournir des implémentations d’algorithmes de machine learning, la plupart pouvant être distribués grâce à Hadoop. Ces algorithmes couvrent principalement :

• La classification et le clustering : permettent de catégoriser, tagger et séparer des données en groupes. Ainsi enrichies, ces données pourraient par exemple être plus facilement exploitables et accessibles par un moteur de recherche qui saurait exploiter ces informations lors de son processus d’indexation.
• Le collaborative filtering : permet de créer des systèmes d’associations d’objets par apprentissage, du type « les utilisateurs ayant acheté cet article ont également acheté … ». Cette fonctionnalité est offerte par le moteur Taste de Mahout.

Ces technologies sont actuellement plus proches du monde de la recherche que de celui de l’informatique de gestion en entreprise. Et c’est bien là que va résider tout le défit pour Mahout : parvenir à proposer une API simple et robuste pour offrir ces fonctionnalités à moindre coût aux applications d’entreprise. Actuellement peu courants, les cas d’utilisation pourraient se multiplier avec la mouvance globale vers les technologies Web 2.0 et autre concepts liés à l’intelligence collective.

ServiceMix 4 et son kernel OSGi

L’équipe de ServiceMix a profité de la conférence ApacheCon Europe 2009 pour annoncer la sortie de la version 4.0 finale de leur ESB.
Rod Biresch présentait en septembre dernier les principaux apports de cette nouvelle version, ce qui permettait alors de constater qu’il s’agissait avant tout d’une refonte de l’architecture du projet. Ainsi, alors que ServiceMix 3 gravitait principalement autour de son conteneur JBI, son successeur utilise désormais un kernel basé sur OSGi et secondé par un module Normalized Message Router (NMR). Il donne naissance à deux sous-projets distincts : ServiceMix Kernel et ServiceMix NMR.

Cette nouvelle architecture permet à ServiceMix de gagner en évolutivité et n’a qu’un impact limité pour les développeurs utilisant cet ESB. Ainsi, les composants développés pour ServiceMix 3.x restent compatibles avec cette nouvelle version, tel que l’on pouvait s’y attendre du fait de la conservation du standard JBI.

En outre, Guillaume Nodet (project lead de ServiceMix) nous apprend que le kernel de ServiceMix 4 attire d’autres projets de la fondation Apache (ActiveMQ, Directory et James) ce qui devrait conduire ServiceMix Kernel à devenir un sous-projet d’Apache Felix et à être, à priori, renommé pour l’occasion en Apache Karaf. OSGi continue ainsi de s’imposer massivement pour apporter la modularité dans les implémentations de conteneurs et middlewares Java, après avoir conquit le cœur de nombreux serveurs d’applications.

Évènements de notre communauté en France et à l’étranger

Les Cast Codeurs, le podcast Java en Français

A l’image du Java Posse anglo-saxon, Emmanuel Bernard (JBoss, Hibernate), Guillaume Laforge (SpringSource, Groovy), Antonio Goncalves (freelance, auteur, Paris JUG) et Vincent Massol (XWiki, Maven) lancent Les Cast Codeurs, podcast dédié aux nouvelles fraîches du monde Java, en Français !
Parmi les sujets discutés pendant cette première édition : Google App Engine, le rachat hypothétique de Sun par IBM ou Java EE 6 proposé en final draft.
On y entend beaucoup Emmanuel Bernard, beaucoup moins Vincent Massol, mais les propos et le format sont intéressants, longue vie aux Cast Codeurs !

En novembre 2007, Google, des opérateurs mobiles et des fabricants de terminaux annoncent la création de l’Open Handset Alliance(tm). Le but de l’OHA : créer une plateforme mobile ouverte, riche, moins chère, et qui donne une meilleure expérience mobile. Quelques jours après l’annonce, l’OHA met rapidement à disposition une première version « early look » du SDK Android.
Un peu moins d’un an après la création de l’OHA, en septembre 2008, le premier mobile tournant sous Android est mis en vente sur le marché américain : le HTC G1. Enfin un système d’exploitation et des terminaux capables de rivaliser avec l’iPhone d’Apple (septembre 2008, soit un an et trois mois après la sortie de l’iPhone…) !

Comme pour l’iPhone, qui est sorti en France en novembre 2007 cinq mois après sa sortie américaine, les premiers téléphones Android arrivent avec un peu de retard sur le territoire français ce mois-ci. Les plus impatients avaient déjà importé l’Android Dev Phone 1 (version développeur du HTC G1). La sortie du HTC G1 chez Orange il y a quelques jours et la sortie du HTC G2 chez SFR, fin avril, va donner aux développeurs Java hexagonaux l’occasion de développer des applications mobiles dans leur langage préféré.

La plateforme présente en effet plusieurs intérêts pour le développeur Java :

• les applications Android sont développées à 100% dans le langage Java. Si vous vous êtes frottés au SDK de l’iPhone et son langage ObjectiveC, et que Java est votre langage de prédilection, développer pour Android est un vrai bonheur
• à l’image de l’AppStore d’Apple et de ses success stories vendues 1$ pièce, Android dispose d’un équivalent, l’Android Market. Il permettra à la fois aux entreprises et aux développeurs de mettre leurs applications gratuites ou payantes à la disposition des possesseurs de téléphone Android

Cet article vous présente les premiers pas du développeur Java dans la plateforme :

• les téléphones à disposition pour tester ses applications,
• les guides de développement,
• exemples de code et livres à lire pour monter en compétence,
• et les différents sites spécialisés à suivre pour se tenir au courant de l’actualité Android.

Android en France

Les téléphones

Orange a annoncé début mars avoir vendu 810 000 iPhone depuis sa sortie en France en novembre 2007. 810 000 iPhone, ce sont plusieurs centaines de milliers d’acheteurs potentiels d’applications dédiées à l’iPhone sur l’AppStore, la plate-forme de téléchargement d’applications mise en place par Apple un an après la sortie de l’iPhone, avec le succès qu’on lui connaît : des milliers d’applications, à des prix souvent très bas, compensés pour les éditeurs par le volume d’applications vendues, sur un modèle de partage des revenus entre Apple et l’éditeur (30% pour Apple, 70% pour l’éditeur). 810 000 iPhone en France, le retard est considérable pour la plate-forme Android, qui dispose elle aussi d’un magasin d’applications en ligne, Android Market.

Le premier téléphone sous Android à sortir en France est le modèle de chez HTC qui est disponible depuis plusieurs mois aux États-Unis et au Royaume-Uni, le HTC Dream (ou G1). Le Dream est commercialisé par Orange, qui au passage a gagné la première bataille qui l’oppose à SFR, puisque SFR sortira son premier téléphone sous Android avec plusieurs semaines de retard : le HTC Magic (ou G2). Là où le Dream est un téléphone à clavier assez peu sexy, le Magic est plus proche de l’iPhone : sans clavier physique (c’est un désavantage pour certains), un grand écran, et des dimensions plus réduites que l’iPhone. Vous pouvez trouver un test très complet du HTC Magic sur le blog presse-citron.

Quelles sont les perspectives de vente pour ces deux terminaux ? Si l’on regarde de l’autre côté de la Manche, les volumes de vente du HTC Dream (G1) sont très proches de ceux de l’iPhone : pour 10 iPhone vendus, on vend 7 HTC G1 (source Nouvel Obs). Orange et SFR peuvent donc rapidement vendre plusieurs dizaines de milliers de terminaux Android d’ici quelques mois. Mais au-delà des « early adopters » qui vont se jeter sur les modèles de chez HTC, ce sont certainement la sortie de modèles sous Android des autres grandes marques qui devraient faire exploser le parc de terminaux sous Android en France. A priori, tout est réuni pour que les constructeurs se mettent à Android : Android est gratuit, et l’OS est équivalent ou supérieur sur certains points à l’iPhone OS propriété d’Apple. Si les constructeurs sont restés assez discrets lors du récent Mobile World Congress de Barcelone, ils sont plusieurs à avoir récemment annoncé des terminaux pour 2009 (LG, Samsung). Il va effectivement falloir patienter, certainement jusqu’au second semestre pour voir la sortie de ces mobiles, mais on peut espérer début 2010 avoir un parc de plusieurs centaines de milliers de téléphones en France sous Android, ayant tous accès à Android Market et aux applications que vous aurez développées !

Concours SFR

À l’image de l’Android Developer Challenge il y a un peu moins d’un an qui avait permis aux développeurs des cinquante meilleures applications de repartir avec un chèque de 25 000 $, SFR organise du 10 mars au 14 avril l’équivalent, le concours SFR Jeunes Talents Développeurs.
L’initiative permet de mettre en avant la plateforme, et les quatre lauréats (plus un prix du public) se partageront un chèque de 50 000€, qui devrait leur permettre de continuer le développement de leur application.

Android Market

Comme avec l’AppStore d’Apple, vous pouvez mettre les applications que vous allez développer à la disposition des possesseurs de téléphones Android sur Android Market. AppStore est un immense succès pour Apple, et pour les développeurs des applications les plus téléchargées et vendues, voici quelques chiffres issus de la récente keynote iPhone OS 3.0 :

• 800 000 SDK téléchargés
• 60% des développeurs ne connaissaient pas la plateforme de développement Apple
• plus de 25 000 applications sur l’AppStore
• plus de 800 millions d’applications téléchargées

L’Android Market est aujourd’hui bien loin de tous ces chiffres. Depuis seulement mi-février 2009, les développeurs américains et britanniques peuvent soumettre des applications payantes.
Si les débuts devraient être modestes pour les applications Android, les gains engendrés par la vente d’applications Android devraient s’approcher des chiffres de vente de l’AppStore en début d’année prochaine. Si Android obtient le succès qu’on lui souhaite, et que plusieurs grands constructeurs (faisant partie de l’Open Handset Alliance) sortent des téléphones Android, il sera aussi intéressant de développer des applications pour l’AppStore que pour Android Market.

La marche à suivre pour mettre son application sur Android Market est la suivante :

• inscription au programme de développement, l’inscription coûte 25$ (100$ chez Apple)
• mise en ligne de l’application, il n’y a pas de validation a priori des applications de la part de Google, on peut donc espérer que la mise en ligne soit bien plus rapide que sur l’AppStore (c’est un des reproches faits à Apple)
• comme sur l’AppStore, les gains des ventes sont partagés (30% pour Google, 70% pour le développeur)
• le développeur récupère ses gains via le « PayPal » de Google, Google Checkout (enfin une utilisation pour Google Checkout !)

Guide de développement, littérature, premiers développements

Android dispose d’un site dédié aux développeurs : http://developer.android.com. Commencez par télécharger le SDK ici : http://developer.android.com/sdk, vous pourrez également télécharger le plugin Eclipse en suivant les indications données dans le guide d’installation du SDK.

Le site développeur vous propose également :

• un guide de développement
• la JavaDoc des APIs Android
• le blog de développeurs d’Android
• les mailing lists Android, hébergées sur Google Groups

Le guide de développement est (évidemment) très bien écrit : vous y trouverez notamment une introduction à Android et le traditionnel Hello, World. La partie Framework Topics est complète et détaille les différents composants de la plateforme Android, mais est quelque peu indigeste. Si vous arrivez à manipuler les Intents à la seule lecture de la page qui les présente, félicitations ! Cette documentation manque d’exemples de code concrets. Le SDK et l’émulateur sont accompagnés d’applications exemples, mais cette fois-ci ce sont les commentaires associés à ces exemples qui manquent.

Quelques livres dédiés à Android sont déjà disponibles, nous vous recommandons fortement Professional Android Application Development, par Reto Meier, que nous avons lu, et qui vous permettra de monter en compétence sur la plateforme, grâce à de nombreux exemples de code concrets. Ce livre est un parfait complément au site développeur d’Android.

Enfin, un mot au sujet des listes de développement. Elles sont très actives, c’est un signe de bonne santé du projet et de la plateforme, mais elles le sont trop pour les suivre quotidiennement en s’y abonnant par email (plus d’une centaine de messages par jour). Vous pourrez en revanche facilement y trouver des informations par l’intermédiaire d’une recherche dans les groupes.
Si vous préférez le format « forum », le forum anddev.org est assez actif. Il n’y a pas encore de forum dédié à Android sur developpez.com (mais vous pouvez y trouver un tutoriel Hello, World très bien fait).

Les sites dédiés à Android à suivre

Enfin, voici une liste de sites qui vous permettront de suivre de près l’actualité de la communauté Android : sortie des nouveaux téléphones, de nouvelles applications dans Android Market, ou articles sur le développement d’applications Android.

Sites Français :

• Frandroid
• PointGPhone

Sites Anglais :

• le blog officiel de l’équipe de développement d’Android
• le très complet AndroidGuys
• PlanetAndroid, agrégateur de blogs Android
• le forum anddev

J’y parle régulièrement d’Android, vous pouvez me suivre sur Twitter en cliquant-ici :

Lors de notre dernier XKE (Xebia Knowledge Exchange), nous lancions, attention teasing, un concours de développement interne sur les nouvelles technologies mobiles, concours dans lequel Android a évidemment sa place. Avant de vous présenter les résultats de ce concours (que nous publierons prochainement), il nous semble intéressant de recueillir a priori votre opinion sur le sujet.

Nous lançons donc ce sondage : Développeurs, initiés, quelle technologie préférez-vous pour le développement sur mobile ?

N’hésitez pas à nous faire part des raisons de votre choix dans les commentaires.

D’autre part, comme cela n’a que très peu de risque de biaiser le sondage, profitons de cet article pour partager le contenu de la petite présentation Android effectuée en interne à Xebia lors de notre dernier XKE.

Télécharger en PDF