Accueil > J'y étais ! > Compte rendu du Paris JUG – Soirée Google

Compte rendu du Paris JUG – Soirée Google

Ce mardi avait lieu le Paris JUG mensuel, cette fois-ci consacré aux technologies Google. J’arrive 10 minutes en avance, ce qui n’est pas suffisant pour m’éviter la place de cancre tout au fond de la salle, le Paris JUG est vraiment victime de son succès, et c’est tant mieux. Au programme : Android, Google App Engine et Google Wave.

Présentation d’Android

(Stéphane Lietaed + Gabriel Kastenbaum) @ OxianeLogo Android

L’engouement pour les smartphones débute en 2002 avec l’apparition du BlackBerry (le téléphone de chef, pour continuer à recevoir des mails pendant les réunions). Le téléphone élitiste par excellence.
Il faudra attendre 2007 et l’iPhone, le pari réussi d’Apple, pour voir le marché évoluer. Et un deuxième boom avec l’AppStore, qui vient de dépasser les 100000 applications disponibles.
Le téléphone portable est omniprésent (3x plus de téléphones que d’ordinateurs personnels dans le monde), cela représente donc un secteur d’avenir en termes de développement.

Android est une plateforme, initiée par Google. Le point clef est l’ouverture (vis-à-vis de l’iPhone certes, mais pensez également au paysage du développement d’applications ayant accès aux fonctionnalités avancées des téléphones avant celà !)

En france, Bouygues et SFR (les perdants côté iPhone) se rattrapent sur les téléphones Android et proposent très rapidement des terminaux. Aux US, le premier téléphone équipé d’Android 2.0 (Motorola Droid) est sorti récemment.

Cette version de l’OS apporte entre autres le support d’exchange, avec de manière sous-jacente la technologie ActiveSync qui permet les “push” (également adoptée par Google pour Google Calendar et la synchronisation des contacts).

Parlons un peu technique

Android est un OS fondé sur Linux (noyau 2.6) et équipé d’une VM java spécifique (Dalvik VM). Ceci permet d’écrire en java, mais d’exécuter du bytecode Dalvik (fichier .dex). Il ne s’agit donc pas à proprement parler d’une JVM mais tous les avantages liés à la technologie java sont là (outillage, librairies et large panel de connaissances en termes de développement). C’est ce qui en fait une plateforme idéale pour l’entreprise. A ce sujet, je vous recommande la lecture de la série d’articles présents sur ce blog : Android pour l’entreprise.
La machine virtuelle java est optimisée pour des processeurs lents et pour une taille de RAM dérisoire à côté de ce que l’on a l’habitude de manipuler sur des ordinateurs personnels ou des serveurs.

Contrairement à une JVM classique, Dalvik ne fonctionne pas avec une stack, mais directement avec des registres.

Disposer d’une plateforme liée à Java permet certes de s’appuyer sur tout un ensemble de librairies existantes, mais l’on est ici dans l’impossibilité de faire quoi que ce soit qui fasse de la manipulation de bytecode java au runtime (langages alternatifs tels groovy, etc) ou des fonctionnalités AOP.

En ce qui concerne l’outillage, celui-ci n’est pas forcément lié à Eclipse (outils en ligne de commande disponibles ?) mais Eclipse est l’environnement de référence. Le jeu de plugins incite aux mises à jour (et contient la documentation en local).

Nos deux intervenants nous font ensuite une démonstration rapide du SDK, où l’on peut voir l’émulateur hébergeant une application “hello world” tourner en quelques secondes.

A propos des éléments graphiques

Le framework permettant de créer des IHMs est un framework “maison” mais les concepts sont similaires à awt, swing, etc.

Le tooling permet de travailler soit en mode graphique (drag & drop de composants), soit en mode édition d’un fichier “layout xml” (inspiré du couple html + css) décrivant les composants sur l’écran. De plus, on peut mélanger à loisir l’approche déclarative via fichier xml et la manière programmatique.

On nous montre également la possibilité de débugger au sein d’Eclipse. A ce sujet, je m’étonne de voir des appels sous forme de stacks si la VM utilise des registres. A creuser, si quelqu’un connait la réponse à ce mystère, cela m’intéresse.
Au sein de la plateforme, l’outil LogCat permet de voir toutes les logs du système (et pas forcément uniquement celles de l’application).

C’est la fin de la démonstration et nous revenons à un contenu plus formel sous forme de slides :

Il existe 4 types de “composants” dans le système Android

  1. Les Activités, qui permettent d’afficher des choses,
  2. les Services (n’ont pas de représentation graphique, équivalents plus ou moins directs de “Threads” effectuant des traitements en tâche de fond),
  3. les Broadcast Receivers : permettent de recevoir des messages envoyés par le système (ex: notification de batterie faible, ou notification d’appel entrant),
  4. les Content Providers : accès aux données (mais qui peuvent être partagées, ex: accès aux contacts).

