Développer des applications pour Android

Au travers d’une série de billet sur la mobilité, Clever Age aborde les différentes facettes du développement d’applications mobiles pour présenter les différentes pistes exploitables, et dans quel cas les suivre.
Deux grands choix s’opposent et ne répondent pas au même besoin : le développement d’applications mobiles Web, et le développement d’applications mobiles natives. Dans cet article, je vais vous présenter la plate-forme Android, et les pistes pour aborder le développement d’applications natives pour ce système.

Android, Google, et les autres…

Android n’est qu’un système d’exploitation mobile, il ne s’agit pas d’un matériel, ni même d’un ensemble d’applications. En cela, il est extrêmement proche de Windows Mobile ou même de Symbian dans son positionnement : le système d’un côté, les constructeurs de l’autre, et au milieu la place pour y mettre des lots d’applications (l’opérateur, le constructeur, un acteur tiers ?). Ça, c’est la version « standard » d’Android, celle réalisée par « l’Open Handset Alliance ». C’est ce qu’on appelle l’« Android Open Source Project » ou « AOSP », placé sous licence Apache 2.0.

Par-dessus ça, Google ajoute la petite touche supplémentaire qui fait qu’Android est plus intéressant que Windows Mobile 6 ou Symbian : les outils et services Google :). Ce sont les applications GMail, Maps, Latitude, Navigation, News, Chrome to Phone, Talk, etc. Mais surtout la plus importante : Market, qui permet d’accéder à tout un ensemble d’applications à la façon de l’AppStore d’Apple. Tout ça, ainsi que les outils de développement associés (le « Google APIs Add-on » permettant entre autres d’utiliser Google Maps dans nos applications), c’est l’Android qu’on connaît et qui jouit d’un grand succès populaire.
Ces outils, de leur côté, ne sont en grande majorité pas open-source.

Android se positionne donc comme un système d’exploitation multi plate-forme, en cela il vient directement affronter Windows Mobile et Symbian sur leur terrain. Il ajoute la dimension « Market » qui est plutôt le terrain de jeu de l’iPhone et de son « App-Store ». Le chaînon manquant ? Probablement, d’autant plus qu’il est arrivé à un moment clé sur le marché : très rapidement après l’iPhone qui a pavé la voie, et avant que les grands noms comme RIM, Symbian, et Microsoft (avec Windows Phone 7) ne sachent réagir pour reconquérir un public qui commençait à sérieusement se lasser.

La plate-forme Android

Pour Android, Google a développé une machine virtuelle Java (ce qui, au passage, lui vaut un procès d’Oracle) nommée « Dalvik ». Pas grand-chose à en dire dans le cadre de cet article, si ce n’est que le runtime n’étant pas exactement le même, des applications J2ME nécessiteront tout de même un peu de travail pour être portées sur Android.

L’image ci-dessus représente bien les couches disponibles dans l’écosystème d’une application Android. En gros on a accès à l’environnement du système (les couches bleues comme l’UI, les notifications, la couche téléphonie, etc.) et à certaines API utilitaires intégrées (les couches vertes, comme SQLite pour la gestion des données), ainsi qu’aux autres applications du système (via des systèmes de communication décrits plus loin). Le reste représente les couches plus basses, utilisées par le système, mais qu’on ne devrait jamais toucher directement avec son application si on veut garantir son fonctionnement sur toutes les cibles.

L’environnement de développement

Pour développer pour iPhone vous devrez utiliser XCode sous Mac OS X, et pour développer sous Windows Phone vous devrez utiliser Visual Studio sous Windows… Le SDK pour Android est quant à lui disponible pour tous les OS ((Linux, Windows, Mac)), et tous les IDE ((Il s’agit d’un ensemble d’outils intégrables dans votre environnement comme vous le souhaitez, mais il existe bien sûr des plugins plus intégrés pour les principaux IDE)). C’est aussi ça l’ouverture 😉

L’environnement de développement de choix pour Android sera Eclipse, pour lequel tous les outils sont disponibles immédiatement, développés et mis à jour par l’équipe d’Android, et bénéficient d’une excellente intégration à l’IDE. Néanmoins le SDK disponible n’est pas spécifiquement lié à Eclipse et il est possible d’utiliser n’importe quel environnement.

