Tutoriel Android : premiers pas avec le SDK de Google Android

Avant d'expliquer les interfaces graphiques, nous présentons de manière succincte les notions fondamentales d'une application Android.

Avant tout, il faut avoir en tête le principe de base de la programmation Android et ses composants principaux. Il y a quatre types d'éléments distincts :

• les activités (activities) : ce sont les programmes qui sont une activité pour l'utilisateur. Ils possèdent donc un GUI ;
• les fournisseurs de contenus (content provider) : ils offrent un niveau d'abstraction pour l'accès à toutes les données stockées sur le terminal. Il est encouragé d'ouvrir ces données aux autres applications. Les données sont identifiées au moyen d'URI (Unified Ressources Identifier) ;
• les services : ils ont une durée de vie infinie (contrairement aux activités et aux fournisseurs de données). Il faut les voir comme des démons qui tournent en tâche de fond ;
• les intentions (intents) : Ce sont des messages système qui servent de support événementiel pour permettre le dialogue entre applications. On répond et on envoie des intentions qui lancent ou communiquent avec les activités.

Une activité envoie des intentions au système qui identifie l'activité associée et soit la lance (startActivity), soit lui parle au moyen du BroadCastReceiver. Un BroadCastReceiver est une interface qui est implémentée par l'activité écoutante.

Une activité se lie à un service par la méthode Bind et soit interagit directement avec les méthodes du service, soit écoute les évènements envoyés par celui-ci.

Une activité peut demander, via un ContentResolver, au système d'effectuer une action CRUD sur des données identifiées par une URI. Le système trouve le ContentProvider qui gère ses données et lui demande d'effectuer l'action demandée. Le résultat de l'action est renvoyé à l'activité. Un service peut aussi utiliser ce mécanisme pour effectuer des actions CRUD sur des données.

Un projet possède la structure normalisée. Il y a deux types de fichiers, ceux que vous utilisez tout le temps, et ceux qui ne sont là que pour la compilation et le déploiement.

Les fichiers utilisés en permanence sont :

• le manifeste (AndroidManifest.xml) qui décrit l'application à construire et ses composants ;

• le dossier res (pour ressources) qui contient les ressources du projet (les layouts, les chaînes de caractères, les images, les fichiers internes, les fichiers XML, les couleurs et thèmes) dont les sous-dossiers sont :

  • Drawable (pour les images, usuellement vous trouverez trois dossiers, un par qualité haute, moyenne, faible),
  • Layout (pour la définition des différents fichiers de layouts des activités qui déclarent et positionnent les composants graphiques),
  • Values (pour les chaînes de caractères, les couleurs, les thèmes, les préférences…),
  • Raw (pour les fichiers),
  • XML (pour les fichiers XML) ;
• le dossier src pour les sources ;
• et enfin le dossier test pour les tests.
  Les fichiers utilisés pour la compilation et le déploiement sont :
• le fichier de build ant (build.xml) qui construit le projet ou son homologue maven ;
• les fichiers properties default et local qui sont utilisés par le build ;
• le dossier asset contient des fichiers pour le déploiement ;
• le dossier bin (pour binaries) qui contient les classes compilées ;
• le dossier gen (pour generated) qui contient le code source généré par les outils de compilation Android ;
• le dossier libs (pour librairies) qui contient les librairies.

Le fichier manifeste est un élément clef du projet, il définit :

• votre projet et sera interprété par le système et l'AndroidStore ;
• les dépendances système de votre projet (par exemple : la version du système, les instruments nécessaires, la géolocalisation) ;
• la version de votre projet (un nom de version name et un numéro de version (un Int)) ;
• les différents composants de votre application (Activity, Service, ContentProvider).

Comme Android a pour vocation de lancer votre application sur un ensemble d'appareils distincts, il est préconisé que vous mettiez en place l'arbre suivant au niveau de vos ressources :

• layout ;
• layout-small ;
• layout-normal ;
• layout-large ;
• layout-xlarge ;
• drawable ;
• drawable-ldpi ;
• drawable-mdpi ;
• drawable-hdpi ;
• values ;
• values-fr || values-en (si vos strings par défaut sont en anglais, mettez values-fr, sinon values-en).

Cet arbre vous permet d'avoir les layouts par défaut puis ceux spécifiques à chaque taille d'écran, vos images par défaut puis celles spécifiques à chaque densité d'écran et enfin vos chaînes de caractères par défaut puis celles anglaises (ou françaises si par défaut vos chaînes sont anglaises).

Il faut toujours mettre le dossier par défaut, car personne ne sait si lors de futures versions d'Android de nouveaux paramètres n'apparaîtront pas (xlarge est apparu à la version 9 du système).

Pour donner vie à ces propos, voici un exemple typique de structure de projet que nous pouvons avoir sous Android, une application permettant d'écouter des médias audio et/ou vidéo présents sur le téléphone :

Cette application est représentée :

• par trois activités qui sont :

  • WelcomeActivity : la page d'accueil de votre application,
  • BrowseActivity : la page vous permettant d'afficher les médias présents,
  • PlayerActivity : celle qui lira le média demandé ;

• par un service :

  • PlayserService : le service tournant en tâche de fond lisant le flux du média, ce qui nous permettra de ne pas être dépendant du thread UI ;

• par un BroadCast :

  • BroadCastReceiver : il nous permet de pouvoir échanger des informations entre le Service « PlayerService » et l'Activity « PlayerActivity » ;

• et enfin par un ContentProvider :

  • MediaStore : nous permet de pouvoir récupérer les informations sur les médias présents sur le téléphone .

Cet article a été publié avec l'aimable autorisation de la société Android2EE.

Nous tenons à remercier milkoseck pour sa relecture orthographique de cet article et Mickael Baron pour la mise au format Developpez.com.