I. Spécialisation des ressources▲
Les exemples de spécialisation des ressources les plus complets se trouvent dans le code source d'Android ; vous trouverez ci-dessous la présentation d'une partie des ressources du navigateur web (à gauche) et du lecteur de musique (à droite).
Pour le navigateur web, remarquez les ressources par défaut values ou layout. layout-land s'appliquera uniquement lorsque le périphérique est en mode paysage. Pour le lecteur de musique, notez les différents dossiers values caractérisés par la langue (cs, da, etc.), mais également par la présence d'un clavier coulissant en position ouverte ou fermée ou bien d'un écran tactile utilisable avec le doigt (par opposition à un écran à stylet). Spécialiser des ressources implique donc la création de sous-dossiers spécifiques, dont le nom doit correspondre au protocole spécifié par Google et dont une liste exhaustive est donnée ci-après. Ce mode opératoire peut se voir appliqué pour l'ensemble des dossiers présents dans res. Les méthodes d'accès décrites précédemment s'appliqueront à l'ensemble des ressources et, pour un même identifiant, c'est le système qui déterminera quelle ressource choisir en fonction des critères. Ci-après, nous listons les principaux critères susceptibles d'être pris en compte quant à la spécification des ressources à utiliser lors de l'exécution de l'application. Une application s'affichera sans erreur à condition que les ressources soient au minimum écrites pour les valeurs par défaut dans les dossiers, comme layout, values, menu, etc. Ensuite, il est possible d'utiliser les critères pour améliorer l'expérience utilisateur (langages, interfaces).
I-A. Les langages et régions▲
Comme indiqué dans l'exemple String Format (figure 5-1), un langage est décrit par deux lettres, et ce conformément à la norme ISO 639-1. À titre d'exemple, fr correspond au français, en à l'anglais et de à l'allemand. Certaines variations linguistiques pouvant être observées pour une même langue selon la région où celle-ci est pratiquée, un critère régional peut venir compléter le type de langage. Ainsi, deux lettres correspondant à la région considérée et répondant à la norme ISO 3166-1-alpha-2, précédées de la lettre r peuvent être ajoutées de manière à affiner la spécification, par exemple dans l'exemple 5-3 nous avons différencié l'anglais pratiqué aux États-Unis et en Angleterre avec le suffixe en-rGB.
Exemple : un dossier positionné au même niveau que values et nommé values-fr contient les valeurs à utiliser dans le cas où la langue choisie par l'utilisateur pour son périphérique est le français. Dans le cas où aucun dossier ne correspond à la langue courante, les valeurs contenues dans values sont prises en considération par défaut. Ce critère de langage s'applique également aux couleurs, styles et thèmes présents dans le dossier values .
I-B. Les codes réseaux nationaux et commerciaux▲
Les ressources peuvent être différenciées selon le critère du réseau sur lequel l'application est exécutée. Cette caractéristique se décompose en un premier code correspondant au réseau du pays, défini par les lettres mcc suivies du code pays, et un deuxième code correspondant à l'opérateur sollicité, défini par les lettres mnc , suivies du code opérateur (on trouve facilement le code des opérateurs mondiaux sur Internet).
Exemple : imaginons une application qui se comporte différemment selon les opérateurs, par exemple pour l'affichage d'un logo ou d'une grille tarifaire des services proposés par celui-ci.
I-C. Les tailles des écrans▲
L'un des critères essentiels quant au choix des ressources à mettre en oeuvre, lors de l'exécution de l'applicatif Android, réside dans la taille de l'écran qui équipe le terminal. Quatre tailles sont identifiables : petit, normal et grand et très grand : small , normal , large , xlarge (introduit avec la version 2.3).
Exemple : le critère de taille d'écran permet de définir des layouts différents. Il est possible d'afficher plus ou moins d'informations sur un layout ou même d'avoir une disposition et une ergonomie différente.
I-D. Les formats d'écrans▲
La longueur de l'écran, en termes d'aspect ratio, peut également être considérée. Il s'agit là de la caractéristique Screen Aspect, pouvant avoir pour valeur long ou notlong .
Exemple : comme pour le critère précédent, l'expérience utilisateur peut être différenciée suivant le format de l'écran.
I-E. La densité des pixels des écrans▲
La densité pixellique de l'écran peut également être prise en considération. Pour ce faire, plusieurs niveaux de résolution sont identifiables : ldpi (basse résolution), mdpi (résolution moyenne), hdpi (haute résolution), xhdpi (très haute résolution) ou encore nodpi (utilisé pour empêcher la mise à l'échelle des images).
Exemple : permet d'optimiser l'utilisation des images en fonction des capacités de l'écran, ainsi il est inutile d'afficher une image haute résolution sur un écran qui ne la supporte pas. L'exemple le plus courant concerne les icônes des applications.
I-F. L'orientation de l'écran▲
Il est envisageable, voire conseillé, de définir des ressources spécifiques en fonction de l'orientation de l'écran lors de l'utilisation de l'applicatif développé. Pour ce faire, le développeur peut utiliser la caractéristique screen orientation avec pour possibilités land (mode paysage) et port (mode portrait).
Exemple : certains périphériques se prêtent à l'utilisation portrait ou paysage, il peut donc être intéressant de différencier le comportement des layouts pour améliorer l'expérience utilisateur.
I-G. Les contextes d'utilisation des terminaux▲
Un terminal Android peut définir son contexte d'utilisation pour choisir des ressources particulières en fonction de la manière dont il est utilisé. Le terminal utilise des capteurs pour déterminer le contexte actuel. Ces contextes sont au nombre de trois : le premier étant le mode normal , le second est le mode voiture, qui s'active lors de la pose du terminal sur un support de type voiture, et le dernier, le mode bureau lorsque l'on utilise un support de bureau ( car et desk ).
Exemple : l'application Home d'Android présente des modes différents avec, par exemple, dans le cas du support voiture un accès simplifié à la navigation, la musique, le bluetooth ou la reconnaissance vocale.
Dans le cas du mode bureau, les informations sur l'heure, les éphémérides ou encore la météo sont affichées en permanence.
I-H. Les critères de situation temporelle▲
Les modes diurne et nocturne peuvent également être spécifiés ( night / notnight ). Ils s'activeront manuellement ou automatiquement dans le cas où l'utilisateur est en mode voiture en fonction de l'heure du téléphone.
Exemple : imaginons un changement des couleurs de l'interface de l'écran pour éviter l'éblouissement du conducteur.
I-I. Les types d'écrans tactiles▲
Deux types d'écrans tactiles sont identifiables au niveau de la spécification des ressources. Il s'agit des écrans résistifs à stylets, identifiés par le terme stylus , et des écrans, généralement capacitifs, utilisables au travers des doigts, identifiés par le terme finger . Les ressources à mettre en oeuvre dans le cas de terminaux dépourvus d'écran tactile peuvent être répertoriées dans le dossier notouch .
Exemple : d'une importance capitale pour l'expérience utilisateur, il faut par exemple prendre en compte la taille des doigts pour les interfaces qui se pilotent au doigt, alors que les stylets permettront des zones tactiles plus petites et laisseront plus de place pour les contenus.
I-J. Présence d'un clavier physique et son état▲
Nous pouvons d'une part, caractériser la présence d'un clavier physique keyssoft sur le périphérique, mais également son état qui peut évoluer au cours de la vie de l'application keysexposed et keyshidden .
Exemple : lorsque le clavier physique est caché, il faut penser que le clavier virtuel vient recouvrir une bonne partie de l'interface utilisateur.
I-K. Type de clavier physique▲
Aucun avec nokeys , qwerty pour les claviers complets, 12key pour les claviers numériques.
I-L. Type des touches de navigation▲
Lorsque le téléphone n'a pas de touche de navigation, le critère est nonav . Dans le cas contraire, le périphérique de navigation peut prendre aujourd'hui plusieurs formes. Pad directionnel à quatre touches avec dpad , roulette avec wheel pour un défilement, boule roulante équivalente au dpad , mais moins encombrant sur le périphérique avec trackball .
Exemple : essentiel pour les jeux, le périphérique de navigation permet la plupart du temps de diriger le personnage principal du jeu. Donc s'il n'y en a pas, il doit être remplacé par un joystick virtuel (affiché à l'écran par exemple). S'il est présent, l'interprétation des actions utilisateur doit être différente pour un pad ou un trackball si un personnage se déplace à l'écran.
I-M. État des touches de navigation▲
Comme pour le clavier, le système de navigation peut être caché derrière un clapet ou autre, nous avons donc les critères navexposed et navhidden .
I-N. La version du système▲
Il est envisageable de prendre en considération le système en termes de version API, au travers de dossiers spécifiques (comme v4 à partir d'Android 1.6).
Exemple : permet d'éviter l'utilisation de widgets dépréciés ou même d'améliorer l'interface avec de nouveaux widgets fournis par les nouvelles versions du SDK.
II. Ressources Android▲
Dans le but de créer une homogénéité sur certaines parties des applications, la bibliothèque jar Android embarque un certain nombre de ressources qui peuvent être utilisées dans les applications. Nous accédons aux identifiants de ces ressources par la classe android.R. , suivie des types que nous avons vus ci-dessus.
Dans ces ressources, sont définis des comportements standard, comme les animations de fondu entrant ou sortant ( android.R.anim.fade_in et android.R.anim.fade_out ), des constantes, comme la durée des animations, les dimensions des vignettes et des icônes du système.
On trouvera également des images, comme les icônes de menu pour les actions standard : ajouter, supprimer, partager, recherche.
Enfin, toujours dans le but d'homogénéiser le développement, des layouts sont proposés comme, par exemple, les éléments simples des listes sur une ou deux lignes. Dans l'exemple 5-9 de ce chapitre, Ressources Android , nous utilisons des icônes de menu et un layout pour une liste à choix unique.
III. Ressources non structurées▲
Dans ce dossier, nous pouvons mettre tout ce qui n'est pas supporté par les ressources structurées, par exemple un fichier texte, un fichier définissant un objet 3D ou encore un fichier dans un format propriétaire.
III-A. Utilisation▲
Ces ressources sont accessibles grâce à la classe AssetManager . Elles sont ensuite lues sous la forme de flux à décoder selon le format du fichier. Pour la lecture d'un fichier texte, dans l'exemple 5-10, Ressources nonstructurées , nous obtenons le code qui suit.
Exemple 5-18. Récupération et décodage d'une ressource de type texte
// Récupération de la ressource
InputStream is = getAssets().open("licence.txt");
// Récupération de la taille de la ressource
int size = is.available();
// lecture de la ressource.
byte[] buffer = new byte[size];
is.read(buffer);
is.close();
// Conversion en String.
String text = new String(buffer);
// Affichage TextView tv = (TextView)findViewById(R.id.licence);
tv.setText(text);Par contre, il faudra faire attention à la taille des fichiers car AssetManager limite la lecture à 1 Mo.
IV. Création d'une bibliothèque de ressources▲
Pour améliorer la réutilisation des ressources développées, depuis la version 0.9.6 du plugin eclipse ADT , nous pouvons créer des ressources dans des projets externes. Ceci permet aussi de développer ses propres composants réutilisables. L'exemple 8, Bibliothèque de ressources , présente cette pratique en mettant en oeuvre une activité ressource dans le fichier AndroidManifest.xml présenté à l'exemple 5-20. Une fois le
projet de ressources créé (dans notre cas RessourcesDigitBooks ), nous devons spécifier dans les propriétés du projet qu'il s'agit d'une bibliothèque.
Ensuite, dans notre projet d'application, nous ajoutons la bibliothèque, ainsi que le dossier src , comme dossier source dans le build path .
Concernant l'accès aux ressources, il n'y a aucun changement puisque les classes R du projet et de ces bibliothèques sont fusionnées. Ainsi, il faut penser que le projet d'application écrasera toutes les valeurs de ressources si elles sont écrites en double.
Nous pouvons d'ailleurs définir l'ordre des projets de ressources pour gérer leur écrasement. Pour le code Java, il faudra importer les classes depuis le package de la bibliothèque.
Exemple 5-19. Utilisation d'une activité définie dans les ressources
<activity android:name="fr.digitbooks.android.ressources. RessourcesActivity" />Ces cinq premiers chapitres terminés, nous sommes désormais armés pour réaliser les interfaces de différents types d'applications tout en supportant la variété infinie des périphériques Android. Nous allons donc maintenant aborder des parties du SDK plus fonctionnelles, comme le stockage, les appels de web services ou communications réseaux, la 3D ou encore le développement de code natif.