Les librairies pour le développement de jeux ou d’applications Android ne sont pas nombreuses mais surtout peu connues. On trouve néanmoins des moteurs 2D, des API de réalité augmentée, des API de lecture/génération de code-barres, d’autres plus généralistes…

En voici une liste qui ne demande qu’à être mise à jour. Elles sont triées en fonction de leur licence d’utilisation.

> Licence libre

• Box2D
  

  Moteur physique 2D complet et libre. Gestion de la physique des corps, détecteur de collisions… A L’origine écrit en C++ par Erin Catto, elle a été portée en Java mais aussi en Flash. Site : http://www.box2d.org/ Ressource : http://www.4feets.com/2009/03/2d-physics-on-android-using-box2d/

• Angle

  Moteur 2D OpenGL pour développer de jeux. Apporte également la gestion du son. Une série du tutoriels est fournie dans l’archive à télécharger. Site : http://code.google.com/p/angle/

• Rokon
  

  Moteur 2D relativement complet avec le support des capteurs. Un forum, des tutoriels et un outil de rapport de bugs sont présents. Site : http://rokonandroid.com/

• Zxing (Zebra Crossing)

  Lecteur de code-barres 1D et 2D (dont QR Code) via l’APN du téléphone. A l’origine développée en Java, la librairie (sous licence Apache) est également disponible pour Iphone et Blackberry. Site : http://code.google.com/p/zxing/ Ressources : http://www.insideandroid.fr/post/2009/04/23/ZXing-%3A-Comment-tester-le-scan-de-code-QR-sur-lemulateur http://www.insideandroid.fr/post/2009/04/16/Tutorial-%3A-Scanner-et-geacuteneacuterer-des-codes-QR-2D-sur-Android

• AndroidDataFramework
  Framework de gestion (création, accès…) de base de données SQLite à l’aide de fichiers XML.
  Site : http://code.google.com/p/androiddataframework/
  Ressource : http://www.brighthub.com/mobile/google-android/articles/52883.aspx

• DroidCouch
  Librairie d’accès à la base de données SQLite. Elle se veut minimaliste. Sous license MIT.
  Site : http://github.com/sig/DroidCouch

• Scala-android
  Pour développer en Scala sous Android. « Scala est un langage de programmation multi-paradigme conçu à l’EPFL pour exprimer les modèles de programmation courants dans une forme concise et élégante. » Wikipedia.
  Site : http://code.google.com/p/scala-android/
  Ressource : http://www.akshaydashrath.com/2009/10/scala-and-android.html

• aSmack (XMMP)
  Permet aux applications de se connecter facilement aux serveurs de messagerie instantanée Jabber/XMPP. C’est un portage non officiel sous Android de Smack API. Vous trouverez tout le support nécessaire sur le site officiel http://www.igniterealtime.org/projects/smack/ pour la version standard.
  Site : http://code.google.com/p/asmack/

• Calculaton
  Calculaton est un framework de tests d’Activity avec une syntaxe relativement naturelle pour ceux qui connaissent JUnit.
  Site : http://github.com/kaeppler/calculon/
  Ressource : http://brainflush.wordpress.com/2010/01/10/introducing-calculon-a-java-dsl-for-android-activity-testing/
• CW-Android
  Collection de codes (sous licence Apache) concernant la gestion des Activity, des fonts, de la base de données, des threads… tous issus du livre The Busy Coder’s Guide to Android Development! dont la traduction en Français s’appelle L’art du développement Android.
  Site : http://github.com/commonsguy/cw-android
  Livres :
  The Busy Coder’s Guide to Android Development!
  L’art du développement Android

• Droid-Fu
  Librairie généraliste, sous licence Apache, apportant un support pour la gestion du cycle de vie des applications, les tâches de fonds, les requêtes HTTP… et propose également des views prédéfinies.
  Site : http://github.com/kaeppler/droid-fu
  Ressources :

  http://brainflush.wordpress.com/2009/11/16/introducing-droid-fu-for-android-betteractivity-betterservice-and-betterasynctask/

  http://brainflush.wordpress.com/2009/11/23/droid-fu-part-2-webimageview-and-webgalleryadapter/

• OpenSocial Java Client Library
  Support d’OpenSocial dans vos applications. La documentation est complète et bien faite.
  Site : http://code.google.com/p/opensocial-java-client/

• RESTProvider
  Pour effectuer des requêtes HTTP. Gère les formats JSON et XML pour les réponses.
  Site : http://github.com/novoda/RESTProvider

• XMLRCP
  Pour réaliser des appels distants de méthodes via le protocole XML-RPC.
  Site : http://code.google.com/p/android-xmlrpc/

• GreenDroid
  

  GreenDroid est une libraire graphique française (par Cyril Mottier). Ses objectifs sont multiples : cohérence entre les applications, rapidité d’exécution, utilisation de concepts avancés, facilité d’utilisation, etc. C’est encore un travail en cours mais elle dispose déjà de fonctionnalités intéressantes comme les listes basées sur les items, la création de liste avancés par XML, etc. Site : http://github.com/cyrilmottier/GreenDroid Ressource : http://android.cyrilmottier.com/?p=240

• Facebook
  

  Le SDK Android de Facebook regroupe l’authentification des utilisateurs via OAuth 2.0, les appels aux APIs Facebook et Open Graph ainsi que l’intégration des applications Facebook. Site : http://github.com/facebook/facebook-android-sdk

> Licence développeur gratuites

• Photoshop Mobile Editor

  Librairie officielle Adobe permettant l’intégration de l’éditeur de photos dans vos applications Android, et cela gratuitement. Site : http://mobile.photoshop.com/android/developers.html

• Wikitude

  Une API de Réalité Augmentée complète et simple d’utilisation. Elle est également disponible sur IPhone. Pour enlever le bandeau « beta » de votre application, vous devrez simplement vous inscrire sur le site. La documentation est complète et un forum existe pour faire part de votre expérience. Site : http://www.wikitude.org/developers Ressource : http://android-france.fr/tag/api-wikitude/

> $ Licence développeur payante

• Android Barcode
  Génère tout type de code-barres qu’ils soient sous forme de lignes (1D) ou de matrices (2D). La documentation est relativement complète. Les versions IPhone et Windows mobiles existent également. Une version d’essai est disponible.
  Site : http://www.onbarcode.com/products/android_barcode/

