AccueilLes mois à venir verront fleurir une multitude de nouveaux terminaux Android. Si jusqu’a présent les terminaux avaient une certaine homogénéité aux niveaux des caractéristiques (HVGA, écran tactile capacitif, APN autofocus, accéléromètre, boussole…) ce ne sera pas le cas pour tous les produits arrivants et les développeurs d’applications vont devoir s’adapter.
Ainsi, le HTC Tatto, disponible depuis peu chez The Phone House, se trouve pourvu d’un écran QVGA résistif et d’un APN sans autofocus. Cette nouvelle résolution aura un impact sur l’UI des applis conçues pour du HVGA et l’absence d’autofocus rendra inutilisable certaines applications tels que les lecteurs de code barre 1D.
Android offre des solutions pour prendre en compte (en partie) cette hétérogénéité de manière simple et sans avoir à toucher au coeur du code source; ceci via 2 axes: les ressources alternatives (Alternate Resources) et le filtrage au sein de l’Android Market.
Les ressources alternatives (Alternate Resources)
Pour simplifier, dans une application Android, les ressources (physiquement séparées du code source) permettent de définir:
- la structure de l’interface graphique sous forme de fichiers xml -> dans le répertoire layouts.
- les images utilisées, par exemple en arrière plan-> dans le répertoire drawable.
- des jeux de valeurs ou wording -> dans le répertoire values.
Ce qui est intéressant est qu’Android permet de définir des jeux de ressources qui seront automatiquement sélectionnés en fonction de la langue ou de la configuration hardware. Il suffit juste d’ajouter au nom du répertoire de ressources, un tiret (”-”) et l’argument qui représente la langue ou la configuration hardware.
Exemple concret :
Voici l’arborescence d’une partie des ressources de mon application:
res/
layout/
main.xml
J’ai donc choisi de définir la structure de mon interface graphique dans le fichier main.xml . Le répertoire “layout” est celui utilisé par défaut.
Mais je voudrais que l’interface graphique soit sensiblement différente sur une résolution QVGA (320×240) afin de prendre en compte la différence de surface. Je vais alors ajouter un répertoire spécifique à la résolution 320×240:
res/
layout/
main.xml
layout-320×240/
main.xml
Lorsque mon application sera lancée sur un terminal, celle-ci choisira automatiquement le bon répertoire de ressource à utiliser.
Il est possible d’utiliser le même mécanisme pour le wording avec le répertoire “values” qui contiendra, par exemple, tout les textes en anglais et un répertoire ” values-fr ” contenant les textes en français.
Voici la liste des paramètres utilisables :
MCC et MNC :
Les valeurs Mobile Country Code et Mobile Network Code sont lues à partir de la SIM. Par exemple, pour la France MCC=208 et pour Bouygues Telecom MNC=20.
Donc, si on souhaite avoir des images différentes lorsque l’application est lancée avec une SIM Bouygues télécom, il suffira d’ajouter le répertoire
drawable-mcc208-mnc20/
Langue et région :
Ex: values-fr (uniquement langue) ou values-en-rUS (langue + région)
Dimension de l’écran :
3 valeurs: small (~QVGA) , normal (~HVGA), large (~VGA)
Ecran plus large que long (ou inversement) :
long, notlong
long est a utiliser pour les résolutions “wide” : WQVGA, WVGA…
Orientation de l’écran :
port, land, square
mode portrait/paysage ou carré. Est appliqué lors du changement de mode avec l’accéléromètre.
Densité de pixel :
Valeurs: ldpi, mdpi, hdpi, nodpi
Mdpi (medium) ~ 160dpi
Ldpi (low)~ 120 dpi
Hdpi (high)~240 dpi
Type d’écran tactile :
notouch, stylus, finger
Clavier physique :
keysexposed, keyshidden, keyssoft
clavier physique sorti, ou pas, ou carrément absent
Mode d’écriture principal :
nokeys, qwerty, 12key
Touches de navigation :
nonav, dpad, trackball, wheel
Dimension de l’écran en pixels :
Ex: 320×240
Version du sdk :
v1 v2 v3 v4
rappel
1= 1.0, 2= 1.1, 3=1.5(cupcake), 4=1.6(donut)
Bien entendu, il est possible de faire des cumuls.
Exemple :
drawable-mcc208-mnc20-fr-BE-land
Ce répertoire sera utilisé par le téléphone lorsqu’il y aura une sim Bouygues Telecom, que la langue soit le francais, la région la belgique et que le terminal soit en mode paysage.
Filtrage Market
Donut apporte de nouveaux tags permettant de cacher son application aux terminaux non compatibles dans l’Android Market. Ces tags sont à mettre dans le fichier AndroidManifest.xml .
Passons-les en revue:
Uses Sdk
Arguments:
android:maxSdkVersion : niveau max d’API
android:minSdkVersion : niveau min d’API
android:targetSdkVersion : indique que l’appli a été développée et testée sur ce niveau d’API, mais qu’elle pourrait marcher sur d’autres (à utiliser avec min et max)
Rappel des niveaux d’API:
version d’android niveau d’API
1.0 -> 1
1.1 ->2
1.5 (Cupcake) -> 3
1.6 (Donut) -> 4
Supports Screens
Par défaut, une application est censée supporter toutes les résolutions. Si ce n’est pas le cas, elle doit désactiver les résolutions pour lesquelles elle ne convient pas.
Attention, pour les applis compilées sur un sdk antérieur à Donut, il n’y aura que le support du HVGA par défaut, donc ces applis ne seront pas visibles sur le market avec des terminaux en QVGA (comme le Htc Tattoo par exemple) !
Voici les arguments dont les valeurs seront true ou false
android:anyDensity : support de toutes les densités de pixel
android:largeScreens : support des terminaux avec grands écran (~vga)
android:normalScreens : support des terminaux avec écran standards(~hvga)
android:resizeable : l’appli peut ajuster sa taille automatiquement
android:smallScreens : support des terminaux avec petits écran (~qvga)
Question : Que faire pour que les applis déjà développées soient visibles sur le HTC Tattoo?
Il faut mettre la “build target” de l’application à 1.6 et ajouter le tag < supports-screens android:smallScreens=”true”> . L’appli sera visible sur les anciens terminaux et sur le HTC Tattoo.
Uses Configuration
Le tag indique des pré-requis hardware.
Voici les arguments:
android:reqFiveWayNav Five way navigation (4 directions + ok), valeur: true ou false.
android:reqHardKeyboard nécessite clavier physique, valeur: true ou false
android:reqKeyboardType le type de clavier, valeur: undefined/nokeys/qwerty/twelvekey
android:reqNavigation type de navigation préféré, valeurs : undefined/nonav/dpad/trackball/wheel
android:reqTouchScreen type d’écran tactile requis, valeurs: undefined/notouch/stylus/finger
Uses Feature
Tag pour indiquer une fonctionnalité spécifique.
2 arguments pour l’instants:
android:glEsVersion version du driver opengl requis
android:name:fonctionnalité requise. Pour l’instant que 2 valeurs possibles: “android.hardware.camera” et “android.hardware.camera.autofocus”
Final words…
Pour pouvoir exploiter pleinement les alternate resources, il faudra impérativement utiliser les layouts xml. Cela permettra une plus grande souplesse, notamment lors des mises à jour pour prendre en compte de nouvelles résolutions d’écrans.
Le filtrage market est un point important puisqu’il évitera le coté déceptif d’une application qui plante ou ne marche pas à cause d’une fonctionnalité manquante.
Articles relatifs au sujet :
Concevoir ses applications pour anticiper la sortie de nouveaux terminaux Android - Point GPhone
Devenez développeur Android grâce à notre formation vidéo.
Source : http://feedproxy.google.com/~r/pointgphone/~3/mpxD...
A l’approche de l’évaluation du RGPD de la Commission européenne, Alliance Digitale présente neuf propositions pour les entreprises du marketing digital