• Dans tous les cas, il faudra commencer par télécharger le SDK d’une vingtaine de Mo. Il contient tous les outils pour le développement (création des 9-patch, optimisation du package final, gestion des émulateurs, etc), et l’intégration dans votre IDE reposera sur sa présence.
• Avec Eclipse c’est via le plugin ADT. C’est a priori le plus complet (notamment avec la prévisualisation de layout).
• Pour IntelliJ IDEA il y a un plugin et un bon article sur le blog de JTeam.
• Pour Netbeans, il y a cette procédure bien décrite pour le plugin “nbandroid” (anciennement “undroid”).

Attention il existe également des IDE dédiés “clé en main”. Parmi eux Motorola Motodev Studio est très connu. Il faut être prudent avec cet outil qui cache également la génération de la clé privée, qu’il est toutefois impossible d’utiliser avec un autre outil ! Si vous choisissez un tel outil soyez très prudent lors de l’export de votre application (voir plus loin), vous pourriez vous retrouver condamnés à utiliser cet outil ad vitam aeternam.

Le bon vieux « Hello, World »

On vient d’installer Eclipse, le plugin ADT, on a téléchargé le SDK et on a indiqué le chemin vers ce SDK dans les préférences du plugin. OK. Maintenant : un projet !

D’abord un petit tour par le menu Window → Android SDK and AVD Manager, dans la partie Available Packages vous allez pouvoir télécharger un ou plusieurs émulateurs. Le mieux est de tous les prendre (afin de pouvoir tester son application sur toutes les versions d’Android), le plus rapide est de ne prendre que le dernier. Cette opération n’est pas spécifique à l’IDE choisi, et l’installation des différents packages du SDK sera toujours une étape obligée !

Clic droit → New → Android Project : Nous voilà partis 🙂

• Project Name = le nom du projet Eclipse, par exemple « Ze Toast Project »
• Application Name = le nom de l’application, celui qui apparaîtra par défaut sur le Market et sur le téléphone. Mettons le même nom.
• Package Name = le nom du package Java de votre application. Vos sources seront dans ce package, mais surtout le plus important : il s’agit d’un identifiant qui doit être unique ! Le mieux est donc d’y insérer votre identifiant, genre « monlogin.toastproject ».
• Create Activity = ADT peut vous générer votre activité principale. Laissons-le faire et appelons-la « MainActivity ».
• Il reste deux informations à fournir avant de valider, et cela mérite quelques explications

Choisir la version cible

Ces données sont issues du site d’Android pour les développeurs ((Ces données sont basées sur l’accès au Market, et n’incluent donc pas la plupart des tablettes)).

Le système Android fonctionne sur plusieurs plate-formes matérielles, produites par différents constructeurs. Google n’a pas la main sur tout ça, et ne peut que proposer les nouvelles versions aux constructeurs : libre à ces derniers de les diffuser aux utilisateurs ou non… Et encore, c’est quand il ne faut pas en plus inviter l’opérateur dans la danse… Ce qui fait qu’on observe au fil des versions une fragmentation de plus en plus importante. Aujourd’hui c’est (en gros) 40% de 2.1 Eclair, 33% de 2.2 Froyo et 15% de 1.6 Donut et 10% de 1.5 Cupcake.

Ces statistiques évoluent vite, et cela tient en général à la mise à jour d’un ou deux téléphones très populaires ((par exemple un bond a été observé dans l’adoption de Froyo lorsque le HTC Desire a reçu sa mise à jour, idem pour Eclair avec les mises à jour du Motorola Droid et du HTC Hero)). Le choix de la version cible sera donc un compromis entre les fonctionnalités requises ((Quelques grands exemples : dans la 1.6 Donut apparaissent l’inscription à la recherche globale, une utilisation plus fine de la caméra, et la gestion des différentes résolutions d’écran; dans la 2.1 Eclair on peut interagir avec les informations des contacts et la synchronisation; et dans la 2.2 Froyo apparait notamment le “Cloud to Device”)), la distribution de ces versions à l’instant T, mais également l’évolution de cette distribution. En surveillant simplement les parts de marché des téléphones les plus vendus, et leur planning de mise à jour, ça donne déjà un bon aperçu, les spécialistes se doivent d’avoir cette vision et devraient savoir vous renseigner sur une tendance. Par exemple, si aujourd’hui la compatibilité 1.5 devait complexifier le développement d’une application, on peut décemment l’abandonner. D’ici 2 à 3 mois il en sera de même pour la 1.6.

