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.

É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 …

Sommaire

• HTML5 ?
• Nouveau modèle de contenu
• Nouveaux éléments de mise en page
• Eléments interactifs
• Les WebForms
  • Nouveaux input
  • Validation native
  • Auto-complétion
  • Répétitions
  • Etat des lieux
• Multimedia
  • Audio et Video
  • La guerre des Codecs
  • Le Canvas
• Conclusion

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s’agit d’une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L’idée d’une nouvelle version de HTML serait motivée par quelques constats simples :

• Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
• La structure des documents n’est pas intuitive et rend l’accessibilité difficile
• Les API JavaScript varient trop d’un navigateur à l’autre pour garantir la portabilité des documents
• Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l’émergence du web sémantique, la spécification propose :

• Un nouveau modèle de contenu des éléments
• Des éléments de mise en page
• De nouveaux éléments pour les formulaires
• Du contenu multimédia
• Plus d’interactivité
• Des APIs standards JavaScript

Bien que la spécification soit encore en cours d’écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

• La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
• Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
• Interactive définit les éléments qui fournissent une interaction avec l’utilisateur
• Embedded affiche des ressource externes dans le document
• Les Metadata représentent tout ce qui n’est pas affiché (style, script, …)
• Heading définit les en-têtes d’une section
• Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d’une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d’autre part ces catégories permettent aux navigateurs d’assimiler le contenu de la page, notamment pour les exports d’impression ou l’accessibilité.

Nouveaux éléments de mise en page

Jusqu’à maintenant, l’élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d’empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

• Ce n’est pas intuitif pour le développeur, vous en conviendrez.
• Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d’aide à la navigation.

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s’organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d’utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l’organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L’algorithme nécessaire est d’ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l’exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l’interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d’une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d’éléments permettant de lancer des commandes.

<menu type="toolbar">
 <li>
  <menu label="File">
   <button type="button" onclick="fnew()">New...</button>
   <button type="button" onclick="fopen()">Open...</button>
   <button type="button" onclick="fsave()">Save</button>
  </menu>
 </li>
 <li>
  <menu label="Edit">
   <button type="button" onclick="ecopy()">Copy</button>
   <button type="button" onclick="epaste()">Paste</button>
  </menu>
 </li>
</menu>

Pour les commandes, HTML5 propose directement un élément command qui permet d’associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d’ajouter l’attribut contextmenu="menu_id", sur l’élément qui doit utiliser le menu.

L’autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d’un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l’utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

<section class="progress window">
 <h1>Copying "Really Achieving Your Childhood Dreams"</h1>
 <details>
  <summary>Copying... <progress max="375505392" value="97543282"></progress> 25%</summary>
  <dl>
   <dt>Transfer rate:</dt> <dd>452KB/s</dd>
   <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
   <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
  </dl>
 </details>
</section>

Ici, le tag details est utilisé pour cacher les informations techniques d’une copie. Vous noterez au passage l’utilisation d’une balise progress, pour afficher une barre d’avancement.

Les WebForms

Nouveaux input

Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu’une API JavaScript de validation en plus d’une interactivité accrue. Parmi les nouveaux types d’input, il y a :

• Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n’aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
• La saisie de formats numériques via les number et les range qui pourront prendre la forme d’un slider vertical ou horizontal
• Différents types de chaînes formatées comme les url, les email et tel
• Le selecteur de couleur color
• Le champ de recherche search

Les anciens types sont maintenus. Ils bénéficient d’un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d’un seul coup, tout en précisant le type mime accepté. Il y a aussi l’attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n’est pas renseigné.

Validation native

Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l’utilisateur, et peuvent interdire la soumission du formulaire, s’il n’est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s’accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, …).

Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

• required pour un champ requis
• min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
• pattern fournit une expression régulière que la saisie doit respecter

Auto-complétion

Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l’aide d’éléments de type liste (li, option, …). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l’attribut list. Une fois l’association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l’intérieur de la liste peuvent-être décorés par CSS directement.

<input type="text" list="roles" autofocus />
<datalist id="roles">
   <li>Designer</li>
   <li>Integrateur</li>
   <li>Programmeur</li>
</datalist>

Répétitions

Une autre évolution sympathique est la création d’un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

<tr id="order" repeat="template" repeat-start="3">
   <td><input type="text" name="row[order].product" value=""></td>
   <td><input type="text" name="row[order].quantity" value="1"></td>
   <td><button type="remove">Remove This Row</button></td>
</tr>
<p><button type="add" template="order">Add Row</button><button type="submit">Submit</button></p>

C’est l’attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d’éléments précédemment soumis. Pour assurer l’ajout et la suppression de ligne, j’ai utilisé les boutons de type add et remove mais j’aurais aussi bien pu utiliser des méthodes JavaScript de l’élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l’ordre des répétitions permettant de monter et descendre les lignes répétées.

