Système d’Exploitation Mobile: Modèle de Programmation

Maps.

- Le répertoire « docs » contient la documentation HTML d’Android. Il s’agit exactement du site

http://developer.android.com .

4

- Le répertoire « samples » (sous-répertoire de docs) regroupe quelques exemples de code dont il est fait

référence par endroits dans la documentation.

II.1 Plug-in Eclipse

Les outils

Les outils Android sont localisés dans le répertoire « tools » du SDK. Si le développement se fait avec le plug-in Eclipse, la majorité de ces utilitaires s’utiliseront de façon transparente sans même que le programmeur ne s’en rende compte. La génération des objets ressources, la transformation des classes java en classes Dalvik (format dex), la création du package apk puis son déploiement sur l’émulateur se font par exemple simplement en lançant l’application depuis Eclipse.

L’émulateur Android : AVD

L’émulateur se lance par la commande « emulator ». Celle-ci prend en paramètre l’image AVD (Android Virtual Device) qui sera montée en mémoire. Il est donc possible de préparer et de conserver de multiples images qui sont autant de téléphones virtuels, ce qui est très commode pour les tests. La commande accepte un nombre important d’options qui permettent de spécifier des images ou de simuler la présence de sdcard. Il est possible de lancer plusieurs émulateurs en même temps, ce qui est utile pour tester des applications faisant interagir deux combinés entre eux. Toutefois, aucune communication ne peut se faire directement d’émulateur à émulateur sans une configuration préalable car ils sont isolés derrière un routeur pare-feu virtuel. Chaque émulateur écoute un port dont le numéro apparaît sur la barre de la fenêtre. Par Telnet on peut se connecter ainsi à la console de l’émulateur et exécuter certaines opérations de configuration.

Par exemple : telnet localhost 5554

Il n’est pas possible de décrire ici toutes les possibilités qu’offre l’émulateur tant elles sont nombreuses. En outre, généralement, on n’a besoin que ponctuellement de se servir de ces options. : Dans ces cas précis heureusement, http://developer.android.com/guide/developing/tools/emulator.html

la documentation de Google est exhaustive

aapt

La commande « aapt », qui signifie Android Asset Packaging Tool, sert à manipuler les packages des applications Android, fichiers ayant pour extension apk. Les fichiers apk comme les fichiers standard jar (Java ARchive) sont des fichiers compressés qui regroupent l’ensemble des éléments constituant le programme.

Le rôle majeur d’« aapt » est de compiler les ressources des applications Android. Cette opération consiste à transformer certains artefacts qui ne sont pas des fichiers sources Java, par exemple des fichiers xml décrivant des animations, dans leur équivalent binaire (fichiers « class » de bytecode).

Comme la plupart des commandes Android, l’exécution de cette commande se fait automatiquement par le plug-in Eclipse.

aidl

« aidl » (Android Interface Definition Language) prend en entrée un fichier de description d’interface (dans le format aidl donc, qui est propriétaire à Android) et génère en sortie les fichiers sources Java qui serviront à la fois au client de l’interface décrite et à la construction de l’implémentation de cette même interface.

5

adb

Grâce à la commande « adb » (Android Debug Bridge), on peut communiquer avec le terminal pour lui envoyer des instructions. « adb » fonctionne selon un modèle client/serveur. Les émulateurs, comme on le sait maintenant, ouvrent un port de connexion Telnet (par défaut le 5554) ; en réalité ils en ouvrent aussi un deuxième (par défaut le 5555) pour la communication avec adb. Il est à remarquer qu’adb fonctionne aussi avec les vrais téléphones.

Pour ce qui est du détail des commandes, là aussi, le choix est vaste :

• « adb install », suivi du fichier apk, déploie l’application packagée. • « adb pull » et « adb push » copie un fichier depuis et vers l’émulateur (ou le téléphone).

• « adb shell » initie une connexion shell sur le terminal grâce à laquelle on pourra exécuter directement sur le système Android les commandes localisées dans le répertoire /system/bin du téléphone. Ce répertoire contient, parmi d’autres, le client sqlite3 qui sert à consulter les bases SQL locales ou monkey qui génère des événements utilisateurs comme les clics ou les mouvements tactiles sur l’écran.

Enfin, avec adb, on peut visualiser les logs et contrôler leur production.

