Présentation du SDK Android

Le SDK d'Android

Environnement de développement

Un SDK, pour Software Development Kit est un ensemble d'outils logiciels permettant de faciliter le développement d'un logiciel sur une plateforme donnée (par exemple, il existe un SDK pour Android, un pour iOS, etc.)

Le SDK d'Android est multi-plateforme, et se compose d'un plugin s'intégrant à Eclipse et d'un émulateur, permettant de tester son application sur plusieurs versions différentes d'Android, plusieurs tailles d'écran, etc. et ce, même si on n'a pas d'appareil physique.

Un projet Android doit respecter une arborescence bien précise, comme on peut le voir sur l'image de droite.

Le dossier "src" est classique : il contient, comme pour tout projet Java, l'ensemble des sources du projet.

Le répertoire "gen" est, comme son nom l'indique, généré automatiquement par Eclipse. On y trouve un fichier "R.java", qui reprend l'ensemble des ressources du projet (les images, les éléments des interfaces graphiques, les valeurs contenues dans le dossier "values", etc.). Cela permet d'accéder, depuis le code, aux différents éléments disséminés dans les fichiers XML.

Le dossier "bin" est généré lors de la compilation et contient, entre autres, le fichier à installer sur le terminal. Ce fichier porte l'extension "apk", et correspond, pour faire l'analogie avec le monde Java, à un "jar" exécutable.

Le dossier "res" contient les ressources nécessaires à l'exécution de l'application. Ainsi, les différentes images sont placées dans les dossiers "drawable" (chaque dossier contient les mêmes images de taille différentes).
Le répertoire "layout" contient les fichiers XML définissant les interfaces graphiques ; nous y reviendrons dans la partie suivante.

Le dossier "values" peut contenir plusieurs fichiers XML déclarant certaines valeurs particulières. On peut y stocker des chaines de caractères, des dimensions, des couleurs, des tableaux, et y accéder simplement depuis le code ou l'interface graphique. Cela permet notamment d'internationaliser les applications de manière transparente dans le code source.

Enfin, le fichier "AndroidManifest.xml" situé à la racine du projet, permet de configurer l'installation de l'application sur les terminaux mobiles. Nous y reviendrons dans une prochaine partie.

Pour pouvoir stocker des données utilisateur, le développeur peut utiliser une base de données SQLLite, intégrée à chaque application Android. Cette base de données est légère et simple d'utilisation. Le fait qu'elle soit embarquée au sein de l'application améliore la sécurité : il n'est du coup pas possible qu'une autre application accède aux données stockées.

Interfaces graphiques