• J4L Barcode
  Génère des code-barres 2D de type QRCode et Datamatrix (seulement :(). Une version d’essai est disponible.
  Site : http://www.java4less.com/barcodes/barcodes.php

• J4L RChart
  Génère toute sorte de graphiques tels que les camemberts, les histogrammes… Les deux aperçus d’écrans trouvés ne donnent pas très envie. Une version d’essai est disponible.
  Site : http://www.java4less.com/charts/chart.php?info=android
  Ressource : http://android-france.fr/2010/03/02/developpez-des-diagrammes-de-barres-statistiques-dans-vos-applications-android/

• Android Chart
  Génère toute sorte de graphiques tels que les camemberts, les histogrammes… Le « Developer Guide » n’est pas rédigé (statut: Coming soon) que ce soit pour la version IPhone ou Android. Çela manque cruellement de sérieux. Une version d’essai est disponible.
  Site : http://www.keepedge.com/products/android_charting/

• aiCharts
  

  Génère toute sorte de graphiques tels que les camemberts, les histogrammes, les pyramides… pour toutes sorte de données (financières, commerciales, techniques, mathématiques…). Le site rassure avec de très jolis aperçus d’écrans, une documentation complète et des exemples de cas d’utilisations. Une version d’essai est disponible. Site : http://www.artfulbits.com/Android/aiCharts.aspx

• PayPal Mobile Payment Libraries

  L’API PayPal permet d’intégrer le célèbre service de paiement sécurisé dans son application. Site : https://www.x.com/community/ppx/xspaces/mobile Ressource : https://www.x.com/community/ppx/xspaces/mobile/mep

Le Site Openintents.org en référence également quelques une.

Avant de choisir une librairie, il est important de vérifier qu’il existe bien une documentation ou un guide de démarrage. Cela facilitera la prise en main. Vérifier également que des mises à jour régulières sont effectuées. Si vous rencontrez des bugs, vous pouvez espérer qu’ils soient corrigés dans les prochaines versions. Un forum n’est pas inutile pour faire part de vos problèmes. S’il y en a pas, vous trouverez peut être des réponses sur le forum Android de développer.com. Dernière vérification, la présence de tutoriels sur le net indique si la librairie a déjà suscité un intérêt ou non.

Toutes les librairies payantes proposent une version d’essai. N’hésitez pas à l’utiliser pour vous assurer de la compatibilité avec votre version d’Android. A l’exception d’aiCharts, et d’Android Barrecord, aucune ne donne réellement envie d’y investir le moindre euros/dollar. Les sites sont soit old-school, soit la documentation est inexistante, soit les deux pour certains. Tout cela manque de sérieux.

Malheureusement, les développeurs Android sont beaucoup moins bien lotis. En début d’année Google publiait la répartition des versions de son OS. Prêt de la moitié des clients de l’Android Market tournent en version 1.6, 30% en 1.5 et seulement 20% en version 2.0. Mais ce n’est pas le seul problème. Le nombre de modèles de téléphones aux caractéristiques totalement différentes augmente de plus en plus. Si bien que cibler un modèle et une version de l’OS n’est pas une stratégie gagnante. Il suffit d’aller sur romandroid.ch pour s’en convaincre d’avantage. Quelque soit le pays d’Europe aucun téléphone ne domine le marché, les résolutions d’écrans sont très différentes ainsi que les versions d’Android. Quant à la mise à jour de l’OS, elle dépend du bon vouloir de l’opérateur ou du constructeur. Difficile dans ces conditions d’avoir un parc de téléphones unifié.

Après ce constat, qui pourrait en décourager plus d’un, on peut se demander ce que fait Google. Et bien rien, puisque son OS pour mobile a été conçu dans le but d’être installé sur le plus grand nombre d’appareils possible. Mais je vous rassure, il existe des solutions. Dans ce post, nous parcourons quelques-une d’entre elles :

• Gérer les versions d’Android
• Supporter les différents écrans
  • Android
  • Rester indépendant de la taille
  • Rester indépendant de la densité
  • Le répertoire de ressources res/
  • Le fichier AndroidManifest.xml
  • Images 9-Patch
• Détecter la présence des capteurs

Rendre son application la plus généraliste possible a un coût. A garder dans un coin de sa tête pour chiffrer un projet

> Gérer les versions d’Android

Si au début de l’année nous pouvions nous inquiéter de la disparité des versions de l’OS, les choses semblent évoluer (à la vitesse d’un escargot) dans le bon sens. La migration vers la 2.1 se généralise chez la plus part des opérateurs et constructeurs de téléphones comme en atteste Android-France et ce… pour la grande joie des développeurs.

Cependant, il reste naturel de vouloir imposer une version à l’utilisateur de la même façon que Google le fait avec Google Earth, Google Maps Navigation, Google Search Gesture et Android 2.0.1.

Dans le fichier AndroidManifest.xml, il suffit d’ajouter la balise <uses-sdk> (qui est automatiquement ajouté lors de la création d’un projet sous Eclipse) :

1 2 3

<uses-sdk android:minSdkVersion="integer"                 android:targetSdkVersion="integer"               android:maxSdkVersion="integer" />

Seul l’attribut android:minSdkVersion a une réelle importance. Il indique la version minimum du SDK nécessaire pour le fonctionnement de l’application. S’il n’est pas renseigné, Android considère que l’application est compatible avec toutes ses différentes versions. android:targetSdkVersion, couplé à android:minSdkVersion, indique que l’application a été testée sur une version précise mais reste compatible avec les versions précédentes jusqu’à minSdkVersion. L’unique but est d’indiquer au système qu’il n’est pas nécessaire d’assurer une compatibilité ascendante au runtime quand l’application s’exécute sur cette version. L’intérêt est peut être de libérer des ressources mais cela reste à vérifier. Quant à android:maxSdkVersion, l’attribut n’est pas recommandé et a perdu tout son sens depuis que la rétro compatibilité est assurée.

Ainsi pour imposer la version 2.1 :

1 2 3 4 5 6

<?xml version="1.0" encoding="utf-8"?>   <manifest xmlns:android="http://schemas.android.com/apk/res/android"     package="com.android23.app">     ...     <uses-sdk android:minSdkVersion="7" />   </manifest>

Les versions sont numérotés de cette façon :
7 -> Android 2.1
6 -> Android 2.0.1
5 -> Android 2.0
4 -> Android 1.6
3 -> Android 1.5
2 -> Android 1.1
1 -> Android 1.0

La compatibilité ascendante des versions du SDK est normalement assurée. Votre application développée en 2.0.1 fonctionnera sur un téléphone équipé d’Android 2.1. Mais Google conseille tout de même de vérifier les changelogs afin de s’assurer que les méthodes utilisées n’ont pas été supprimées d’une version à l’autre.
Concernant la compatibilité descendante, elle n’est évidement pas assurée. Google prend tout de même le soin de nous donner quelques pistes pour l’assurer manuellement: http://developer.android.com/resources/articles/backward-compatibility.html

Quant aux ressources (images, layout… du répertoire res/), elles peuvent être spécifiques à une version du système. Je pense par exemple aux icones du Launcher qui ont subit un petit ravalement 3D en passant à la version 2.0. Pour cela vous pouvez ajouter au répertoire drawable : -v<api-level> et spécifier la version cible. Exemple: drawable-v6/ désigne des ressources qui ne seront chargées uniquement sur Android 2.0.1.

Enfin, certains mobiles bien qu’en version 2.1 ne supporterons pas le flash 10.1 pour des problèmes de performance : http://android-france.fr/2010/02/26/adobe-flash/. Pensez y aussi si vous souhaitiez réaliser une application en Flash à destination des mobiles Android.

[ Mise à jour : 02/04/2010 ]
Une simplification de la gestion des versions d’Android est en marche http://www.journaldugeek.com/2010/04/02/vers-une-simplification-dandroid/

[ Mise à jour : 22/06/2010 ]
A la mi-Juin 2010, Google publie de nouvelles statistiques :

On apprend que la version 2.1 est installée sur plus de 50% des smart-phones se connectant à l’AndroidMarket. Les versions 1.5, et 1.6 sont installées de manière équitable : 24.6% pour la première et 25.0% pour la seconde. Il est donc encore trop tôt pour les oublier. Quant aux versions 1.1,2.00 et 2.01, elles ne méritent plus l’attention des développeurs.
Avec la mise à jour du HTC-Hero en 2.1 à la fin du mois, on peut s’attendre à un fort déclin de la version 1.5.
Le site Android France fait l’état des versions Android installées sur les téléphones disponible en France.

> Supporter les différents écrans

La documentation Google sur ce sujet est très complète, c’est pourquoi je vous invite vivement à la lire bien qu’elle soit en anglais.

Néanmoins j’ai décidé de partager avec vous quelques points qui me paraissent essentiels. Je conseillerai également de jeter un oeil à l’application démo MultiResolution qui illustre le support des différents écrans et le mode paysage.

>> Le support d’Android

Android répartit les différentes tailles et densités d’écran de la façon suivante :

L’écran et la densité par défaut est en jaune.

A titre indicatif, le Google Nexus One, HTC Desire, Sony Ericsson Xperia 10X et Motorola Droid (milestone) sont à ranger dans les écrans normaux à forte densité (normal-hdpi). Les HTC Magic, Dream, Hero, Legend, le Motorola Dext et le Samsung Galaxy sont à ranger dans les écrans normaux à densité moyenne (normal-mdpi). Enfin le HTC Tattoo, le prochain HTC Halo, et les dérivés « Mini » des constructeurs sont à ranger dans les petits écrans à faible densité (small-ldpi). Quant à la catégorie des écrans larges, elle concerne les tablettes PC.

Vous avez mal à la tête ? moi aussi… :'(

Vous devrez tester votre application au minimum sur 4 types d’écrans (encerclés en rouge) pour cibler le maximum de téléphones. En créant différents AVD vous pourrez vous rendre compte des modifications à apporter rapidement :

Pour gérer cette multitude d’écrans, Android se base sur la configuration de son fichier AndroidManifest.xml (<supports-screens>) mais également sur le nom des répertoires de ressources (répertoire res/). Il est possible de leur rajouter des qualificatifs :

• pour les différentes taille des écrans : -large, -normal, et -small
• pour les différentes densités : -hdpi, -mdpi, et -ldpi

Si l’application ne contient pas les ressources nécessaires pour les différentes résolutions et densités, le système adaptera les ressources présentes dans res/drawable/, res/layout… aux caractéristiques de l’écran. Le résultat peut être des images moins net, des boutons plus grands…

[ Mise à jour : 11/06/2010 ]
Google publie des statistiques concernant les écrans utilisés par les utilisateurs de l’Android Market. Nous remarquons que les écrans mdpi et hdpi sont les plus répandus :

>> Rester indépendant de la taille de l’écran

Le problème est un peu similaire aux applications de bureau dont l’interface doit s’adapter à la dimension de la fenêtre.

Lors de la construction des écrans, évitez l’emploi des AbsolutLayout qui impose de fixer les coordonnées X et Y de vos Button, TextView… qu’ils contiennent. Privilégiez plutôt les RelativeLayout qui permettent de placer vos éléments de façon relative au layout parent. Quand vous définissez les attributs layout_width and layout_height de vos Views, utilisez wrap_content, ou fill_parent.

Enfin pensez aux images 9-patch. Elle vous faciliterons également la vie lors du passage en mode paysage de votre application.

>> Rester indépendant de la densité de l’écran

La densité est basée naturellement sur la résolution de l’écran mais aussi sur sa taille physique. Un écran de type normal-ldpi contient moins de pixel sur 1cm² qu’un écran normal-hdpi. C’est pourquoi un bouton dont la taille est définie en pixels apparaitra plus grand sur un écran de faible densité que sur un écran normal par exemple.

Pour éviter ce genre de désagrément, privilégiez l’utilisation des dip ou dp au px lorsque vous spécifiez les tailles des boutons, des champs textes, des labels… Utilisez sp si vous spécifiez la taille du texte dans les EditText par exemple.

Les éléments garderont ainsi la même taille quelque soit l’écran.

>> Le répertoire de ressources

Lors de la création d’un projet sous Eclipse, plusieurs répertoires par défaut sont créés. Il est possible de leur rajouter des suffixes qui indiqueront à Android quelles ressources charger selon l’écran ou la densité :

• La taille
  • -small : ressources dédiées aux écrans QVGA à basse densité
  • -normal : ressources dédiés aux écrans par défaut, tel que le T-Mobile G1 – HTC Magic ou équivalent
  • -large : ressources dédiées aux écrans larges
• La densité
  • -ldpi : ressources pour les écrans à faible densité (de 100 à 140 dpi)
  • -mdpi : ressources pour les écrans de densité standart (de 140 à 180 dpi)
  • -hdpi : ressources pour les écrans à forte densité (de 190 à 250 dpi)
  • -nodpi : ressources indépendante de la densité de l’écran

Quelques exemples :
res/drawable/ images communes à tous les types d’écrans
res/drawable-hdpi/ images pour les écrans à forte densité
res/drawable-ldpi/ images pour les écrans à faible densité
res/drawable-mdpi/ images pour des écrans à densité normal
res/layout/my_layout.xml layout pour les écrans normaux
res/layout-land/my_layout.xml layout pour les écrans normaux en mode paysage
res/layout-small/my_layout.xml layout pour les petits écrans
res/layout-large/my_layout.xml layout pour les écrans larges
res/layout-large-land/my_layout.xml pour les écrans larges en mode paysage

Définir drawable/, drawable-hdpi/, drawable-ldpi/, drawable-mdpi/, layout/ et layout-land/ suffit amplement. D’ailleurs sous Eclipse, les répertoires drawable-hdpi/, drawable-ldpi/, drawable-mdpi/, layout/ sont par défaut créés à l’initialisation d’un nouveau projet.

Si Android ne trouve pas de ressources spécifiques à la configuration du matériel, il chargera les ressources présentes dans les répertoires sans suffixes tel res/drawable, res/layout…

>> Le fichier AndroidManifest.xml

Vous pouvez spécifier dans le fichier AndroidManifest.xml les écrans supportés avec la balise <supports-screens> :

1 2 3 4 5 6 7

<manifest xmlns:android="http://schemas.android.com/apk/res/android">   <supports-screens           android:largeScreens="true"           android:normalScreens="true"           android:smallScreens="true"           android:anyDensity="true" /> </manifest>

android:largeScreens, android:normalScreens, et android:smallScreens indiquent si les écrans sont supportés (true) ou non (false).

La valeur false n’empêche pas l’installation de l’application. Android simulera un écran de type normal-mdpi sur les téléphones non supportés. Sur des écrans larges, l’application sera entourée de noir, tant dis que sur des écrans petits, l’application sera coupée.

L’attribut android:anyDensity indique si Android met à l’échelle les valeurs en pixel ou non. Ainsi à true, l’OS laisse l’application s’assurer de sa compatibilité. Votre bouton apparaitra plus gros sur un écran large ou plus petit sur un écran small si vous lui avez spécifié des valeurs en px. A false, l’OS simule sur le téléphone un écran medium-mdpi et adapte les valeurs px.

Quelques soit la version de l’OS supportée, android:normalScreens est par défaut à true. Pour le reste, tout dépend de la version d’Android :

• Si l’application vise Android 1.5 et ses versions inférieures, tous les autres attributs sont à false.
• Si l’application vise Android 1.6 et ses versions supérieures, tous les autres attributs sont à true.

Puisque la version 2.1 se généralise, votre application est par défaut compatible avec tous les écrans. Il ne vous reste plus qu’à assurer la compatibilité des différentes densités en employant des dip et en proposant des ressources destinées aux écrans ldpi,mdpi et hdpi.

>> Images 9-Patch

Les images 9-Patch (NinePatchDrawable) sont des images au format PNG dont nous avons spécifié les zones étirables et les zones statiques. Elles doivent être enregistrées avec l’extension .9.png.

A l’aide de 2 traits noirs épais d’1 pixel, un en haut et un à gauche de l’image, nous définissons une grille de 9 cases :

Ces deux traits noirs seront seulement interprétés par l’OS et n’apparaitront pas à l’écran. Ainsi, seules les cases présentes dans les zones vertes et mauves seront redimensionnées tant dis que les autres resteront fixes si l’image est étirée en hauteur ou en largeur :

Il est possible de spécifier une zone de padding avec un trait sur le bord droit et un en bas de l’image. Cette zone est optionnelle mais permet de définir l’endroit où Android positionnera les éléments à l’intérieur de la vue.

Les 9-Patch trouvent toutes leur utilité dans la création de Button ou de TextView dont le fond s’adapte à la longueur du texte mais également lors du passage en mode paysage de votre application.

Pour finir, Google nous propose un outil pour éditer les zones étirables et de contenu: draw9patch.bat qui se trouve dans le répertoire tools/ du SDK. Pour ouvrir un fichier .png ou .9.png, il suffit d’aller dans File > Open 9-patch :

Sur la panneau de droite, vous verrez le comportement de votre image dans 3 situations :

• étirement horizontal
• étirement vertical
• étirement horizontal et vertical

En cochant la case Show patches, dans la barre d’outils du bas, vous verrez les zones étirables de votre image sur le panneau de gauche. En cochant la case Show content vous verrez en bleu , dans le panneau droit, le padding défini.

> Détecter la présence des capteurs

Tous les capteurs ne sont pas présents dans les téléphones. Ainsi le HTC Hero et le Tatto ne possèdent que l’accéléromètre et une boussole digitale alors que le Nexus One est complet. Avant de les utiliser il est préférable de les détecter :

1 2 3 4 5 6

SensorManager sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);   List<Sensor> sensorsList = sensorManager.getSensorList(Sensor.TYPE_ACCELEROMETER); if(sensorsList.size()>0) {   Log.d("SensorManager","L'accéléromètre est présent"); }