dx

Le but principal de dx est de prendre en entrée des classes au format bytecode JVM et d’en sortir des fichiers au format binaire dex (Dalvik Executable). L’exécution de la commande suivie de « –help » renseigne sur les options relativement nombreuses de l’outil. Certaines options servent à contrôler la manière dont les fichiers dex sont générés (avec ou sans optimisation, inclusion ou non des noms de variables locales...) et aussi à exécuter des tests junit.

apkbuilder

apkbuilder est la commande (elle-même écrite en java) à utiliser pour générer les package apk Android. C’est la dernière étape nécessaire avant de pouvoir déployer son application sur le terminal. En paramètre de cette commande, il faut indiquer les chemins vers les fichiers (ressources, dex...) qui seront assemblés pour créer le package. Cette commande est aussi capable de signer le package avec une clé de test (debug key), ce qui est exigé pour pouvoir installer l’application sur l’émulateur. Par contre, pour distribuer l’application finale, il faudra la signer avec une clé privée classique et cela ne se fera pas avec apkbuilder mais avec la commande jarsigner du JDK.

sqlite3

Il s’agit de la commande sqlite normale dont la documentation officielle se trouve à l’adresse : http://www.sqlite.org/sqlite.html

L’objet de sqlite3 est d’exécuter des commandes d’administration sqlite3 et même des requêtes SQL sur une base de données spécifiées en argument. Il s’agit bien sûr d’une base sqlite locale au téléphone et non d’une base distante hébergée sur un serveur. Le nom de la base se précise par le nom du fichier de stockage.

Pour utiliser sqlite3, il faut préalablement avoir ouvert un « remote shell » sur un émulateur ou sur un véritablement téléphone (adb shell).

6

III. DÉVELOPPER, EXÉCUTER & DÉBUGGER

III.1 Installation

Pour commencer à développer, il faut s’équiper :

• Le JDK, on peut le trouver là

http://www.oracle.com/technetwork/java/javase/downloads/index.htmlla documentation Javadoc mérite aussi d’être téléchargée.

• Le SDK Android, http://developer.android.com/ • L’IDE :

• Android Studio, est l’IDE officiel supporté par Google,

http://developer.android.com/sdk/index.html

• Eclipse ou ADT, le simple bundle « Eclipse IDE for Java Developers » suffit,

http://www.eclipse.org/downloads/ en lui ajoutant Le plug-in Eclipse d’Android (ADT).

Le SDK Android peut être sous format d’exécutable ou un fichier zip, qu’il convient de décompresser.

Notons qu’il vaut mieux développer avec Android Studio vu les avantages qu’il présente par rapport à ADT.

III.2 Dalvik Debug Monitor Service (DDMS)

Le SDK Android vient avec un outil de débogage nommé DDMS (Dalvik Debug Monitor Service).

Cet outil peut se lancer par le batch ddms.bat, il fonctionnera alors de façon autonome. Il peut aussi

s’utiliser au travers d’Eclipse et de la perspective DDMS.

DDMS est très complet et présente à l’utilisateur de nombreuses informations d’introspection sur

la machine virtuelle Dalvik :

• la liste des threads et leur état,

• l’activité du Garbage Collector,

• l’ensemble des logs du système...

En outre, DDMS, qui s’appuie également sur adb, est capable de piloter le terminal ou le téléphone pour

simuler des appels téléphoniques entrants, la réception de SMS ou déterminer la position GPS du

terminal. DDMS est en fait le compagnon graphique des outils Android, indispensable en phase de

développement.

Notons qu’à partir de SDK 5.0 (Lollipop) API 21, Delvik a été remplacé par ART (Android

RunTime)

IV.

STRUCTURE D’UN PROJET

La structure d’un projet Android répond à des règles bien précises. Le meilleur moyen pour les

7

appréhender est de commencer par créer un projet de test à l’aide de l’IDE . Nous verrons la structure de

projet avec les deux IDE : Android Studio et ADT

Avec Android Studio :

Le menu Eclipse « File/New Project. » amène à la boîte de dialogue depuis laquelle l’assistant de création

de projet Android est accessible.

• Les champs « Application name » et « Package name »: il s’agit simplement du nom du projet et du

package Java racine de l’application.

8