Des solutions simples, comme le <a href= »http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html »>pattern Factory</a> permettent de répondre techniquement au problème de fragmentation logicielle. Mais l’API n’a pas tant évolué que ça entre la 1.5 et la 2.2. Donc le choix commun, et le meilleur pour la visibilité de votre application, est d’utiliser le SDK 2.2 («  target = 8  ») [6. Cela permet de bénéficier des dernières avancées du SDK, comme certaines options de déploiement, ou également la gestion multi-résolution du SDK 1.6] et de spécifier ensuite une compatibilité à partir de la 1.5 («  minTarget = 3  ») ((Attention alors à ne pas utiliser de méthodes de l’API spécifiques à 1.6 ou plus, car le projet compilera, mais ne fonctionnera pas sur 1.5. Un gros défaut du SDK ici, qui ne vous signalera pas ces méthodes, en revanche la documentation online est très bien faite et permet de filtrer par version.)).

Revenons à notre projet :

• Build target = la version du SDK qu’on utilisera pour compiler l’application. Le mieux est de prendre la dernière, on cochera donc « Android 2.2 ». On aurait utilisé « Google APIs » (2.2) si on utilisait des APIs Google (tiens donc !) comme les MapView.
• Min SDK Version = la plus petite version du SDK compatible avec notre application. Ici on va indiquer que notre projet est compilé en 2.2, mais qu’au niveau du code source pas de souci, il tournera sur un système en 1.5. Ici c’est un « API level » qu’on indique((Les principales sont : 3 (Cupcake), 4 (Donut), 7 (Eclair), 8 (Froyo))), en l’occurrence « 3 ».
• Ça y est, on peut valider la création du projet !

Structure d’un projet Android

Un projet a une structure bien définie. Lorsque vous créerez dans Eclipse un nouveau projet de type “Android”, vous aurez à définir le nom de l’application, le nom du package Java principal, et cette structure sera alors initialisée directement.

Une application Android est composée des principaux éléments suivants :

• AndroidManifest.xml présente l’ensemble des caractéristiques et des acteurs de l’application :
  • Nom et version de l’application
  • Options de déploiement
  • Compatibilité (version ciblée d’Android, résolutions, fonctionnalités matérielles requises, etc.)
  • Permissions requises
  • Liste des activités, des fournisseurs de contenus, des widgets, etc.
  • En gros, tout ce qui doit être connu du système doit être spécifié dans le manifest, sinon c’est comme s’il n’existait pas
• Les ressources de l’application dans res : Chaque sous-dossier contient un type de ressource (layout, images, constantes, animations), et peut être nommé avec des « conditions » dont je parlerai un peu plus loin.
• Couplé aux ressources, le dossier gen va contenir le code généré par le SDK pour permettre d’accéder à vos ressources. Chaque ressource se voit attribuer un ID unique qui est déclaré dans une constante de la classe R de votre projet. Par exemple R.drawable.toto désignera l’image dans drawable/toto.png (ou drawable-hdpi/toto.png selon les conditions). Ceci implique de nommer vos layouts et vos images sans tiret ni espaces, sinon vous aurez tout simplement une erreur de compilation ! On peut donc considérer les fichiers dans res comme faisant partie intégrante du code source de l’application.
• Le code source dans src.
• Les librairies externes sont par convention dans lib.
• Le dossier assets contient des fichiers embarqués par l’application. Il s’agit de fichiers qui seront considérés comme tels et non comme des ressources système directement utilisables, c’est-à-dire qu’il faudra lire leur contenu pour les utiliser (fichiers textes, mp3, etc.).

Les ressources

Les ressources sont tous les fichiers présents dans les sous-dossiers du répertoire res. Ils peut s’agir d’images (formes déclarées en XML ou images PNG), des layouts (XML), d’animations (XML), des listes de valeurs (chaînes, nombres, tableaux… dans un fichier XML), ou encore du texte brut (dans le sous-dossier raw).