Vous pouvez remplacer Sensor.TYPE_ACCELEROMETER par :

• TYPE_ALL (pour tous les lister)
• TYPE_GYROSCOPE
• TYPE_LIGHT
• TYPE_MAGNETIC_FIELD
• TYPE_ORIENTATION
• TYPE_PRESSURE
• TYPE_PROXIMITY
• TYPE_TEMPERATURE

Ceux barrés n’apparaissent sur aucun téléphone.

> Conclusion

Il est nécessaire de garder cette problématique en tête au démarrage d’un projet. Les solutions sont simples et les tests rapides. Il serait dommage de se priver de nombreux utilisateurs ;).

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

> Ressources

• http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

• http://developer.android.com/resources/samples/MultiResolution/index.html

• http://developer.android.com/guide/appendix/api-levels.html

• http://www.brighthub.com/mobile/google-android/articles/61895.aspx

• http://www.higherpass.com/Android/Tutorials/Android-9-Patch-Scaled-Png-Image-Guide/

• http://www.developpez.net/forums/d834262/club-professionnels-informatique/actualites/fragmentation-dandroid-probleme-developpeurs-final-oui-repond-google/

> Content License
Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

• Installation du SDK
• Spécifier le proxy à l’émulateur
• Se connecter à un serveur distant via HttpURLConnection
• Se connecter à un serveur distant via DefaultHttpClient

> Installation de l’environnement : windows, Eclipse 3.5, ADT 0.9.7 et le SDK r6

[edit du 11/06/2010 ]
Si les précédents SDK pouvaient être installés directement sans nécessiter une connexion internet, Google a décidé depuis Décembre de changer sa façon de faire. L’archive du SDK ne contient que le répertoire sdk/tools.

La plateforme Android (1.5, 1.6, 2.1 et 2.2), la documentation, les drivers USB se téléchargent via l’installateur (sdk/SDK Setup.exe). C’est une vision plus modulaire et plus pratique pour eux.

Allez dans Settings et saisissez l’adresse et le port du proxy. Cochez éventuellement Force Https.

Mais si comme moi votre Proxy nécessite une identification, et bien l’erreur 407 sera la seule donnée que vous récupérerez.

Deux solutions existent:

• La plus simple est de télécharger les composants du SDK sur une machine ayant un accès direct à internet puis de les copier/coller sur votre machine de développement.
• La seconde consiste à installer SQUID (multi-plateforme), un proxy à installer en local sur votre machine qui s’occupera d’effectuer l’authentification auprès du proxy de votre entreprise. Malheureusement je n’ai pas essayé. Mais J.S décrit la marche à suivre sur son blog : http://sastriawan.blogspot.com/2009/10/workaround-on-installing-android-sdk-20.html et sur le forum http://androidforums.com/android-developers/21088-problem-sdk-installation.html un post détaille comment faire sous Windows

> Spécifier le proxy à l’émulateur

[edit du 11/06/2010 ]
-http-proxy est une option au lancement de l’émulateur. Je n’ai jamais réussi à faire fonctionner le navigateur internet et GoogleMap avec.

Du temps du SDK 1.6, il était possible d’utiliser le navigateur en définissant l’adresse du proxy et son port en éditant un APN : Home > Menu > Settings > Wireless Controls > Mobile networks > Access Point Names

Depuis le SKD d’Android 2.0.1, 2.1 et la récente 2.2, plus rien de marche :
http://code.google.com/p/android/issues/detail?id=5508