On aura le choix des devices (SmartPhone & Tablette, TV, Glass, ), ainsi que la version SDK minimale

Le concept d’Activité est très important dans Android et il convient de parfaitement

9

l’appréhender. Cette notion est la base de l’extraordinaire capacité de coopération des applications.

une Activité pourrait être définie comme le point d’entrée, équivalent de la classe contenant la méthode static main, d’une application Java de base. L’activité est aussi le point d’ancrage, où est défini le contenu visuel de l’écran.

Le champ « Activity name » est typique à Android.

Une fois créé, le projet possède la structure arborescente suivante :

10

Avec Eclipse ADT:

Le menu Eclipse « File/New/Other... » amène à la boîte de dialogue depuis laquelle l’assistant de création de projet Android est accessible.

• • • • • • • • • •

11

• Les champs « Project name » et « Package name »: il s’agit simplement du nom du projet

Eclipse et du package Java racine de l’application. • Le champ « Activity name » est typique à Android.

Une fois créé, le projet possède la structure arborescente suivante :

12

IV.1 Le manifest

Le fichier AndroidManifest.xml est, comme son nom l’indique, le fichier manifeste d’Android au format xml.

Fichier manifest

Un manifeste est un petit fichier qui contient des informations sur l’application ou la librairie à laquelle il appartient. Il regroupe ainsi des métadonnées dans un fichier au format xml.

13

Ce fichier regroupe les éléments de configuration de l’application. Il est à Android ce que le web.xml est aux applications web Java. Avec Android Studio, on modifie directement sur le contenu XML. Avec ADT, l peut se modifier en double-cliquant sur le fichier depuis la vue « Package Explorer », la fenêtre suivante apparaît :

Cette fenêtre sert à éditer le fichier manifeste de façon graphique. Les données sont subdivisées en quatre catégories :

• Manifest • Application • Permissions • Instrumentation (ce dernier onglet présente la vue xml du fichier).

Certaines propriétés peuvent être renseignées directement dans le champ de texte correspondant de la fenêtre de l’éditeur de manifeste. Par exemple, sur l’onglet « Application », le champ label peut être rempli librement. D’autres, au contraire, doivent forcément être valorisées au travers d’un fichier de ressources. Toujours dans le même onglet, la propriété description, par exemple, doit obligatoirement faire référence à une entrée dans un fichier de ressources (pseudo-fichier properties). Enfin certaines pointent vers un fichier de ressource comme l’attribut « icon » de l’application qui fait référence à une image placée dans le répertoire res/drawable.

Pour s’assurer de correctement éditer le fichier AndroidManifest.xml, il est donc préférable de se servir de l’assistant.

14

Manifest

Les principaux champs à saisir concernent les paramètres globaux de l’application : dans le fichier xml, cela représente le tag racine « manifest ».

Nom du champ Package

Description Le nom du package racine de l’application. Il identifie unitairement l’application. Cette valeur suit les règles de nommage des packages Java : seuls les caractères de type lettre ASCII en minuscules sont valables. Pour s’affranchir des problèmes de collisions de noms, la pratique veut que le début du package commence par le nom de domaine inversé de l’organisation responsable de l’application.Ex : tn.rnu.isi…

Version code

Le « Version code » est un entier représentant la version de l’application. Ce champ est important car c’est celui qui permet de comparer deux versions d’un même logiciel et de déterminer ainsi si une mise à jour est nécessaire. L’évolution de ce champ est par contre libre, on peut imaginer qu’il soit incrémenté à chaque livraison de l’application mais il n’y a aucune obligation, sa progression n’est pas tenue d’être linéaire.

Version name

Shared user id

Ce champ est libre, et peut prendre n’importe quelle valeur de type String. Il s’agit de la version du logiciel affichée à l’utilisateur. Cela peut correspondre à la version commerciale ; contrairement au code de version, ce champ n’a pas d’incidence technique.

Ce champ facultatif est l’équivalent du compte utilisateur Linux avec lequel sera exécutée l’application. S’il est omis, Android attribue automatique un « user id » unique à chaque application afin d’obtenir un bon niveau de sécurité et de les isoler les unes des autres. Par contre, si deux applications ont le même « Shared user id », elles pourront partager les données. Pour cela, il faut, en plus de définir la même valeur pour cette entrée, qu’elles aient été signées avec le même certificat. Posséder un « Shared user id » identique est la condition préalable pour configurer deux applications à tourner dans le même processus Linux VM Dalvik.