• Les images “par défaut” seront dans drawable, les images pour les hautes résolutions seront dans drawable-hdpi.
• La mise en page de l’UI sera dans layout/main.xml, et une version “paysage” du même layout pourra être déclarée dans layout-land/main.xml.
• Il peut être intéressant de ne pas avoir les mêmes libellés en fonction de la résolution d’écran, et ainsi avoir un fichier values/strings.xml et des versions “raccourcies” dans values-ldpi/strings.xml.
• On peut les combiner et imaginer avoir un layout pour les écrans haute résolution à stylet dans layout-hdpi-stylus/.
• La langue fait partie de ces conditions, et vous pourrez donc internationaliser votre application par le fait que les chaînes de values/strings.xml seront surchargées par values-fr/strings.xml, values-de/strings.xml, en fonction de la langue du système.

Les combinaisons sont très souples et permettent d’aller très loin dans la customisation. C’est cette fonctionnalité qui permettra aux développeurs de faire une application qui fonctionnera sur tous les types de “devices”.

La fragmentation matérielle, qui est souvent présentée comme un défaut mais qui est également une liberté fondamentale pour le consommateur, est ainsi très simple à gérer.

Les activités

Android est multi-taches, cela signifie grossièrement que plusieurs applications peuvent tourner en même temps, mais également qu’une même application peut faire tourner plusieurs processus. Ainsi, lorsque vous ouvrez une nouvelle « fenêtre » de votre application, l’ancienne n’est pas forcément détruite pour autant, et l’utilisateur – via le bouton « retour » – pourra y revenir. L’activité correspondant à cette fenêtre n’a pas forcément été arrêtée, par exemple un téléchargement a pu continuer et quand l’utilisateur reviendra sur cette fenêtre il verra que la barre de progression n’en est plus au stade où il l’a quittée. L’enchaînement des fenêtres se fait par empilement : on crée une nouvelle activité qui vient s’ajouter à la pile, et l’utilisateur peut dépiler via son bouton « retour ».

En gros, une activité correspond à un écran de votre application. Il s’agit d’une classe Java étendant la classe android.app.Activity

Voici le code de la première activité créée lorsque vous initialisez un nouveau projet Android dans Eclipse :

package naholyr.toastproject;
import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
        @Override
        public void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.main);
        }
}

Dans le Manifest, cette activité a été déclarée comme étant celle par défaut pour votre application, et c’est donc elle qui est démarrée quand on lance l’application.

Ici, l’activité ne fait rien de particulier : elle se contente de charger le layout « main » (a priori le fichier res/layout/main.xml) à l’écran.

Le diagramme ci-dessus illustre le cycle de vie d’une activité. La méthode onCreate() est appelée au démarrage de l’application, et à chaque fois qu’il faudra la réafficher si elle a été tuée par le système (en cas de besoin de ressources), sinon c’est onResume() qui sera appelée.

Ce cycle de vie est intéressant à connaître, car vous ne souhaiterez pas forcément faire les même actions au même moment. Les plus fréquemment utilisées sont onCreate(), onPause(), onResume(), onDestroy().

Interface utilisateur

Le layout est au format XML, et décrit les différents éléments de l’interface : certains éléments sont des « conteneurs » censés organiser d’autres vues, et d’autres sont de simples vues « finales ».

Parmi les vues principales on aura évidemment les TextView, les Button, ImageView, et autres ListView. Les conteneurs principaux seront les RelativeLayout et les HorizontalLayout.

Voici un exemple de layout, à taper dans res/layout/main.xml (onglet main.xml de l’éditeur après ouverture du fichier pour éditer directement son contenu) :