Toutes les applications* sont logées à la même enseigne. Corollaire : vous pouvez remplacer certains morceaux de l’OS.
(*) Il n’y a pas a proprement parler d’applications, les 4 types de composants ci dessus pouvant être une “application”.

Pour faire le lien entre ces concepts, il manque un mécanisme de communication par événements : ce sont les Intents.
Il ne s’agit pas juste d’invoquer une méthode sur une autre instance “d’Application”. Le mécanisme des Intents permet notamment de mettre en place la notion d’autorisation. Ceci permet donc un couplage lâche. Gabriel fait un parallèle avec l’association de fichiers au sein de Windows : un .doc peut s’ouvrir avec Word ou OpenOffice.

C’est déjà la fin, place aux questions

Comment le market gère la sécurité des applications publiées ?
R : L’application est chiffrée par un certificat identifiant la machine ayant créé l’application

Quels sont les composants graphiques disponibles dans le SDK ?
R : Le framework est assez riche, y compris possiblité de faire de la 3D

Comment Google entend-il prévenir la fragmentation du marché en termes de capacités des téléphones (notamment avec l’arrivée du HTC Hero ?)
R : Question plus ou moins éludée…

Peut-on repasser de .dex à “java” plus classique (bytecode ou source) ?
R : Possible, certains s’étant amusés à retro-engineerer le format (mais celui-ci n’est-il pas ouvert ?)

En conclusion, on avait affaire à une présentation très bien menée (même si l’un des deux intervenants ne semblait pas très à l’aise, ce que l’on peut comprendre vu la taille du public). Le défi de présenter la plateforme dans son ensemble à un public supposé novice est relevé.

Instant promo

Arnaud Héritier vient nous présenter le premier ouvrage sur Maven disponible en français (sortie le 20 novembre).

Ai-je besoin de préciser qu’il en est le co-auteur (avec Nicolas de Loof) :)

Google App Engine

Groovy and Gaelyk
Guillaume Laforge @ SpringSource/VMWare & (Marc Antoine Garrigue + Gaël Lazzari) @ Octo

Nos trois intervenants introduisent la présentation en nous rappelant les trois modèles disponibles dans le Cloud :

  • Saas : GMail, salesforce.com
  • PaaS : Google App Engine
  • IaaS : Amazon EC2

Au début de l’année, le service GAE s’est donc ouvert à Java (la plateforme était initialement réservée à un développement en python). On a ici affaire à une JVM sandboxée et un conteneur de servlet jetty. Puisqu’il s’agit d’une vraie VM java, il est possible de faire tourner d’autres langages compatibles avec la JVM (dont groovy qui nous intéressera ce soir).

Le principe est d’écrire votre application (web) et Google App Engine gère la scalabilité pour vous. Le service est gratuit en dessous de certains quotas (ressources CPU, bande passante, envoi de mails, etc)

Toutes les APIs java ne sont pas forcément disponibles, mais pour pallier cela, GAE offre des services de haut niveau :

  • Memcache (pour mettre en cache tout ce que vous voulez, utilisable à différents niveaux de votre architecture)
  • URL Fetch (pour récupérer le flux présent à une certaine URL)
  • Mail (pour l’envoi de … mails)
  • Images (resize, crop, etc) : permet la manipulation d’images côté serveur
  • XMPP : envoi et réception de messages sur le protocole utilisé par jabber entre autres
  • User : authentification via un google account
  • Cron + Task Queues : permet le traitement programmé de tâches

Pour autant, la plateforme connaît certaines “limitations” (ou du moins diffère en certains points d’un développement de webapps auquel on peut être habitué). Par exemple, on ne dispose pas d’une base de données relationnelle. De même, chaque requête doit répondre en moins de 30 secondes, sous peine de se faire couper la chique par la plateforme. On est également limité sur la taille et le nombre des fichiers que l’on peut déployer. Enfin, certaines actions sont interdites, par exemple :

  • écrire sur le filesytem,
  • créer des Threads,
  • utiliser les sockets natives,
  • AWT et Swing évidemment, la plateforme se destinant au traitement côté serveur, mais donc indisponibilité pour certaines classes de manipulation.

En terme d’administration, GAE donne accès à un joli dashboard pour le monitoring de l’application (et permet le suivi des fameux quotas).

La “BDD” s’appuie sur BigTable : imaginez une immence HashMap distribuée. Ce système supporte les transactions (avec subtilités) et le partitionnement, mais ne connaît pas la notion de schéma (ie une entité peut avoir des “colonnes” différentes de sa voisine).