C’est tout même absurde qu’on ne puisse pas développer correctement derrière un proxy d’entreprise.

> Se connecter à un serveur distant via HttpURLConnection

Vous pouvez récupérer les préférences de l’utilisateur :

1 2	final String proxyHost = android.net.Proxy.getDefaultHost(); final int proxyPort = android.net.Proxy.getDefaultPort();

Puis…

1 2 3 4 5 6 7 8 9 10 11 12 13

String url = "http://www.google.com/ig/api?weather=Nantes.FRANCE", username = "username ", password = "password ";   Authenticator.setDefault(new SimpleAuthenticator(username,password)); URL server = new URL(url);   Properties systemProperties = System.getProperties(); systemProperties.setProperty("http.proxyHost",proxyHost ); systemProperties.setProperty("http.proxyPort",proxyPort );   HttpURLConnection connection = (HttpURLConnection)server.openConnection(); connection.connect(); InputStream xmlGoogleWeather = connection.getInputStream() ...

La classe SimpleAuthenticator :

1 2 3 4 5 6 7 8 9 10 11 12

public class SimpleAuthenticator extends Authenticator {   private String username, password;     public SimpleAuthenticator(String username, String password) {     this.username = username;     this.password = password;   }     protected PasswordAuthentication getPasswordAuthentication() {     return new PasswordAuthentication(username, password.toCharArray());   } }

> Se connecter à un serveur distant via DefaultHttpClient

1 2 3 4 5 6 7 8 9 10 11 12

final String proxyHost = android.net.Proxy.getDefaultHost(); final int proxyPort = android.net.Proxy.getDefaultPort();   DefaultHttpClient client = new DefaultHttpClient(); client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, new HttpHost(proxyHost , proxyPort ));   UsernamePasswordCredentials credentials = new UsernamePasswordCredentials("username:password"); client.getCredentialsProvider().setCredentials(new AuthScope(proxyHost ,proxyPort ),credentials);   HttpResponse response = client.execute(new HttpGet("http://...")); InputStream xmlGoogleWeather = response.getEntity().getContent(); ...

> Conclusion

On ne peut pas dire que Google nous facilite la tâche. Travailler derrière un proxy n’est pourtant pas si étonnant que cela en entreprise. Et cette histoire dure depuis les premières versions du SDK.

Je tiendrai à jour le post au fil de mes recherches…

> Ressources

• http://stackoverflow.com/questions/28380/proxy-with-android-emulator
• http://markmail.org/message/r2mpgv7dqaeti3zf
• http://www.coderanch.com/t/462906/Android/Mobile/connect-internet-behind-proxy
• http://groups.google.com/group/android-developers/browse_thread/thread/1105da659b20a176
• http://www.developer.com/java/other/article.php/1551421/Questions-on-HttpURLConnection-and-Proxies.htm
• http://www.rgagnon.com/javadetails/java-0085.html
• http://sastriawan.blogspot.com/2009/10/workaround-on-installing-android-sdk-20.html

Sensor Simulator simule 4 capteurs : l’accéléromètre, la boussole magnétique, les changements d’orientations et le thermomètre (qui ne nous intéresse pas). Sont absents le détecteur de proximité et de luminosité. L’outil se décompose en une application Java s’exécutant sur le poste de travail et d’une application Android tournant en tâche de fond qui simulera les stimulations des capteurs sur le téléphone.

Nous allons voir l’installation, la configuration et les quelques modifications à apporter à une application pour prendre en compte le simulateur.

Un bon dessin valant mieux qu’un long discours. Voici une illustration de son fonctionnement issue de la page du projet :

> Installation de SensorSimulator

>> Téléchargement

A l’heure où j’écris ces lignes, la version actuelle est la 1.0.0 beta1.
Lien pour le téléchargement : http://openintents.googlecode.com/files/sensorsimulator-1.0.0-beta1.zip.

L’archive est à décompresser dans le répertoire de votre choix.

Elle se présente ainsi :

• bin/ : l’application pour le poste de travail sensorsimulator.jar et celle pour Android SensorSimulatorSettings.apk
• lib/ : sensorsimulator-lib.jar, la librairie à rajouter à votre application le temps des tests
• release/ : fichier Ant pour reconstruire sensorsimulator.jar
• samples/ : l’application de démo
• SensorSimulator/ : les sources de l’application pour le poste de travail
• SensorSimlatorSetting/ : les sources de l’application Android

>> Installation sur le poste de travail

Aucune installation n’est nécessaire. Il suffit simplement de lancer le fichier jar sensorsimulator.jar du répertoire bin/ pour que l’application démarre et apparaisse à l’écran.

Une applet est également disponible à cette adresse : http://www.openintents.org/en/node/6

>> Installation sur le téléphone

Il est nécessaire d’installer SensorSimulatorSettings.apk sur l’émulateur. Deux manières s’offrent à nous :

• En ligne de commande, dans le répertoire bin/, une fois l’émulateur démarré :
  

  adb -install SensorSimulatorSettings.apk

• Sous Eclipse, en créant un projet Android, puis en sélectionnant les sources du répertoire SensorSimlatorSetting/. Vous devrez indiquer une version minimum du SDK et l’ajouter dans le fichier AndroidManifest.xml (<uses-sdk android:minSdkVersion="7">)

L’application SensorSimulatorSettings doit tourner en tâche de fond pendant les tests.

> Configuration

Il ne vous reste plus qu’à configurer les deux applications pour qu’elles communiquent entre elles.

• Sur votre poste de travail, lancer en premier SensorSimulator.jar. Le port sur lequel se fera la communication peut être changé. Vous pouvez laisser le numéro par défaut 8010 :

  

• Sous Android, lancez l’application SensorSimulatorSetting. Dans l’onglet Setting, saisissez le numéro de port et l’adresse IP 10.0.2.2 pour indiquer la boucle locale de votre poste de travail à l’émulateur (et non 0.0.0.0 qui fait référence à l’émulateur lui même) :

  

  Dans l’onglet Testing, cliquez sur « connect » puis cochez les 3 capteurs :

  

Si tout se passe bien, en bougeant le pavé rouge de SensorSimulator.jar sur votre poste de travail, les valeurs des capteurs devraient se mettre à jour sous Android.

> Modifications à apporter dans votre application

Les modifications à apporter aux applications ne sont pas nombreuses.

Avant tout, il est nécessaire d’ajouter sensorsimulator-lib.jar à son projet. La librairie se trouve dans le répertoire lib/ de l’archive téléchargée.

SensorEmulator n’ayant pas été porté sous Android 2.1, l’Activity doit implémenter l’interface dépréciée SensorListener au lieu de SensorEventListener.

La méthode onSensorChanged(int , float[] ) doit alors être définie :

1 2 3 4 5 6 7 8 9 10 11 12 13

public void onSensorChanged(int sensor, float[] values) {     switch(sensor) {     case SensorManager.SENSOR_ACCELEROMETER:         Log.i("onSensorChanged","Accelerometer: " + values[0] + ", " + values[1] + ", " + values[2]);     break;     case SensorManager.SENSOR_MAGNETIC_FIELD:         Log.i("onSensorChanged","Compass: " + values[0] + ", " + values[1] + ", " + values[2]);     break;     case SensorManager.SENSOR_ORIENTATION:         Log.i("onSensorChanged","Orientation: " + values[0] + ", " + values[1] + ", " + values[2]);     break;     } }

Nous déclarons un SensorManagerSimulator dans l’activity :

private SensorManagerSimulator sensorManager = null;

… que nous initialisons dans la méthode onCreate() :

1 2	sensorManager = SensorManagerSimulator.getSystemService(this, SENSOR_SERVICE); sensorManager.connectSimulator();

Pour terminer, il reste à définir la liste des capteurs en écoute dans la méthode onResume(), de la même manière qu’avec le SensorManager du SDK :

1 2 3 4 5 6 7 8 9 10 11 12 13 14

@Override protected void onResume() {     super.onResume();     sensorManager.registerListener(this, SensorManager.SENSOR_ACCELEROMETER |         SensorManager.SENSOR_MAGNETIC_FIELD |         SensorManager.SENSOR_ORIENTATION,         SensorManager.SENSOR_DELAY_FASTEST); }   @Override protected void onStop() {      sensorManager.unregisterListener(this);      super.onStop(); }

The end

> Ressources

• http://www.frandroid.com/254/openintents-des-standards-pour-les-intents-dandroid
• http://www.openintents.org/en/
• http://code.google.com/p/openintents/
• http://code.google.com/p/openintents/wiki/SensorSimulator

Dans ce long article nous aborderons :

• Les services (threads, cycle de vie…)
• Services Locaux (LocalService)
  • Déclaration du service
  • Implémentation des listeners
  • Implémentation d’un binder
• Services Distants (RemoteService)
  • Déclaration du service
  • Mise en place des Callbacks
  • Démarrer le service au boot du téléphone
  • Exemple : Connexion au service MP3

> Les services (threads, cycle de vie…)

Les services ont pour but de réaliser des tâches de fond sans aucune interaction avec l’utilisateur pour une durée indéfinie. Il existe deux type de services :