Et le résultat (la preview est directement visible dans l’onglet Layout de l’éditeur) : Sans aller très loin dans le détail, on peut déjà voir le fonctionnement d’un HorizontalLayout qui permet simplement d’empiler les vues les unes après les autres (contrairement à son nom, il peut empiler verticalement avec l’attribut “ direction ”). Mes deux éléments principaux se sont vus attribuer un id, ceci me permet d’y faire référence une fois que le layout a été chargé. Après l’appel à setContentView() dans mon activité, je pourrai simplement appeler findViewById(R.id.button) pour récupérer mon bouton, et lui affecter des comportements spécifiques. Un mot sur l’éditeur de layout : le plugin ADT d’Eclipse propose un éditeur de layout. Il est assez peu ergonomique, et je ne vous conseille pas vraiment de l’utiliser pour construire votre layout : ça vous aidera peut-être au début, mais rapidement ses limites apparaissent, et l’auto-complétion du XML est bien plus efficace pour configurer une vue. En revanche il permet d’avoir sous la main la liste des vues disponibles – ça aide quand on débute – et, en tant qu’outil de pré-visualisation, il est extrêmement pratique ! Note sur match_parent : avant l’API level 8 (2.2) on utilisait fill_parent. Cette valeur a été dépréciée au profit de match_parent, strictement équivalente. Vous observerez que l’on peut utiliser la nouvelle valeur de l’attribut et que malgré tout le code fonctionnera sur les versions antérieures à Froyo. Les ressources sont traitées à la compilation, et seul l’API level (il y a une option de filtrage dans la documentation en ligne, pour ne voir que les classes et méthodes compatibles avec l’API level ciblé) doit être pris en compte dans la rétro-compatibilité. Créer ses propres vues : Chaque vue est une classe étendant android.view.View, et le tag XML correspondant est simplement le nom de cette classe ! Il est donc extrêmement simple de créer des vues spécifiques en étendant d’autres vues existantes.

Les notifications

Android supporte deux types de notification :

• • Une notification dans la barre de statut. Ce type de notification peut par défaut contenir une icône, un titre, un horodatage, et une seconde ligne de texte, mais on peut également utiliser une vue personnalisée. Au clic sur cette ligne, une nouvelle activité (choisie lors de la création de la notification) est lancée.

• • Les notifications « Toast » qui sont des messages affichés en surimpression sur l’écran durant un court instant. Ils ne permettent aucune interaction.

Selon votre objectif, vous utiliserez l’une ou l’autre de ces notifications. Il est intéressant de noter que les notifications sont également utilisées pour signifier à l’utilisateur l’exécution d’un service ((Les services sont des tâches s’exécutant sans interaction utilisateur, en fond, et sont survolés en fin d’article)) en avant-plan (c’est-à-dire qui ne peut jamais être tué par le système lorsqu’il cherche à récupérer des ressources). Retournons à notre projet : on veut qu’au clic sur le bouton, une notification toast affiche « Toasted that : contenu du champ texte ».

• On va déjà déclarer le texte dans res/values/strings.xml, ajouter :

  Toasted that : %s

• Ensuite on va préciser la gestion de l’évènement clic sur le bouton dans notre MainActivity :

  ...
  setContentView(R.layout.main);
  findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
          public void onClick(View v) {
                  // À faire au clic sur le bouton
          }
  });

• Au clic, on veut récupérer le contenu du champ texte, formater la chaîne précédemment déclarée, et afficher la notification Toast :

  // Récupérer la chaîne déclarée dans strings.xml
  String notificationText = getString(R.string.toast_message);
  // Récupérer le contenu de mon champ texte
  TextView text = (TextView) findViewById(R.id.text);
  CharSequence fieldContent = text.getText();
  // Afficher le message Toast
  Context ctx = getApplicationContext();
  String message= String.format(notificationText, fieldContent);
  Toast toast = Toast.makeText(ctx, message, Toast.LENGTH_SHORT);
  toast.show();

Tester son application

Pour tester notre application, il va nous falloir des « Android Virtual Device » ou « AVD ». Ça vous dit quelque-chose ? Oui c’est le même que dans « Android SDK and AVD manager ». On peut donc créer des machines virtuelles directement depuis le menu de tout-à-l’heure.

Dans la partie « Virtual Devices » on a la liste des machines existantes (aucune a priori à ce stade), cliquez sur New pour en créer une. On va pouvoir spécifier pas mal d’informations intéressantes :

• Un nom, essayez de le garder explicite, par exemple « froyo-mdpi ».
• Le système émulé, ici on va spécifier « Android 2.2 – API level 8 ».
• La taille de la carte SD si on veut en simuler une.
• La résolution, on va ici choisir « Default (HVGA) » (ça correspond à du 320×480).