Nous l'avons vu dans la partie précédente, les interfaces graphiques sont définies dans des fichiers XML ; cela permet de bien séparer la vue du contrôleur.
Le plugin Eclipse, fourni par Google, permet au développeur de construire graphiquement son interface : il suffit ainsi de faire glisser les composants disponibles depuis la liste de gauche vers l'écran du téléphone. Cela génère le fichier XML situé à droite de l'image ci-dessous. Chaque composant possède différents attributs, et notamment un ID (qui sera utilisé pour retrouver le composant depuis le code de l'application).

Chaque composant possède différents attributs, et notamment un ID (qui sera utilisé pour retrouver le composant depuis le code de l'application).

Google fournit de base plusieurs composants différents, comme les champs textes classiques ou formatés (numéros de téléphones, adresses, nombres, etc.), des boutons, des listes, des champs heures et dates... Si cela ne suffit pas, il est aussi possible de créer ses propres composants pour personnaliser son application.

Les activités

Notre interface graphique est maintenant créée, mais comment l'afficher à l'écran ? C'est ici que le concept d'activité prend tout son sens. Ainsi, chaque écran de notre application correspond à une activité distincte. Il s'agit d'une classe héritant de "android.app.Activity", et contient la logique de l'activité, ainsi que l'interface graphique (définie soit directement dans le code, soit dans un fichier XML à part). Ci dessous, un code très simple permettant d'incrémenter un nombre grâce à un bouton :

Explication du code :

• setContentView(R.layout.listener) : cette méthode permet d'associer à l'activité l'interface créée dans le fichier listener.xml
• findViewById(R.id.*) : on peut, grâce à cette fonction, récupérer à l'aide de son identifiant un composant graphique défini dans le fichier XML de l'interface.
• setOnclickListener() : de la même manière qu'en Java, on peut ajouter des listeners sur les composants, permettant ainsi de réagir aux événements. Ici, on ajoute un écouteur sur le bouton "btn_increment" : au clic, on récupère la valeur contenue dans le champ texte "text_increment", et on remplace sa valeur par le même nombre incrémenté de 1.

Cycle de vie d'une activité

Android fonctionnant sur des appareils ayant de faibles ressources, il est nécessaire de mettre en place un mécanisme pour gérer les activités. Chacune d'entre elle a son propre cycle de vie, rythmé par des appels à des méthodes bien définies. L'image ci-contre, en provenance de Google, représente ce cycle.

Ces méthodes sont listées ci-dessous :

• onCreate() : l'activité se créé. C'est dans cette méthode qu'on définit l'interface graphique.
• onStart() : appelée lorsque l'activité démarre.
• onResume() : l'activité démarre ou sort de pause. C'est ici qu'on peut lancer ou relancer les différentes threads.
• onPause() : l'activité est suspendue, c'est à dire qu'une autre activité vient au premier plan, recouvrant en partie l'activité de notre application. Il faut stopper les traitements qui consomment beaucoup de ressources.
• onStop() : l'activité n'est plus visible et passe en arrière plan. Il faut libérer les écouteurs et arrêter les threads.
• onDestroy() : le cycle de vie de notre activité est terminé. On place dans cette méthode la fermeture des fichiers et le code de "nettoyage".

Seule la méthode onCreate() est obligatoire. Cependant, dès que la complexité des activités augmente (ouverture de fichiers, écouteurs sur des capteurs, etc.), il devient nécessaire d'implémenter les autres méthodes pour gérer finement les différents états de l'activité.

Un objet Bundle savedInstanceState est passé en paramètre aux méthodes onCreate, onStart et onResume. Cet objet représente l'instance sauvegardée de l'activité. Ainsi, lorsqu'on revient sur cette dernière (après une pause ou un arrêt) et si elle est toujours en mémoire, l'activité est dans le même état que lorsqu'on l'a quittée.

Bon à savoir : lorsque l'activité est en pause (partiellement visible) ou stoppée (plus visible du tout), elle peut être arrêtée par le système s'il doit libérer de la mémoire. Il est donc important que les données soient dans un état cohérent dès l'appel de la méthode onPause().

Le fichier AndroidManifest.xml

L'application est maintenant développée, il est temps de l'installer sur notre smartphone. Nous avons vu qu'une application Android est packagée dans un fichier "apk", qui est l'équivalent du fichier "jar" pour Java. Or dans un fichier jar, il y a un fichier manifest.xml qui définit la classe à exécuter au lancement du jar. Il en est de même pour un apk, qui contient un fichier AndroidManifest.xml.

Ce dernier, en plus de définir la classe principale, permet d'indiquer la version minimale d'Android à avoir pour installer l'application, les tailles d'écran supportées (on peut optimiser une interface pour des tablettes, et empêcher ainsi l'installation sur des téléphones), ou encore la version de l'application. On y indique aussi les permissions nécessaires pour faire fonctionner l'application. En effet, certaines fonctionnalités (accès aux données personnelles, à l'envoi de SMS, etc.) doivent obtenir l'accord de l'utilisateur avant toute installation.

L'exemple ci-dessus indique que le numéro de version du logiciel est 1.0 et qu'il est nécessaire de posséder au minimum la version 8 du SDK (qui correspond à Android 2.2). On y trouve aussi le nom de l'application et son logo (qui apparaîtra dans le menu principal d'Android). Les activités sont ensuite définies : la première, nommée "ExposeExampleActivity" est celle qui sera lancée au démarrage de l'application (cela se définit grâce à la balise <action android:name="android.intent.action.MAIN" />).

On constate que cette application ne nécessite aucune permission particulière. Néanmoins, si on avait voulu utiliser l'appareil photo, il aurait été nécessaire de rajouter les lignes suivantes à notre fichier :

<uses-permission android:name="android.permission.CAMERA" ></uses-permission>
<uses-feature android:name="android.hardware.camera"/>
<uses-feature android:name="android.hardware.camera.autofocus"/>

---