Application

L’onglet « Application » gère graphiquement l’édition du tag « application » et de ses sous-éléments correspondant au paramétrage des « Application Nodes ». Dans le fichier xml, le tag « application » est lui-même un sous-élément de « manifest »

Nom du champ Application Toggle

Description Cliquer sur cette case à cocher, supprime le tag « application » du fichier xml ainsi que tous ses sous éléments. Cela a pour effet de désactiver toutes les options de paramétrage renseignées dans cet onglet.

Ce champ optionnel renseigne le nom de la sous-classe d’an-droid.app.Application que l’on souhaite utiliser. La classe Application, ou donc une sous-classe que l’on aurait soi-même créée, est automati- quement instanciée au démarrage. Cette classe permet de stocker les variables globales du programme à la façon de l’« application context » des webapp java. Définit le thème visuel (skin) de l’application. Le thème peut être redéfini précisément pour chacune des activités constituant l’application. Le thème est en quelque sorte l’équivalent du PLAF (Pluggable Look and Feel) de Java Swing.

Il s’agit juste du nom de l’application. Ce nom sera celui affiché à l’utilisateur. L’icône de l’application. Le fichier ressource image référencé doit bien sûr exister. Ce champ, comme le label, est purement informatif : il décrit en détail l’application. Ici sont listées les permissions qui devront être accordées à l’application pour fonctionner correctement. Par exemple si une application nécessite d’effectuer des requêtes sur Internet, il faudra déclarer la permission qui a pour nom : « android.permission.INTERNET ».

Le nom du processus Linux sous lequel tourneront les composants (les objets Activity, Service, BroadcastReceiver, ContentProvider) de l’application. Par défaut, il s’agit de la valeur du champ « Package » de l’onglet « Manifest ». Si cette valeur n’est pas redéfinie au niveau du composant, ces derniers seront tous exécutés dans le même processus. Dans le cas contraire, ils pourront être isolés en étant portés par des processus différents. Il est aussi possible de mutualiser un même processus entre plusieurs composants issus de plusieurs applications. Pour cela, la valeur de l’attribut « Process » doit être bien entendu la même mais ils doivent aussi partager le même utilisateur Linux, c’est-à-dire avoir le même « Shared user id ». Si le nom du processus commence par « : », ce processus sera privé à l’application et ne pourra en aucun cas être partagé avec d’autres composants d’autres applications.

Name

Theme

Label Icon Description Permission

Process

15

Task affinity

La notion de Task dans Android doit être appréhendée sous l’angle de vue purement utilisateur et non selon une perspective technique. Une « Task » représente une pile d’activités, c’est-à-dire d’écrans, ordonnée à la manière d’un historique de navigation web. L’attribut affinité, indique dans quelle pile les écrans (les activités) sont destinés à être rangés. Si l’attribut est défini au niveau de l’application alors toutes les activités de celle-ci hériteront de cette valeur, ce qui signifie qu’elles seront conçues pour être classées dans la même pile d’historique. Cet attribut peut aussi être individuellement défini ou redéfini sur l’activité ce qui signifie que les activités d’une application ne seront pas forcément classées dans la même task.

Allow task reparenting

Valeur « true » ou « false ». Cet attribut est à rapprocher de « task affi-nity », il concerne également la notion de task. Il s’agit ici de renseigner si l’activité pourra être déplacée de la « task » de l’activité précédente ayant lancé la nouvelle activité vers la « task » correspondant à son affinity.

Has code

Persistent

Enabled

Debuggable

