Un article de ndruet    2 Commentaires

Les développeurs Iphone ont bien de la chance. Les 3 téléphones d’Apple ont des caractéristiques très proches: résolutions d’écrans identiques (11,5 x 6,1 x 1,16), des capteurs identiques (gps, boussoles magnétiques,accéléromètres…), le WiFi… L’OS se met à jour via ITunes et permet ainsi aux utilisateurs de bénéficier des dernières nouveautés immédiatement après la publication d’Apple.

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.