Créer l’AVD, et quitter le manager. Maintenant clic droit sur le projet → Run as → Android Application. Comme notre application cible Android 2.2, Eclipse va voir qu’on a une AVD pour cette version, et automatiquement l’utiliser. L’émulateur démarre, c’est un peu long la toute première fois. En théorie l’application va être automatiquement installée et lancée, en pratique lorsque l’émulateur n’était pas déjà démarré ça a tendance à ne pas aller au bout. Donc dès que le système a fini de démarrer on peut refaire un coup de « Run as Android Application » si on voit que ça ne démarre pas seul.

Tester son application sur différentes versions : Comme on va exporter notre application vers différentes versions d’Android, il convient de toutes les tester. On n’a pas toujours une flotte de téléphones, et la possibilité de créer autant d’AVD qu’on veut est une vraie bénédiction ! Toutes les versions du système, dans toutes les résolutions possibles, avec ou sans carte SD, avec ou sans géolocalisation, avec ou sans réseau : vous avez tout à disposition pour tester votre application dans les pires conditions !

Le minimum est de tester son application au moins sur le Build target (dans notre cas 2.2 Froyo) et le min SDK version (dans notre cas 1.5 Cupcake). Pour ce faire il faut aller dans le « Launcher? » généré par Eclipse et désactiver le choix automatique de l’AVD à utiliser ((Menu Run → Run Configurations, puis éditez le launcher Android Application/Ze Toast Project (le nom de votre application), dans l’onglet Target, cochez Manual au lieu de Automatic)). Vous aurez ainsi à chaque fois que vous exécuterez votre projet une fenêtre vous invitant à choisir l’AVD à utiliser.

Exporter son application

Votre application fonctionne et vous êtes prêt à la distribuer (sur l’Android Market ou tout autre biais de diffusion), il faut donc l’exporter?!

Cette opération est assez simple, mais nécessite au préalable la création d’une clé privée. Cette clé sera utilisée pour signer votre package. Il est très important de la sauvegarder !! Si cette clé est perdue, et que vous exportez à nouveau votre application mais avec un autre certificat, les utilisateurs ne pourront pas faire de mises à jour ! Ils devront désinstaller l’ancienne avant de ré-installer la nouvelle version.

Avec le plugin ADT, l’opération est assez simple :

1. Clic droit sur le projet, Export, choisissez le type Android/Export Android Application.
2. Confirmez le projet à exporter.
3. Là il faut signer. Si vous avez déjà votre « keystore », sélectionnez-le et indiquez le mot de passe pour l’ouvrir, sinon vous pouvez en créer un nouveau et lui attribuer un mot de passe.

   

4. Une fois le keystore créé ou ouvert, vous allez sélectionner la clé que vous souhaitez utiliser pour signer votre application ou – là encore – en créer une.
5. Choisissez l’endroit où mettre le fichier .apk.
6. Et voilà 🙂

Vous pouvez consulter la page de la documentation Signing your application qui aborde toute la génération du .apk et quelques optimisations.

Vous êtes prêts à la diffuser au grand public ? Choisissez un biais :

• L’Android Market
• Un ou plusieurs markets alternatifs : YAAM, SlideMe, Appoke…
• La diffusion directe, par votre site

Évidemment, le choix le plus naturel est le Market « officiel ». Créez un compte depuis la page développeur de l’Android Market, il vous en coûtera 25€ et vous êtes quite pour la vie (on est loin des pratiques des concurrents). Si vous décidez de faire une application au téléchargement payant, alors 30% de commission seront retenus (là par contre on est exactement dans les pratiques des concurrents). Une fois votre paiement validé, vous pouvez uploader vos applications !

Faites deux copies d’écran (quand l’émulateur est lancé, depuis la perspective « DDMS » vous avez un bouton dans la vue « Devices » qui sert à ça), envoyez l’APK, vos copies d’écran, des descriptions, et quelques informations comme la catégorie et les pays ciblés. Cliquez sur « Publish » (ou juste « Save » si vous voulez la publier plus tard). D’ici quelques minutes, votre application sera visible dans l’Android Market 🙂