Valeur booléenne qui détermine si le système doit essayer de charger du code en mémoire au moment du lancement des composants de l’application. En d’autres termes, si « Has code » égale « false », cela veut dire que l’application ne contient aucun code binaire à exécuter ! Cela peut sembler étrange de déployer une application vide : qu’on se rassure, la valeur par défaut de « Has code » est « true », mais il existe un mécanisme par lequel on peut déclarer dans une application, une activité comme étant un alias d’une autre activité provenant d’une autre application. Booléen indiquant si l’application doit tourner en permanence. La valeur par défaut est « false ». Il est préférable, en effet, de laisser le système démarrer et stopper les processus Linux. La VM Dalvik est prévue pour pouvoir se lancer très rapidement, de plus une application permanente consomme inévitablement des ressources système. En conclusion, à moins d’avoir une raison bien particulière, il vaut mieux ne pas positionner ce champ à vrai. Active (« true » valeur par défaut) ou désactive (« false ») les composants de l’application. Chaque composant pourra, au niveau de ses propres propriétés, définir l’attribut « enabled ». Un composant ne sera considéré comme actif que si sa propre propriété « enabled » vaut true ainsi que celle plus globale de l’application. La notion de composant est décrite dans un autre chapitre. Les valeurs possibles sont « true » ou « false » (par défaut). Ce champ autorise ou non de déboguer l’application (positionner des points d’arrêt, faire du pas à pas dans le code, inspecter les valeurs des variables...). Le débogage est possible aussi bien depuis l’émulateur que depuis un vrai téléphone.

Manage space activity

Le nom qualifié (avec le nom de package) de la classe de l’activité à afficher lorsque l’utilisateur voudra libérer la mémoire occupée par l’application. C’est par le programme « Application Manager », inclus de base dans Android, que cette activité sera lancée.

Allow clear user data

Prend la valeur « true » (valeur par défaut) ou « false ». Indique si oui ou non, l’utilisateur peut effacer les données de l’application à l’aide de l’« Application Manager ». Le gestionnaire d’applications est un programme accessible directement depuis le téléphone grâce auquel on peut examiner les propriétés des applications installées, comme les permissions qu’elles requièrent ou l’espace de stockage utilisé, ou encore effacer leurs données quand cela est autorisé.

Application Nodes

Les « applications nodes » sont les composants centraux des applications. Il en existe de quatre types : Activity, Service, BroadcastReceiver et ContentProvider. Il convient ici de lister et de paramétrer ceux faisant partie de l’application. Ces composants sont étudiés en profondeur dans d’autres chapitres.

Permissions

16

Sur l’onglet Application, il était possible de définir une et une seule permission requise par le programme. Ici, sur cet onglet consacré uniquement à ce sujet, on peut définir plusieurs permissions requises par l’application grâce à l’élément uses-permission.

Mais on peut aussi faire l’inverse, c’est-à-dire déclarer les permissions qui devront avoir été accordées aux autres applications qui voudront interagir avec l’application du manifeste (élément permission).

Instrumentation

Cet onglet permet d’installer et de configurer des éléments d’instrumentation dans l’application (tag xml « instrumentation »). C’est grâce aux instrumentations qu’on peut dérouler des tests unitaires réalisés avec le framework JUnit

17

Nom du champ Name

classe

Description Le nom (« fully qualified ») de la classe d’instrumentation que l’on souhaite installer dans l’application. Cette android.app.Instrumentation. étendre InstrumentationTestRunner est une spécialisation de la classe de base Instrumentation dédiée aux compagnes de tests. Plusieurs classes d’instrumentation peuvent être ajoutées à l’application. Si ce nom commence par un point « . », alors le nom de l’application, attribut Package du tag « manifest », servira de préfixe pour obtenir le nom qualifié de la classe à instancier.

nécessairement

classe

doit

la

Target package

Label Icon

Ce champ contient l’id de l’application sur laquelle appliquer l’instrumentation courant. Pour rappel, l’id d’une application est son package racine. Un simple label permettant d’identifier visuellement l’instrumentation. Une image référençant l’instrumentation. L’icône, comme le label, ne sert que de repère visuel.

Handle profiling

Indique si la classe d’instrumentation aura la main sur l’activation ou non du profiling.

Functional test

Ce booléen, s’il prend la valeur vrai, notifie que le test représenté par l’instrumentation est un test fonctionnel. Il aura donc besoin d’un contexte Android complet et conforme à celui obtenu lorsque l’application est exécutée normalement. Via les composants d’instrumentation, il est alors possible de générer des événements utilisateurs et de contrôler les réponses des éléments d’IHM.

Notons qu’avec Android Studio, certaines propriétés qui figuraient dans AndroidManifest.xml compileSdkVersion, applicationId, minSdkVersion, targetSdkVersion, versionCode et versionName figurent désormais dans le fichier build.gradle

Les métadonnées