• les services locaux (ou LocalService) qui s’exécutent dans le même processus que votre application
• Les services distants (ou RemoteService) qui s’exécutent dans un processus différent de celui de application

Les services s’exécutent dans le Thread principal du processus parent. Ils doivent être déclarés dans le fichier AndroidManifest.xml: <service android:name=".subpackagename.ServiceName"/>

Ils doivent étendre la classe Service dont vous devrez surcharger les méthodes suivantes en fonction de vos besoins :

1 2 3 4 5 6 7 8 9

void onCreate(); // initialisation des ressources void onStart(Intent intent); // SDK<2.0 la tâche de fond démarre void onStartCommand(Intent intent, int flags, int startId); // SDK>2.0 la tâche de fond démarre void onDestroy(); // libération des ressources     IBinder onBind(Intent intent); // connexion client distant boolean onUnbind(Intent intent); // déconnexion d'un client void onRebind(Intent intent)

Google a publié un post sur la méthode onStartCommand() apparue avec le SDK 2.0 :

http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html

La méthode onStart() est dépréciée mais doit être redéfinie pour une compatibilité avec les SDK antérieurs (si nécessaire).

Quant au cycle de vie d’un service, Google l’illustre de la manière suivante :

Pour interagir (demarrer/arrêter…) avec un service, deux possibilités s’offrent à nous :

• Soit on appelle la méthode startService() qui invoque la méthode onCreate() puis onStart()
  service.startService() | -> onCreate() – > onStartCommand() [service running]
  L’appel de la méthode stopService() invoque la méthode onDestroy()

• Soit on appelle la méthode bindService() qui appelle uniquement la méthode onCreate()
  activity.bindService() | ->onCreate() [service created]

Il est possible de voir la liste des services exécutés en allant dans Menu > Settings > Applications > Running Services > du téléphone:

> Services locaux (LocalService)

>> Déclaration du service

Un service Local n’est accessible que par les Activity de l’application.

Pour l’exemple, notre service initialise un Timer et une tâche qui sera exécutée toutes les minutes. Nous allons créer une classe héritant de Service et surcharger les méthodes onCreate(), onStart() et onDestroy().

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