Etat des lieux

Voilà la promesse d’un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d’autres termes, il sera possible de placer nos input pour un formulaire à l’extérieur de ce dernier.

Comme vous l’avez remarqué, j’ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s’y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l’API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l’on sait, c’est que l’éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

Page de démonstration pour Chrome, Safari et Opera.

Multimedia

Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd’hui que Flash est utilisé principalement pour 3 choses dans les applications :

• Pouvoir écouter de la musique
• Pouvoir regarder des vidéos
• Faire des animations de folies

J’ai mis volontairement de côté Flex car il cible plutôt les applications d’entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler . Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

• audio permet de gérer la lecture de fichiers audio en streaming.
• video assure la lecture de vidéos en streaming toujours.
• canvas permet de dessiner et de faire des animations en JavaScript.

Audio et Video

Jusqu’à maintenant, les gros avantages de la technologie d’Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

• controls pour activer l’affichage de l’interface de contrôle du navigateur
• autobuffer pour activer le chargement automatique de la ressource en cache
• autoplay pour activer le lancement automatique de la lecture
• loop pour lire le ou les médias en boucle
• src pour fournir l’url du fichier média à lire

La balise source placée à l’intérieure d’une balise audio ou video permet aussi de définir l’url (@src), le type mime et le codec (@type) d’une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

<audio controls autobuffer autoplay loop>
  <source src="elvis.ogg" />
  <source src="elvis.mp3" />
</audio>
<video src="video.ogg" controls>
  <source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <!-- Un texte alternatif pour les anciens navigateurs -->
  Your browser does not support the <code>video</code> element.
</video>

Si le navigateurs n’arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l’élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

Si vous ne voulez pas utiliser l’interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l’API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

De plus l’interface HTMLMediaElement fournit quantité de propriétés allant du volume à l’état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d’une batterie d’événements qui permettent de suivre l’avancement du chargement, l’état du lecteur, et les action lancées par l’utilisateur.

Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

La guerre des Codecs

Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l’audio avec AAC, FLAC, Vorbis, … La spécification laisse le libre choix aux navigateurs et table sur la création d’extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd’hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d’H.264, à mon sens, tient au fait qu’il est parfaitement adapté à l’embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

Codecs supportés par navigateurs

Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s’intéresse au sujet pour l’avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l’embarqué, iPhone et iPod Touch en tête, qui, d’une part, supportent pleinement les balises audio, et video, et d’autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

Le Canvas

Passons maintenant au canvas. Inventé par Apple pour le Dashboard d’OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L’objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l’API permet de faire de la composition, des transformations, de manipuler des images et d’afficher du texte formaté. Avec un timeout ou un intervalle sur l’objet et un peu de JavaScript, il devient possible d’animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d’animation. Il existe déjà un tas de librairie JS construites autour de l’élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

<canvas id=firstCanvas">Browser does not support the canvas element.</canvas>
<script type="text/JavaScript">
var canvas=document.getElementById('myCanvas');
var ctx=canvas.getContext('2d');
ctx.fillStyle='#FF0006';
ctx.fillRect(0,0,80,120);
</script>

Les détracteurs déplorent l’utilisation d’une API procédurale, et l’absence d’éléments crées dans l’arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

Voilà pour les domaines d’application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d’habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

Conclusion

Nous voici à la fin de ce tour d’horizon des nouveautés d’HTML5, côté contenu du moins.
Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd’hui. Il faudra attendre la sortie d’IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu’il s’imposera sur le web. Il faudra aussi regarder de près l’évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

Il reste un problème d’outillage, car il n’existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l’export vers d’autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d’implémentation.

Le script JavaFX

Dans ce langage, tout est objet, donc pas de types primitifs. Le script permettant de définir les IHMs a une structure arborescente plus facile à manipuler.
Exemple de code :

import javafx.stage.Stage;
Stage {
  title: "Hello World !"
  width: 100
  height: 50
}

Voici quelques unes des fonctionnalités qui nous ont été présentées :

• Le Data Binding : il est possible de lier (binder) des données entre deux objets avec JavaFX. Ce binding va plus loin avec la possibilité de binder un bloc ;
• Transition c’est à dire le passage d’un état vers un autre ;
• Les effets : pour déplacer un objet avec Move par exemple ;
• Media player : JavaFx est capable de gérer les médias ;
• Des layouts verticaux et horizontaux ;
• Les composants sont skinables, c’est-à-dire qu’il est possible de mettre le style à part dans une CSS ;
• Access modifier différent de java : avec public-read pour lecture uniquement ou public-init si seule l’initialisation est autorisée.