Des valeurs de paramètres de quelque nature qu’elles soient peuvent être transmises aux composants via la balise <meta-data>. Elles sont ensuite récupérées dans le code un peu comme les paramètres applicatifs des servlets configurés dans le web.xml.

IV.2 Les ressources

Les ressources sont des éléments constituant l’application, hormis le code source lui-même. Il peut s’agir de fichiers image, vidéo, du texte... Il y a deux grandes familles de ressources, chacune ayant son propre répertoire de stockage au sein des applications Android : « res » et « assets ». « res » abritera les ressources typées et référencées par Android alors que le dossier « assets » accueillera les fichiers bruts qui seront lus sous forme de flux d’octets indifféremment de la nature même de leur contenu.

Les ressources « res »

Les ressources « res » sont disposées dans des sous-répertoires de « res » en fonction de leur type. Ces ressources sont référencées dans la classe spéciale R. Cela veut dire que cette fameuse classe définira des constantes de type int permettant l’identification de chacune de ces ressources. Ces ID sont utiles à de nombreux endroits dans l’API Android. Ces ressources sont également typées : en effet leur ventilation dans les sous-répertoires se fait très précisément. La raison de cette façon de faire est que lors du processus de packaging de l’application, les ressources sont transformées en binaire pour des questions d’optimisation. Un fichier jpg sera par exemple compilé en un objet Drawable. Il convient donc de bien catégoriser les ressources. Par défaut, l’assistant de création de projet Android d’Eclipse crée trois dossiers « res » prêts à accueillir les ressources les plus fréquemment employées :

• res/drawable - Ce dossier stocke les images jpg, png et même gif (format néanmoins obsolète

18

qu’il est préférable d’éviter). Ces images deviendront donc des Drawable et pourront être affichées à l’écran.

• res/layout - Ce répertoire contient les fichiers xml décrivant l’agencement de l’IHM : la

disposition des widgets, leur taille, style à appliquer...

• res/values - Ce répertoire héberge toutes les ressources exprimées textuellement sous forme de fichier xml. Ces ressources peuvent toutes être déclarées dans un seul et même fichier ou réparties selon un découpage libre dans plusieurs fichiers xml. La convention cependant dicte plutôt de rassembler dans un même fichier les ressources de même catégorie, ce fichier portant le nom de la catégorie. Par exemple, les simples chaînes de caractères devraient toutes être dans le fichier « strings.xml », les thèmes dans « style.xml »,...

En plus de ces trois répertoires créés par le plug-in Eclipse, il est possible d’en rajouter d’autres qui contiendront d’autres types de ressource :

• res/anim - Android offre un

langage d’animation minimaliste au format xml. Ce

répertoire est le lieu où il convient de les stocker.

• res/menu - Les menus de l’application, qu’il s’agisse des menus d’options (affichés lorsqu’on presse le bouton MENU) ou contextuels (en l’absence de clic droit, ils apparaissent suite à un clic tenu de plusieurs secondes), peuvent se déclarer par des fichiers xml mis dans le répertoire « res/menu »..

• res/xml - C’est le répertoire pour placer les fichiers xml applicatifs dont le format n’est pas connu d’Android. Ces fichiers seront lus dans le code de l’application au travers de l’objet XmlResourceParser obtenu par la méthode Resources.getXml(int id). L’objet Resource sera lui- même récupéré à partir de l’objet Context. XmlResourceParser est un parseur de type XMLPull : cette nouvelle famille de parseurs tente de faire la synthèse de ce qu’il y a de meilleur dans les parseurs SAX et DOM. En effet, ces nouveaux parseurs ont une faible empreinte mémoire et sont capables de parcourir des fichiers très volumineux tout en exposant une API élégante et pratique pour le développeur.

• res/raw - Les fichiers contenus dans le sous-répertoire « raw » ne seront pas compilés mais se retrouveront tels quels dans le package apk. Ces fichiers seront lus par l’interface InputStream obtenue par Resources.openRawResource(int id). En somme, ces ressources ont un mode opératoire assez similaire aux « assets » à la différence notable que les fichiers « res/raw » ont un identifiant répertorié dans la classe R.

Les ressources « assets »