public class BackgroundService extends Service {   private Timer timer ;   @Override protected void onCreate() {     super.onCreate();     timer = new Timer();     Log.d(this.getClass().getName(), "onCreate"); }   @Override public int onStartCommand(Intent intent, int flags, int startId) {     Log.d(this.getClass().getName(), "onStart");     timer.scheduleAtFixedRate(new TimerTask() {         public void run() {             // Executer de votre tâche         }     }, 0, 60000);       return START_NOT_STICKY; }   @Override public void onDestroy() {     Log.d(this.getClass().getName(), "onDestroy");     this.timer.cancel(); }

Nous déclarons le service dans le fichier AndroidManifest.xml à l’intérieur de la balise <application> :

1	<service android:name=".BackgroundService" />

Pour le démarrer, nous faisons appel à la méthode startService(Intent) de l’Activity prenant en paramêtre un Intent. Ce dernier peut être initialisé de deux manières :

• Soit en lui passant explicitement le context de l’application et la class du service.

  1 2	Intent intent = new Intent(this,BackgroundService.class); startService(intent);

• Soit en déclarant une action dans le fichier AndroidManifest.xml…
  

  1 2 3 4 5

  <service android:enabled="true" android:name=".BackgroundService">     <intent-filter>         <action android:name=".BackgroundService.ACTION" />     </intent-filter> </service>

  … que nous passons au constructeur de l’intent

  1 2	Intent intent = new Intent(".BackgroundService.ACTION");     startService(intent);

Il est possible de passer des objets complets serialisables en paramètre avec les méthodes intent.putExtra(…). Les objets pourront être récupérer dans la méthode onStart(Intent intent, int startId) du service avec intent.getExtras().get(String key). Le fonctionnement est similaire à une table de Hash.

Pour arrêter notre service :

1 2	Intent intent = new Intent(this,BackgroundService.class); stopService(intent);

>> Implémentation des listeners

Dans un premier temps, nous allons implémenter un système de listeners très simple. L’interface IBackgroundServiceListener implémentée par notre Activity pour écouter les mises à jour du service est la suivante :

1 2 3

public interface IBackgroundServiceListener {     public void dataChanged(Object o); }

Nous créons l’interface IBackgroundService :

1 2 3 4

public interface IBackgroundService {     public void addListener(IBackgroundServiceListener listener);     public void removeListener(IBackgroundServiceListener listener); }

Nous implémentons l’interface dans le service :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

private List<IBackgroundServiceListener> listeners = null;   // Ajout d'un listener public void addListener(IBackgroundServiceListener listener) {     if(listeners == null){         listeners = new ArrayList<IGoogleWeatherListener>();     }     listeners.add(listener); }   // Suppression d'un listener public void removeListener(IBackgroundServiceListener listener) {     if(listeners != null){         listeners.remove(listener);     } }   // Notification des listeners private void fireDataChanged(Object data){     if(listeners != null){         for(IBackgroundServiceListener listener: listeners){             listener.dataChanged(data);         }     } }

Pour accéder au service depuis l’Activity nous rajoutons une variable static IBackgroundService service que nous initialiserons dans la méthode onCreate() :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class BackgroundService extends Service implements IBackgroundService { ...       private static IBackgroundService service;       @Override     public void onCreate() {         ...         service = this;     }       public static IBackgroundService getService() {         return service;     }   ... }

L’emploi d’une variable static n’est pas la meilleure solution. Nous verrons plus tard comment nous en passer. Mais à ce stade, il n’est pas possible d’accéder aux méthodes du service et d’appeler un setter.

Nous poursuivons en définissant notre listener dans notre Activity:

1 2 3 4 5 6 7 8 9 10 11

Intent intent = new   // Lancement du service Intent(this,BackgroundService.class);   startService(intent);   // Ajout de l'activity à la liste des listeners du service BackgroundService.getService().addListener(new IBackgroundServiceListener() {     public void dataChanged(Object o) {         // mise à jour de l'interface graphique     } });

Au moment voulu, dans la méthode run() du Timer nous ferons appel à la méthode privée fireDataChanged(data) pour notifier les listeners (dans notre cas, l’Activity) de la mise à jour des données.

Attention ! Si nous nous contentons d’implémenter la méthode dataChanged(), l’exception suivante sera levée au runtime :

1 2	android.view.ViewRoot$CalledFromWrongThreadException:   Only the original thread that created a view hierarchy can touch its views.

En effet, la méthode du listener dataChanged() est appelée par le Timer, et donc exécutée dans le Thread de celui-ci. L’exception nous indique que toute mise à jour de l’interface utilisateur ne peut se faire que par le Thread responsable de la création des View, Button, TextView… Nous utilisons donc la méthode runOnUiThread de la classe Activity pour poster des instructions dans l’UiThread :

1 2 3 4 5 6 7 8 9

// Ajout de l'activity à la liste des listeners du service   BackgroundService.getService().addListener(new IBackgroundServiceListener() {       public void dataChanged(final Object o) {         MyActivity.this.runOnUiThread(new Runnable() {             public void run() {                 // Mise à jour de l'UI             }     }); }});

Il nous reste à mettre à jour la méthode onDestroy() du service pour vider la liste des listeners :

1 2 3 4 5 6

@Override public void onDestroy() {     this.listeners.clear();     this.timer.cancel();     Log.d(this.getClass().getName(), "onDestroy"); }

A ce stade, nous avons vu comment déclarer notre service et y accéder, définir une tâche de fond, et mettre à jour notre interface utilisateur. Le défaut de la solution proposée est l’utilisation d’une variable static pour accéder au service depuis l’Activity. Malheureusement, la méthode startService(Intent) n’offre pas d’accès direct aux méthodes du services. Pour se faire, nous allons avoir recours au binding.

>> Implémentation d’un binder

Comme avec un RemoteService, nous allons nous connecter au service et récupérer un Binder. A travers cet objet nous accéderons aux méthodes public du service via l’interface IBackgroundService que nous avons définie plus haut. L’avantage de cette solution est d’unifier l’utilisation des LocalService et RemoteService mais surtout de récupérer l’instance du service.

Nous redéfinissons la méthode onBind(), modifions l’implémentation du listener et déportons notre tâche de fond dans la méthode _onStart() :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

public class BackgroundService extends Service implements IBackgroundService {       private Timer timer ;       private BackgroundServiceBinder binder ;       private List<IBackgroundServiceListener> listeners = null;       @Override     public void onCreate() {         timer = new Timer();           binder = new BackgroundServiceBinder(this);             _onStart();     }       @Override     public IBinder onBind(Intent intent) {         return binder;     }       public void _onStart(){         timer.scheduleAtFixedRate(new TimerTask() {             public void run() {                 if(listeners != null){                     fireDataChanged(new Object());             }         }}, 0, 60000);     }       @Override     public int onStartCommand(Intent intent, int flags, int startId) {         _onStart();         return START_NOT_STICKY;     }       // Ajout d'un listener       public void addListener(IBackgroundServiceListener listener) {           if(listeners == null){               listeners = new ArrayList<IGoogleWeatherListener>();           }           listeners.add(listener);       }         // Suppression d'un listener       public void removeListener(IBackgroundServiceListener listener) {           if(listeners != null){               listeners.remove(listener);           }       }         // Notification des listeners       private void fireDataChanged(Object data){           if(listeners != null){               for(IBackgroundServiceListener listener: listeners){                   listener.dataChanged(data);               }           }       }       @Override     public void onDestroy() {         this.listeners.clear();         this.timer.cancel();     } }

Nous définissons le binder qui nous permettra de récupérer l’instance de notre service :

1 2 3 4 5 6 7 8 9 10 11 12 13

public class BackgroundServiceBinder extends Binder{       private IBackgroundService service = null;       public BackgroundServiceBinder(IBackgroundService service) {         super();         this.service = service;     }       public IBackgroundService getService(){         return service;     } };

L’avantage de l’interface IBackgroundService est de masquer les méthodes onCreate(), onBind()... et de ne proposer uniquement addListener(), removeListener() et pourquoi pas d’autres méthodes métiers.

Il nous reste à nous connecter au service, accéder aux méthodes exposées par l’interface et s’ajouter comme listener pour mettre à jour l’interface utilisateur :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Intent intent = new Intent(this,BackgroundService.class);   final IBackgroundServiceListener listener = new IBackgroundServiceListener() {     public void dataChanged(final Object data) {         MyActivity.this.runOnUiThread(new Runnable() {             public void run() {                 // Mise à jour de l'UI               }         });     } };   ServiceConnection connection = new ServiceConnection() {     public void onServiceConnected(ComponentName name, IBinder service) {         Log.i("BackgroundService", "Connected!");         IBackgroundService service = ((BackgroundServiceBinder)service).getService();         service.addListener(listener);     }       public void onServiceDisconnected(ComponentName name) {         Log.i("BackgroundService", "Disconnected!");     }   };     bindService(intent,connection, Context.BIND_AUTO_CREATE);

La connexion au service se fait via la méthode bindService (Intent service, ServiceConnection conn, int flags) de la classe Context dont hérite Activity. L’argument flags peut prendre soit 0 soit Context.BIND_AUTO_CREATE pour forcer le service à démarrer, s’il ne l’est pas, au moment de la connexion.

La partie sur les LocalService est terminée. Je ne suis pas personnellement convaincu de leur intéret. Les classes Service, ServiceConnection, IBinder… sont relativement contraignantes, complexifient le code et n’offrent pas vraiment d’aide à la réalisation de services. Mais si un jour votre LocalService doit se transformer en RemoteService alors vous serez prets.

> Services distants (RemoteService)

>> Déclaration du service

Contrairement aux LocalService qui s’exécutent dans le processus de l’application et plus particulièrement dans le thread principal, les RemoteService s’exécutent dans un processus totalement différent de celui de votre application.

Afin que deux processus différents puissent communiquer et s’échanger des données, Google a implémenté son IDL appelé AIDL (Android Interface Definition Language) pour décrire les méthodes publiques et les données échangées. Cette description se fait dans un fichier .aidl qui devra être connu des deux processus !

Pourront être échangées entre deux processus, seulement les types primitifs java (int, boolean, etc), les String, List, Mapet CharSequence. Pour des objects personnalisés, vous devrez implémenter l’interface Parcelable.

Un RemoteService peut être sollicité par plusieurs applications différentes. C’est pourquoi je préfère le déporter dans un nouveau projet Android sous Eclipse. Je conseille également la réalisation d’une petite interface graphique avec deux boutons pour le démarrer et l’arrêter. Si vous ne souhaitez pas créer un projet particulier, il faudra ajouter android:process=":remote" à la déclaration de votre service (<service>) dans le fichier AndroidManifest.xml.

Après avoir créer un projet BackgroundService (package de l’application com.android23.backgroundservice), nous créons notre service com.android23.backgroundservice.service.BackgroundService le plus simple qui soit, avec un Timer et un objet Data:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

public class BackgroundService extends Service  {       private Timer timer ;     private BackgroundServiceBinder binder ;     private Data data;       @Override     public void onCreate() {         binder = new BackgroundServiceBinder(this);         timer = new Timer();         _onStart();     }       public void _onStart(){         timer.scheduleAtFixedRate(new TimerTask() {             public void run() {                 data = new Data(18, Data.Weather.ENSOLEILLE);                 }         }, 0, 60000);     }       @Override     public void onDestroy() {         super.onDestroy();         this.binder = null;         this.timer.cancel();     }       @Override     public IBinder onBind(Intent intent) {         return binder;     }       public Data getData() {         return data;     } }

Pour chaque RemoteService il est nécessaire de déclarer un fichier .aidl que nous plaçons dans le même package (com.android23.backgroundservice.service).

Voici le contenu de notre fichier IRemoteBackgroundService.aidl :

1 2 3 4 5 6 7 8 9

package com.android23.backgroundservice.service;   import com.android23.backgroundservice.bo.Data;   interface IRemoteBackgroundService {       int getPid(); // Renvoie le PID du processus du service     Data getData(); // Renvoie notre objet mis à jour     //void updateData(in Data data); }

Il n’y pas de règle concernant le nom du fichier. Ce fichier sert d’interface entre le client et le service. Nous y déclarons seulement les méthodes public. La syntaxe ressemble fortement au Java bien que cela n’en soit pas. Les mots clefs ‘in‘, ‘out‘, ‘inout‘ sont ajoutés aux paramètres des méthodes. ‘//‘ permet d’ajouter des commentaires. Enfin on peut spécifier ‘oneway‘ devant interface.

Nous créons dans le package com.android23.backgroundservice.bo, notre objet java Data implémentant l’interface Parcelable :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

public class Data implements Parcelable {     public static enum Weather {NUAGEUX,PLUVIEUX,ENSOLEILLE,BROUILLARD}     private int temperature;     private Weather today;       public static final Parcelable.Creator<Data> CREATOR = new Parcelable.Creator<Data>() {         public Data createFromParcel(Parcel in) {             return new Data(in);         }           public Data[] newArray(int size) {             return new Data[size];         }     };       public Data(int temperature, Weather today) {         super();         this.temperature = temperature;         this.today = today;     }       public int getTemperature() {         return temperature;     }       public Weather getToday() {         return today;     }       private Data(Parcel in) {         readFromParcel(in);     }       public void readFromParcel(Parcel in) {         temperature = in.readInt();         today = (Weather)in.readSerializable();     }       public int describeContents() {         return 0;     }       public void writeToParcel(Parcel arg0, int arg1) {         arg0.writeInt(temperature);         arg0.writeSerializable(today);     }   }

Notre objet contient le temps et la température, deux types java simples. Le code est calqué sur l’exemple que vous trouverez sur http://developer.android.com/guide/developing/tools/aidl.html.

L’interface Parcelable nous oblige à définir la méthode writeToParcel() dans laquelle nous ajoutons à l’objet Parcel tous les attributs de notre objet Data. Un Parcel peut être vue comme l’unité de communication entre deux processus. Attention, l’ordre dans lequel nous ajoutons les attributs à une importance. C’est ordre doit être respecté dans la méthode readFromParcel().

L’attribut static CREATOR est obligatoire. Il implémente l’interface Parcelable.Creator. L’implémentation de cette interface nous force a écrire la méthode readFromParcel().

Pour que notre objet Data puisse voyager d’un processus à l’autre, il nous reste à déclarer son fichier Data.aidl :

1 2	package com.android23.backgroundservice.bo; parcelable Data;

Le mot clef parcelable spécifie que notre objet Data implémente bien le protocole Google pour les communication IPC.

Les erreurs contenues dans les fichiers .aidl devraient disparaitre. Eclipse génère alors l’interface Java IRemoteBackgroundService dans le répertoire source « gen » du projet :

Il nous reste ensuite à déclarer notre BackgroundServiceBinder qui permettra au client d’accéder aux méthodes déclarées dans le fichier aidl. Notre binder hérite de IRemoteBackgroundService.Stub généré par Eclipse :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class BackgroundServiceBinder extends IRemoteBackgroundService.Stub{       private BackgroundService service = null;       public BackgroundServiceBinder(BackgroundService service) {         super();         this.service = service;     }       public Data getData() throws RemoteException {         return service.getData();     }       public int getPid() throws RemoteException {         return Process.myPid();     } };

N’oublions pas de déclarer notre service dans le fichier AndroidManifest.xml :

1 2 3

<application android:icon="@drawable/icon" android:label="@string/app_name">     <service android:exported="true" android:name=".service.BackgroundService" /> </application>

Il est possible d’ajouter une permission :

1 2 3 4 5

<permission android:name="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION" /> <application android:icon="@drawable/icon" android:label="BackgroundService">     <service android:exported="true" android:enabled="true"       android:name=".service.BackgroundService" android:permission="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION"/> </application>

Les clients devront déclarer cette permission dans leur fichier manifest pour se connecter au service. Sans quoi une SecurityException sera levée à l’appel des méthodes startService ou bindService. Pour plus d’informations concernant les permissions, jetez un coup d’oeil à la documentation Google:

• http://developer.android.com/guide/topics/manifest/manifest-intro.html#perms
• http://developer.android.com/guide/topics/security/security.html

Revenons à notre projet Eclipse principal. Pour réaliser notre appel distant au service, nous devons y copier/coller les fichier .aidl Data.aidl, et IRemoteBackgroundService.aidl dans le même package que le projet BackgroundService, ainsi que votre objet java Data! Eclipse créera automatiquement les interfaces d’accès.

Pour nous connecter au service, rien de bien compliqué :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Intent intent = new Intent(); intent.setClassName("com.android23.backgroundservice", "com.android23.backgroundservice.service.BackgroundService");   ServiceConnection remoteConnection  = new ServiceConnection() {       public void onServiceDisconnected(ComponentName name) {       }           public void onServiceConnected(ComponentName name, IBinder service) {         IRemoteBackgroundService service = IRemoteBackgroundService.Stub.asInterface(service);         try {             service.getPid();             service.getData();         } catch (RemoteException e) {             // TODO Auto-generated catch block         }     } };   bindService(intent, remoteConnection, Context.BIND_AUTO_CREATE);

Nous passons au constructeur de l’Intent le package principal de notre projet BackgroundService puis la classe du service.
IRemoteBackgroundService.Stub.asInterface() nous permet de récupérer notre service. A noter également que chaque appel de méthode peut lever une RemoteException.

Pour nous déconnecter au service, nous faisons appel à la méthode unbindService(ServiceConnection) qui prend en paramêtre l’object ServiceConnection que nous avons créé :

unbindService(remoteConnection);

Il est indispensable d’ajouter la permission dans le fichier AndroidManifest.xml, au même niveau que la balise <application> sans quoi notre Activity ne se connectera jamais :

1	<uses-permission android:name="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION"></uses-permission>

Il n’est pas possible de débugger à la fois le service et notre application. Pour tester, notre service il sera nécessaire de développer dans notre projet BackgroundService une Activity avec 2 boutons : un pour démarrer le service, et l’autre pour l’arrêter.
Pour tester notre application, nous déployons le service en premier puis nous lançons notre application en mode debug.

>> Mise en place d’un syteme de Callback/Listeners

Comme pour les LocalService, les RemoteService peuvent également notifier leurs clients grâce une liste RemoteCallbackList. Pour cela nous allons apporter quelques modifications.

Pour commencer, retournons dans le projet BackgroundService, et modifions le fichier IRemoteBackgroundService.aidl en supprimant la méthode getData() et en rajoutant les méthodes registerCallback et unregisterCallback qui permettrons aux clients de s’enregistrer auprès du service :

1 2 3 4 5 6 7 8 9 10 11

package com.android23.backgroundservice.service;   import com.android23.backgroundservice.service.IRemoteBackgroundServiceCallback;   interface IRemoteBackgroundService {             int getPid();           void registerCallback(IRemoteBackgroundServiceCallback cb);     void unregisterCallback(IRemoteBackgroundServiceCallback cb); }

A travers cette interface, les clients pourront s’enregistrer. Une fois enregistrés il leur faudra implémenter l’interface IRemoteBackgroundServiceCallback que nous déclarons dans le fichier IRemoteBackgroundServiceCallback.aidl :

1 2 3 4 5 6 7

package com.android23.backgroundservice.service;   import com.android23.backgroundservice.bo.Data;   interface IRemoteBackgroundServiceCallback {           void dataChanged(in Data data); }

Nous déclarons dans notre service, la liste des clients à l’écoute :

1 2 3 4 5

final RemoteCallbackList<IRemoteBackgroundServiceCallback> callbacks = new RemoteCallbackList<IRemoteBackgroundServiceCallback>();       public RemoteCallbackList<IRemoteBackgroundServiceCallback> getCallbacks() {         return callbacks;     }

Nous mettons à jour la méthode _onStart() afin de créer un nouvel objet Data toutes les minutes et notifier les clients :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public void _onStart() {     Log.i(getClass().getSimpleName(), "_onStart()");     timer.scheduleAtFixedRate(new TimerTask() {         public void run() {             data = new Data(++counter, Data.Weather.BROUILLARD);                     // Broadcast to all clients the new value.             final int N = callbacks.beginBroadcast();             for (int i = 0; i < N; i++) {                 try {                     callbacks.getBroadcastItem(i).dataChanged(data);                 }                   catch (RemoteException e) {}             }             callbacks.finishBroadcast();         }     }, 0,60000); }

callbacks.beginBroadcast() et callbacks.finishBroadcast(); encadre le début et la fin de la notification des clients. callbacks.getBroadcastItem(i) vous permet d’appeler les méthodes de l’intarface IRemoteBackgroundServiceCallback et prévenir les clients. Elle ne peut être appelée qu’après beginBroadcast()

Nous désactivons la liste des callbacks dans la méthode onDestroy() :

1 2 3 4 5 6 7

@Override public void onDestroy() {     super.onDestroy();     this.binder = null;     this.callbacks.kill(); // Désactive tous les éléments de la liste     this.timer.cancel(); }

N’oublions pas de mettre à jour notre Binder implémentant l’interface IRemoteBackgroundService.Stub :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

public class BackgroundServiceBinder extends IRemoteBackgroundService.Stub{       private BackgroundService service = null;       public BackgroundServiceBinder(BackgroundService service) {         super();         this.service = service;     }       @Override     public int getPid() throws RemoteException {         return Process.myPid();     }       @Override     public void registerCallback(IRemoteBackgroundServiceCallback cb) throws RemoteException {         if(cb != null){             service.getCallbacks().register(cb);         }         }       @Override     public void unregisterCallback(IRemoteBackgroundServiceCallback cb) throws RemoteException {         if(cb != null){             service.getCallbacks().unregister(cb);         }     } };

Retournons maintenant du côté de notre application principale pour y copier les fichiers IRemoteBackgroundService.aidl et IRemoteBackgroundServiceCallback.aidl dans le package com.android23.backgroundservice.service.

Puis mettons à jour la manière dont nous nous connectons au service en déclarant un IRemoteBackgroundServiceCallback et en l’inscrivant auprès du service dans la méthode onServiceConnected() :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Intent intent = new Intent(); intent.setClassName("com.android23.backgroundservice", "com.android23.backgroundservice.service.BackgroundService");           final IRemoteBackgroundServiceCallback callback = new IRemoteBackgroundServiceCallback.Stub() {     public void dataChanged(Data data) throws RemoteException {         Log.d( getClass().getSimpleName(), "Temperature : " + data.getTemperature());         Log.d( getClass().getSimpleName(), "Temps : " + data.getToday().toString());     } };   ServiceConnection remoteConnection  = new ServiceConnection() {     public void onServiceDisconnected(ComponentName name) {         Log.d( getClass().getSimpleName(), "onServiceConnected()" );     }           public void onServiceConnected(ComponentName name, IBinder service) {         remoteBackgroundService = IRemoteBackgroundService.Stub.asInterface(service);         try {             remoteBackgroundService.getPid();             remoteBackgroundService.registerCallback(callback);         }         catch (RemoteException e) {}     } };   bindService(intent, remoteConnection, Context.BIND_AUTO_CREATE);

Pour tester, nous déployons le service et puis nous lançons en mode debug notre application.

>> Démarrer le service au boot du téléphone

Dans le projet BackgroundService, nous rajoutons un BroadcastReceiver :

1 2 3 4 5 6 7 8

public class BackgroundServiceReceiver extends BroadcastReceiver{     @Override     public void onReceive(Context context, Intent intent) {         Intent serviceIntent = new Intent();         serviceIntent.setClassName("com.android23.backgroundservice", "com.android23.backgroundservice.service.BackgroundService");         context.startService(serviceIntent);     } }

Nous le rajoutons dans le fichier AndroidManifest.xml :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<permission android:name="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION" />   <application android:icon="@drawable/icon" android:label="@string/app_name">         <service android:exported="true" android:name=".service.BackgroundService" android:permission="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION" />         <receiver android:name=".service.BackgroundServiceReceiver">         <intent-filter>             <action android:name="android.intent.action.BOOT_COMPLETED" />             <category android:name="android.intent.category.HOME" />         </intent-filter>     </receiver> </application>   <uses-permission android:name="com.android23.backgroundservice.BACKGROUNDSERVICE_PERMISSION"/>

Nous avons également précisé que notre service demande la permission BACKGROUNDSERVICE_PERMISSION pour pouvoir démarrer tout seul.

Déployons le service sur l’émulateur en faisant un clic droit sur le projet : Run As > Android Application. Une fois déployé, re-démarrons l’émulateur en cliquant sur le bouton dans la barre d’outil d’Eclipse puis sur le bouton start dans la fenêtre qui apparait. Une fois l’émulateur lancé, il suffit d’aller dans Menu > Settings > Applications > Running Services > pour constater que notre BackgroundService est bien en route.

>> Exemple : Connexion au service MP3

Le lecteur MP3 d’Android est lui aussi un RemoteService. Il est donc très simple de s’y connecter pour récupérer la chanson en cours, l’artiste… Pour l’exemple n’oubliez pas de lancer la lecture d’un fichier mp3.

Profitons du fait qu’Android soit open-source pour nous rendre sur Google Code et récupérer le fichier IMediaPlaybackService.aidl.

Une fois le fichier récupéré, nous créons le package "com.android.music" dans lequel nous insérons le fichier .aidl. Eclipse génère alors automatiquement l’interface IMediaPlaybackService. Le service ne renvoyant que des types primitifs, seul ce fichier suffit au client.

Nous nous connectons au lecteur mp3 comme nous nous connections à notre BackgroundService :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Intent intent = new Intent(); intent.setClassName("com.android.music", "com.android.music.MediaPlaybackService");   ServiceConnection conn = new ServiceConnection() {     @Override     public void onServiceDisconnected(ComponentName componentname) {     }       @Override     public void onServiceConnected(ComponentName componentname, IBinder ibinder) {         IMediaPlaybackService service = IMediaPlaybackService.Stub.asInterface(ibinder);           try {             Log.i("ServiceConnection", "Playing track: " + service.getTrackName());             Log.i("ServiceConnection", "By artist: " + service.getArtistName());         } catch (Exception e) {         }       } };   this.bindService(intent, conn, 0);

Malheureusement, si Google modifie l’interface .aidl de son lecteur MP3 il faudra mettre à jour le fichier IMediaPlaybackService.aidl dans notre projet.

> Conclusion

Le post est relativement long mais regroupe tout ce que j’ai pu apprendre en parcourant le net. Je vais réfléchir à le publier au format PDF dans la rubrique tutorial.

L’intérêt des LocalService reste flou à mes yeux. J’ai la fâcheuse impression de gagner plus en complexité qu’en productivité. A contrario, les RemoteService ont une véritable valeur ajoutée. Ainsi on peut imaginer un service météo commun à toutes nos applications et nos widgets. Les possibilités sont nombreuses dès lors que l’OS gère le multi-taches

Si vous souhaitez que certains points soient approfondis, ou corrigés, n’hésitez pas à m’en faire part.

> Ressources

• http://developer.android.com/reference/android/app/Service.html

• http://blog.7touchgroup.com/tag/android-services-versus-broadcast-receivers/

• http://www.brighthub.com/mobile/google-android/articles/34861.aspx

• http://saigeethamn.blogspot.com/2009/09/android-developer-tutorial-part-9.html

• http://www.androidcompetencycenter.com/2009/06/start-service-at-boot/

• http://www.alexc.me/android-music-app-service-currently-playing-song/231/

> Environnement : Windows XP, Eclipse 3.5, ADT 0.9.5 et le SDK Android 1.6/2.0.1

En théorie, sous Eclipse, il suffit d’ouvrir la perspective DDMS (Dalvik Debug Monitor Server) et de saisir les coordonnées dans la vue « Emulator Control »

En mettant un point d’arrêt dans la méthode :

1 2 3

public void onLocationChanged(Location location) {     …   }

On s’aperçoit que l’application réagit au premier essai, mais pas aux tentatives suivantes…

J’ouvre une invite de commande sous Windows et me connecte à l’émulateur par Telnet pour saisir manuellement les coordonnées :

geo fix [longitude] [latitude] [altitude (optionnelle)]

Cette fois ci, l’application réagit à chaque changement !

Mais je constate une différence entre les coordonnées saisies précédemment et celles notées sous Eclipse :

Location[mProvider=gps,mTime=1261440000000,mLatitude=47.207835833333334,mLongitude=-1.5516668333333334,
mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,
mBearing=0.0,mHasAccuracy=false,mAccuracy=0.0,mExtras=null]

[ Mise à jour : 25/01/2010 ]
Le problème existe depuis la version 0.9 du SDK et ne semble pas avoir été corrigé depuis.
Le blog http://www.insideandroid.fr nous donne une explication :

« …en France la longitude et la latitude sont envoyées sous le format « 120,0832 » au lieu de « 120.0832 ». Cela engendre un bug critique qui empêche la mise à jour des coordonnées dans votre émulateur. »

Deux solutions existent :

• Sous XP, allez dans Panneau de Configuration > Options régionales et linguistiques. Dans Standarts et Formats sélectionnez « Anglais (Etats Unis) ».
• Ajouter la ligne -Duser.language=en dans le fichier eclipse.ini.

Redémarrez Eclipse dans les deux cas, pour que les modifications soient prises en compte, et tout fonctionnera sans problème !

Merci à @lesgrumels pour le commentaire

> Ressources

• http://code.google.com/p/android/issues/detail?id=2545
• http://groups.google.co.jp/group/android-developers/browse_thread/thread/b460684fed89a516
• http://groups.google.com/group/android-developers/browse_thread/thread/5360c665c92af02e/d1ee24b3377a47da#d1ee24b3377a47da
• http://www.insideandroid.fr/post/2009/03/28/Simulation-du-GPS-avec-l-emulateur-android

Dans ce billet je vais donc expliquer comment :

• Créer une carte SD en ligne de commande
• Créer une carte SD sous Eclipse
• Configurer Eclipse
• Ajouter des fichiers
• Lister les fichiers dans une application

> Créer une carte SD en ligne de commande

Ouvrez une ligne de commande Windows. Allez dans le répertoire où vous souhaitez la créer puis utilisez l’outil du SDK mksdcard:

Pour créer un carte sd_card d’1 Go :
> mksdcard 1024M sd_card

Il est inutile de spécifier une extension au nom de la carte.

Puis sous Eclipse: Run > Run configurations > Target
Dans le champ « Additional Emulator Command Line Options »,ajoutez le paramètre :
-sdcard <filepath>/<filename>

On indique ainsi pour chaque projet, s’il nécessite une carte et laquelle.

> Créer une carte SD sous Eclipse

Il est possible de créer une carte SD lors de la création du Android Virtual Device (AVD).

Les données restent persistantes. Si vous relancer l’émulateur, les fichiers seront toujours présents.

Vous pouvez également spécifier un fichier créé avec la commande mksdcard

De cette manière, tous vos projets déployés sur ce même AVD utiliseront cette carte SD. Sinon vous devez créer un AVD par projet et spécifier sur quel AVD vous voulez déployer chacun de vos projets.

Pour cela dans Eclipse: Run > Run configurations > Target et sélectionnez l’AVD

> Ajouter des fichiers

Vous pouvez voir le contenu de la carte SD dans la vue DDMS sous l’onglet File Explorer :

Il est nécessaire que l’émulateur soit lancé.

Pour ajouter des fichiers deux solutions existent mais qu’une fonctionne (c’est la magie de google):

• En ligne de commande, utiliser la commande adb push <source path> /sdcard/:
  

• Sous Eclipse, sélectionnez le répertoire sdcard et cliquez sur le bouton de droite à coté des onglets :
  
  Malheureusement, j’obtiens systématiquement le message Failed to push the item(s) dans la console

J’ai quand même un doute sur la prise en compte à chaud de nouveaux fichiers, du moins en ce qui concerne le lecteur mp3…

> Lister les fichiers dans une application

Je vais faire court puisque qu’un très bon tutorial existe http://www.anddev.org/building_an_android_filebrowser_list-based_-t67.html et montre comment lister les fichiers du téléphone dans une ListActivity

Rien de bien sorcier, puisqu’on part d’un objet File en indiquant la racine du téléphone :

File file = new File("/");

Pour lister les fichiers de la carte SD, on partira de :

File file = new File("/sdcard/");

On prendra soin de vérifier la présence de la carte SD avec file.exist(); qui renvoie vrai si le répertoire ou le fichier existe. On peut prendre également la précaution de s’assurer que notre fileest un bien un répertoire en utilisant file.isDirectory();.

Enfin n’oublions pas :

file.listFiles();

qui renvoie un tableau de Fileprésents dans le répertoire.

Pour compiler l’exemple, effectuez les quelques modifications indiquées sur ce post : http://www.anddev.org/viewtopic.php?p=12328#12328

> Ressources

• http://www.anddev.org/tinytut_-_pull-push_files_from-to_the_emulator_eclipse-t113.html

• http://modmygphone.com/wiki/index.php/Emulating_SD_card
• http://www.anddev.org/building_an_android_filebrowser_list-based_-t67.html

Je me présente : Nicolas, Développeur Java/J2EE depuis 3 en SSII à Nantes. Le choix de la plateforme s’est fait tout naturellement. J’ai pu rapidement trouver mes marques et réaliser quelques idées en Java sous Eclipse. L’accessibilité de l’environnement de développement et l’arrivée du Google Phone NexusOne, je l’espère, en motiveront plus d’un à se lancer dans l’aventure.

Après quelques applications j’ai été confronté à un manque de ressources en français. C’est la principale raison de ce blog. J’ai donc du aller voir ce que proposait nos amis d’outre-Atlantique. Si la documentation Google http://developer.android.com/guide/index.html est une véritable mine d’or, je suis tombé sur http://www.anddev.org/index.php regorgeant d’astuces, d’exemples… et plein d’autres que je citerai dans mes articles.

En dehors du forum http://www.developpez.net/forums/f1238/java/general-java/java-mobiles/android/ et quelques blogs http://jahbromo.blogspot.com/, http://android.cyrilmottier.com/ et http://android-france.fr/category/developpement/ je n’ai pas trouvé grand chose.

J’espère donc que ce blog apportera quelques solutions à vos développements actuels et futurs. N’hésitez surtout pas à laisser des commentaires. Cela me permettra d’avoir un regard critique sur ce qui a été écrit et de corriger les erreurs qui se sont glissées lors de la rédaction des billets.