Pour plus d’informations, voici la documentation de référence.

Des librairies supplémentaires sont également disponibles pour JavaFX :

• JFXtras : fournit des librairies de composants supplémentaires ;
• JFXtrasShapes : fournit des formes supplémentaires comme des flèches ou des étoiles ;
• MigLayout pour JavaFX.

Courbe d’apprentissage

Stephen Chin semble dire que la courbe d’apprentissage de JavaFX n’est pas très importante pour un développeur Java. En effet, il serait possible d’importer des classes Java dans une application JavaFX. Il y a peut être eu des évolutions entre temps mais cette courbe d’apprentissage ne fut pas aussi évidente lors du Mobile Contest.

Déployable sur un HTC Diamond !

Pour nous prouver qu’il est possible de déployer sur un téléphone portable, Stephen Chin a fait tourner une application sur son téléphone comme lors de JavaOne l’année dernière. Mais en dehors de ces téléphones spécialement configurés, il n’y aurait aucun mobile grand public qui en serait capable pour le moment.

Netbeans 6.8 et son JavaFX Builder

Un second speaker, Tor Nobye, est intervenu pour présenter la bêta de Netbeans 6.8 qui supporte (toujours) JavaFX. Une révolution pour les développeurs qui bénéficiaient jusqu’à présent de plugins très pauvres. Cette bêta fournit :

• le support du SDK 1.2.1 ;
• meilleure complétion du code ;
• un debugger amélioré ;
• des suggestions pour les erreurs et warning de compilation.

Conclusion

La présentation fut intéressante pour comprendre le fonctionnement du langage et voir de quoi JavaFX était capable. D’après la documentation, il existe des composants graphiques comme des boutons, champs texte … Il aurait été intéressant de voir des exemples de réalisation de formulaires qui se rapproche plus de ce que l’on développe tous les jours. Finalement, il ne semble pas y avoir une énorme révolution par rapport aux versions précédentes.

Interrogée sur l’avenir de JavaFX, l’équipe du projet a expliqué que la prochaine version apporterait un gain significatif de performance. L’équipe est consciente de la montée en puissance de la plate-forme d’Adobe et se dit pénalisée par le temps de démarrage important de la JVM, rendant les applications Web JavaFX forcément moins attrayantes. Dès lors on comprend l’enjeu stratégique de la modularisation que Jigsaw apportera et qui permettra de rééquilibrer la plate-forme de Sun face à Flex en terme de performance. Ils tablent également sur une convergence des environnements RIA en terme de fonctionnalités à l’avenir, ce qui permettrait à JavaFX de briller grâce à l’intégration native à Java dont il dispose.

Un autre sujet « mobile » était présenté aujourd’hui, à savoir la fragmentation du marché des mobiles. Cette fragmentation intervient à tous les niveaux : hardware, OS, environnement applicatif.

Le chaos est positif, car il amène l’innovation, mais il complique considérablement la tâche des développeurs. Pour réaliser une application fonctionnant sur toutes les plates-formes, plusieurs stratégies se présentent :

• Développer spécifiquement pour chaque appareil : la portabilité et l’expérience utilisateur sont maximales, mais le travail titanesque.
• Développer une application n’utilisant que le plus petit dénominateur commun entre les plates formes, ce qui revient à sacrifier l’expérience utilisateur.
• Utiliser un player, ce qui équivaut à la solution ci dessus (l’expérience utilisateur est limitée par les fonctionnalités du player, elles mêmes limitées par les adhérences entre les différents mobiles).
• Utiliser un framework de portage.

C’est cette dernière solution qui était présentée, par les créateurs du framework J2ME Polish. L’idée sous-jacente est d’écrire son programme en Java, et d’utiliser un framework pour le porter sur la majorité des mobiles. Le code est transcrit par le framework en J2ME en utilisant un repository d’appareils, qui spécifie les caractéristiques de chacun (taille de l’écran, interactions possibles avec l’appareil) …

Il est possible de migrer le code sous Android ou Blackberry (J2ME Polish utilise pour ces deux cibles une reconstruction des classes J2ME spécifique).

Il est même possible de transformer ce code source pour le déployer sur Windows mobile et sur iPhone : le code Java est représenté sous forme d’arbre et un ‘cross-compiler’ est utiliser pour transformer cet arbre en langage cible.

Même si l’exercice est intéressant, il est un peu surfait, notamment parce que l’expérience utilisateur offerte par l’iPhone surclasse tous ces concurrents et qu’il n’est donc raisonnable que de porter une logique business lourde (la conception des IHM étant trop différente selon les mobiles).

A noter que les créateurs du framework apprécient l’initiative JavaFX, mais ne se pencheront réellement dessus que si le marché des terminaux mobiles porte cette nouvelle technologie.

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…

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