Les éléments de type « assets » (signifie en anglais « actif », comme une machine outil fait partie des « actifs » d’une entreprise) ne sont pas traités par les outils de package d’Android : ils seront copiés sans transformation sur le terminal au moment du déploiement et n’auront pas de constante int dans la classe R les identifiant.

La lecture du contenu des fichiers se fait grâce à l’objet AssetManager qui, en lui soumettant le nom du fichier par la méthode open, renvoie un InputStream. Pour obtenir une référence vers l’objet AssetManager de l’application, il faut appeler Context.getAssets().

La classe R

La classe R, ‘R’ comme « Resources », est une classe générée au moment de la création du fichier .apk, qui est le fichier de l’application packagée, par l’utilitaire aapt (Android Asset Packaging Tool) qui se trouve comme les autres utilitaires dans le répertoire « tools » du SDK Android.

Ceux qui feront le choix d’Eclipse peuvent se rassurer : le plug-in regénère automatiquement la classe R dès que des changements sur le projet le nécessitent, c’est-à-dire dès que des modifications, suppressions ou ajouts sont apportés aux fichiers présents dans les sous-répertoires de « res ». Les ressources positionnées dans le dossier « assets » ne sont pas concernées car elles ne sont pas référencées par Android.

Voici le genre de contenu que la classe R pourra avoir :

19

/* AUTO-GENERATED FILE. DO NOT MODIFY. * * This class was automatically generated by the * aapt tool from the resource data it found. It * should not be modified by hand. */

package tn.rnu.isi.ssice.helloworld; public final class R{ public static final class array { public static final int saisons=0x7f040000; } public static final class attr { } public static final class drawable { public static final int gallery1=0x7f020000; public static final int gallery10=0x7f020001; public static final int gallery2=0x7f020002; public static final int gallery3=0x7f020003; public static final int gallery4=0x7f020004; public static final int gallery5=0x7f020005; public static final int gallery6=0x7f020006; public static final int gallery7=0x7f020007; public static final int gallery8=0x7f020008; public static final int gallery9=0x7f020009; public static final int icon=0x7f02000a; public static final int logo=0x7f02000b; } public static final class id { public static final int CancelButton=0x7f060002; public static final int bold_cb=0x7f060005; public static final int clock=0x7f060007; public static final int color=0x7f06000e; public static final int gallery=0x7f06000b; public static final int image=0x7f06000c; public static final int italic_cb=0x7f060006; public static final int okButton=0x7f060001; public static final int option1=0x7f06000f; public static final int option2=0x7f060010; public static final int option3=0x7f060011; public static final int option4=0x7f060012; public static final int password=0x7f06000a; public static final int phoneNumber=0x7f060009; public static final int plain_cb=0x7f060003; public static final int progress=0x7f06000d; public static final int saisons=0x7f060013; public static final int serif_cb=0x7f060004; public static final int time=0x7f060014; public static final int title=0x7f060008; public static final int toggle1=0x7f060015; public static final int toggle2=0x7f060016; public static final int voiture=0x7f060000; } public static final class layout { public static final int analog_clock=0x7f030000; public static final int auto_complete_text_view=0x7f030001; public static final int buttons=0x7f030002; public static final int check_boxes=0x7f030003; public static final int date_picker=0x7f030004; public static final int digital_clock=0x7f030005; public static final int edit_texts=0x7f030006;

20

public static final int gallery=0x7f030007; } public static final class string { public static final int app_name=0x7f050001; public static final int hello=0x7f050000; public static final int prompt=0x7f050002; }

La classe R est frappée du modificateur « final », elle ne peut donc pas être étendue. Rien d’étonnant à cela, sa raison d’être étant simplement de regrouper les identifiants des ressources du projet, cette classe ne définit aucune méthode ni aucun attribut. Par contre, la classe R déclare des classes internes statiques et finales comme « drawable », « id », « layout »...

Ce sont ces classes qui encapsulent véritablement les constantes de type int. Les règles de codage Java stipulent que le nom des classes doit commencer par une lettre majuscule ce qui n’est pas le cas ici parce que le pattern de programmation utilisé ici cherche uniquement à regrouper les constantes selon leur catégorie.

Utilisation des ressources

Dans le code Java, c’est très simple : l’API Android accepte partout où les ressources pourraient être employées le moyen d’y faire référence en spécifiant un paramètre de type int qui ne saurait être autre chose que les