Aller plus loin

• Les recommandations interface utilisateur

Le manque d’uniformité dans les applications Android est un fait. Les recommandations officielles sont insuffisantes, et l’interface de base est trop peu attrayante pour qu’elles soient strictement suivies. Il y a 6 mois sortait l’application « Twitter for Android » et avec elle un article indiquant qu’elle serait bientôt open-source et présentant de nouvelles recommandations pour les interfaces bien résumées ici, notamment avec les « Quick Action Window » (menu contextuel sous forme de popup avec des boutons d’actions), et l’« Action Bar » (barre horizontale en haut d’application présentant les actions globales courantes). Outre le fait que ces recommandations soient discutables (le menu contextuel est théoriquement un ContextMenu ouvert par un long-click, et le menu global devrait être l’OptionsMenu accessible par la touche « menu » du téléphone), Google ici ne fait pas son travail : il donne des recommandations, mais n’offre aucun outil aux développeurs pour qu’ils les suivent ! Heureusement des initiatives comme Greendroid, simple-quickactions, ou encore QuickActionWindow (réalisé par votre humble serviteur :)), permettent de simplifier l’intégration de ces éléments dans votre application.

• Les «  9-patch  »

Ce format d’image est un simple png auquel on a ajouté une bordure d’1 pixel dont les pixels noirs permettent de définir les zones fixes, répétables, et extensibles de manière à avoir en une seule image toutes les informations nécessaires pour styler une boite de dialogue, un bouton, etc. Vous pourrez lire ce très bon tutorial pour plus d’informations.

• La communication entre activités et entre applications

Ce concept est utile dès lors qu’on veut lancer une 2e activité dans son application, ou simplement lancer une autre application. En gros, chaque activité indique dans le Manifest ce qu’elle fait (par exemple « je suis capable d’ouvrir les fichier text/plain «), et pour effectuer une action on va demander au système de trouver toutes les activités capables de l’effectuer, et d’exécuter celle trouvée (ou celle choisie par l’utilisateur s’il y en a plusieurs). Cet excellent article d’introduction vous initiera au concept d’Intent.

• Le partage de données

La notion de fournisseur de contenu est assez simple à implémenter dans votre application : il suffit de déclarer l’information dans le Manifest et d’implémenter un ContentProvider. Les autres applications pourront alors faire des requêtes sur vos données. Toutes les données du système auxquelles vous pourriez accéder (contacts, SMS, favoris du navigateur, etc.) sont interrogeables via ces content providers.

• Les widgets

Une spécificité d’Android est la possibilité de placer des applications sur le bureau, sous forme de widgets. Rien de magique du point de vue du développeur : un widget n’est en gros qu’une activité d’un type particulier, avec un layout spécifique. N’hésitez pas à en développer pour vos applications, ils sont très appréciés 🙂 Néanmoins pour de l’accès direct à une liste d’items de votre application, vous pouvez vous orienter vers les Live Folders

Conclusion

Android est une plateforme jeune, et qui n’est pas dénuée de défauts. Le principal de ces défauts se situe au niveau des interfaces peu sexy par défaut, et mal homogénéisées. Il semble que Google ait décidé de lutter contre cet état de fait, et on attend beaucoup de Gingerbread à ce niveau.

Pour le reste, en revanche, il y a beaucoup d’excellentes idées, une documentation vraiment très complète, une communauté active, une liberté de diffusion, un grand choix de matériel dont on s’accommode finalement assez facilement dans les développements grâce à la gestion fine des ressources.

Globalement, il est simple et très agréable de développer pour Android, et de l’expérience que j’en ai, l’épouvantail de la fragmentation n’est franchement pas si effrayant.

Ressources utiles pour aller plus loin

• Un excellent forum : http://www.anddev.org
• Blog des développeurs d’Android : http://android-developers.blogspot.com, notamment le dernier article à cette date qui regorge de bons conseils, « Improving app quality ».
• Documentation : http://d.android.com
• L’auteur de l’article a également réalisé l’application « Horaires TER SNCF «, dont les sources sont disponibles et peuvent montrer l’utilisation des notifications, des content providers, l’intégration de la recherche, les taches d’arrière-plan, etc.