On n’utilise pas le SQL pour la requêter : pas de jointures, pas de contraintes, pas de fonctions d’aggrégations. Au chapitre des limitations, on peut ajouter :

  • on ne peut ramener que 1000 enregistrements à la fois,
  • impossibilité de faire des filtres d’inégalité sur plusieurs critères (ie les inscrits au JUG avant telle date ET qui ont plus de 31 ans).

Passons au celtique

Les intervenants nous font à présent découvir Gaelyk : une fine surcouche à GAE pour l’interfacer avec Groovy (et notamment les Groovlets et templates).

Gaelyk donne accès aux classiques request, session, etc mais aussi aux services GAE (urlfetch, etc). Guillaume Laforge nous montre par exemple l’envoi de mails en version java et en version Gaelyk, et évidemment, la réduction de code est bluffante.

Gaelyk permet par exemple de manipuler les entités BigTable (qui sont vues comme des “maps” en java) comme des POGO (Plain Old Groovy Object) en groovy : notation pointée pour les propriétés et ajout de méthodes membres save(), delete(), etc.

S’ensuit une démonstration ayant pour but de montrer une application complète mettant en jeu le plus de services de Google App Engine possible. Pari réussi sous la forme d’un service totalement inutile (ou du moins à contre-sens de l’histoire) : une application qui récupère des feeds RSS et envoie des mails quand des mises à jour sont disponibles.

Cette démonstration est l’occasion d’aborder le casse-tête d’architecture qu’est le développement GAE pour de “vraies” applications : tout est initié par une requête http, mais une requête ne doit pas durer plus de 30s. Comment faire pour traiter mes 10000 flux ?

La démo s’achève et avec elle la présentation peu après. Au final, une très bonne présentation même si l’on peut craindre une certaine confusion entre Gaelyk et GAE pour les personnes qui ne connsaissaient pas du tout Google App Engine.

Je ne reste pas pour la présentation de Google Wave, ce qui est bien dommage puisque le contenu était très intéressant techniquement d’après les échos que j’ai eus par la suite. Qu’importe, les occasions ne manquerons pas de découvrir cette plateforme.

Share
  1. Pierre-Yves RICAU
    13/11/2009 à 16:45 | #1

    N’ayant pas eu l’occasion d’assister à ce JUG, ce compte rendu détaillé est une aubaine, merci :-) .

    Quelques précisions concernant Android :

    “En ce qui concerne l’outillage, celui-ci n’est pas forcément lié à Eclipse (outils en ligne de commande disponibles ?)”

    => Le plugin Eclipse s’appuie sur des outils disponibles en ligne de commande. Pour plus d’informations, vous pouvez consulter le lien suivant : http://developer.android.com/guide/developing/tools/index.html .

    “A ce sujet, je m’étonne de voir des appels sous forme de stacks si la VM utilise des registres.”

    => Je n’ai pas beaucoup plus de détails à apporter, on remarquera simplement que la méthode d’instance Thread.getStackTrace() s’appuie sur une méthode static native : dalvik.system.VMStack.getThreadStackTrace(this); . Il faudrait regarder le code natif pour en savoir plus ;-) .

    “Comment le market gère t’il la sécurité des applications publiées ?
    R : L’application est chiffrée par un certificat identifiant la machine ayant créé l’application”

    => Cela permet d’assurer qu’une mise à jour d’une application a bien été créée par le même développeur que la première version. Cela permet aussi de certifier que l’application a bien été créée par une personne donnée. Par contre, cela n’empêche nullement les copies pirates.

    “Comment Google entend-il prévenir la fragmentation du marché en termes de capacités des téléphones (notamment avec l’arrivée du HTC Hero ?)”

    En terme de fragmentation, il me semble que pour le moment ils se soient essentiellement concentrés sur les différentes tailles d’écran (les rapports).
    Il est ainsi possible de décider de rendre l’application limitée à certains types d’écran. Il me semble que les écrans très petits ne sont pas supportés par défaut par les applications, qui doivent le spécifier le cas échéant.

  2. Eric BOTTARD
    16/11/2009 à 15:58 | #2

    En y réfléchissant bien, je pense avoir la réponse à propos de cette vue sous forme de stacks dans le debugger. En fait, il faut distinguer deux choses :
    – le fait que l’on programme avec un langage “évolué” qui permet de modulariser les programmes avec des appels de “procédure” entraine que l’on peut voir l’enchainement A appelle B qui appelle C etc. Ceci implique qu’une représentation sous forme de pile d’appels est possible dans le débugger et est valable pour tout un tas de langages courants de nos jours, même pas forcément orientés objet
    – la façon qu’a de fonctionner la VM de manière interne : sous forme de stack pour la JVM (voir http://en.wikipedia.org/wiki/Java_bytecode) où les opérandes sont identifiés par leur position sur la pile, ou bien à base de registres directement.

    Le premier point est bien sûr possible quelle que soit l’implémentation sous jacente (2° point). Pas de mystère donc :)

  1. Pas encore de trackbacks