Activités et ressources Android (PDF)

Summary

Ce document décrit les concepts clés nécessaires au développement d'applications Android, en mettant l'accent sur les activités, les vues et contrôles, et les ressources.

Full Transcript

Chapitre3 Activités et ressources 3.1 Introduction Dans ce chapitre, nous nous intéressons aux différents concepts nécessaires à la création d’une application Android et nous détaillons ceux d’activités et de ressources. 3.2 Définitions Une application...

Chapitre3 Activités et ressources 3.1 Introduction Dans ce chapitre, nous nous intéressons aux différents concepts nécessaires à la création d’une application Android et nous détaillons ceux d’activités et de ressources. 3.2 Définitions Une application Android est un assemblage de composants liés grâce à un fichier de configuration (Figure 3.1). Avant de rentrer dans le détail d’une application Android et de son projet associé, différents concepts fondamentaux sont à préciser : les activités ; les vues et contrôles (et leur mise en page) ; les ressources ; le fichier de configuration appelé également manifeste.  Les vues sont les éléments de l’interface graphique que l’utilisateur voit et sur lesquels il pourra agir. Les vues contiennent des composants, organisés selon diverses mises en page (les uns à la suite des autres, en grille…). Les contrôles (boutons, champs de saisie, case à cocher, etc.) sont eux-mêmes un sous-ensembles des vues. Ils ont besoin d’accéder aux textes et aux images qu’ils affichent (par exemple un bouton représentant un téléphone aura besoin de l’image du téléphone correspondante). Ces textes et ces images seront puisés dans les fichiers ressources de l’application.  Une activité peut être assimilée à un écran structuré par un ensemble de vues et de contrôles composant son interface de façon logique : elle est composée d’une hiérarchie de vues contenant elles-mêmes d’autres vues. Une activité est par exemple un formulaire d’ajout de contacts ou encore un plan Google Maps sur lequel vous ajouterez de l’information. Une application comportant plusieurs écrans, possédera donc autant d’activités.  À côté de ces éléments, se trouve un fichier XML : le fichier de configuration de l’application. C’est un fichier indispensable à chaque application qui décrit entre autres : le point d’entrée de votre application (quel code doit être exécuté au démarrage de l’application) ; quels composants constituent ce programme ; les permissions nécessaires à l’exécution du programme (accès à Internet, accès à l’appareil photo...). Figure 3.1. Structure d’une application Android 10 3.3 Qu’est-ce qu’une activité Android ? Une activité peut être assimilée à un écran qu’une application propose à son utilisateur. Pour chaque écran de votre application, vous devrez donc créer une activité. La transition entre deux écrans correspond au lancement d’une activité ou au retour sur une activité placée en arrière-plan. Une activité est composée de deux volets :  La logique de l’activité et la gestion du cycle de vie de l’activité qui sont implémentées en Java dans une classe héritant de Activity (nous reviendrons plus tard sur tous ces concepts) ;  L’interface utilisateur, qui pourra être définie soit dans le code de l’activité soit de façon plus générale dans un fichier XML placé dans les ressources de l’application. Voici venu le moment de voir à quoi ressemble l’activité la plus simple possible : 3.4 Cycle de vie d’une activité Pour développer une application sur Android, on doit comprendre le cycle de vie d’une activité (Figure 3.2). Figure 3.2 Cycle de vie d’une activité 11 Les états principaux d’une activité sont les suivants : active (active) : activité visible qui détient le focus utilisateur et attend les entrées utilisateur. C’est l’appel à la méthode onResume, à la création ou à la reprise après pause qui permet à l’activité d’être dans cet état. Elle est ensuite mise en pause quand une autre activité devient active grâce à la méthode onPause ; suspendue (paused) : activité au moins en partie visible à l’écran mais qui ne détient pas le focus. La méthode onPause est invoquée pour entrer dans cet état et les méthodes onResume ou onStop permettent d’en sortir ; arrêtée (stopped) : activité non visible. C’est la méthode onStop qui conduit à cet état. La Figure 3.2 représente ces principaux états et les transitions y menant. Le cycle de vie d’une activité est parsemé d’appels aux méthodes relatives à chaque étape de sa vie. Il informe ainsi le développeur sur la suite des événements et le travail qu’il doit accomplir. Voyons de quoi il retourne en observant chacune de ces méthodes. 12 13 Pourquoi implémenter ces méthodes? Cela est important afin que votre application fonctionne correctement :  Réception d’un appel et basculement sur une autre application ;  Ne pas consommer trop de ressources système ;  Ne pas avoir de problème lors de la création/restauration de l’application par le système (lors d’une rotation de l’écran par exemple). Remarque : avant de distribuer une application, Il est donc important d’avoir fait des tests dans les situations évoquées ci-dessus. 3.5 Les ressources Les ressources sont des fichiers externes – ne contenant pas d’instruction – qui sont utilisés par le code et liés à votre application au moment de sa construction. Android offre un support d’un grand nombre de fichiers ressources comme les fichiers images JPEG et PNG, les fichiers XML… L’externalisation des ressources en permet une meilleure gestion ainsi qu’une maintenance plus aisée. Android étend ce concept à l’externalisation de la mise en page des interfaces graphiques (layouts) en passant par celle des chaînes de caractères, des images et bien d’autres... Physiquement, les ressources de l’application sont créées ou déposées dans le répertoire res de votre projet. Ce répertoire sert de racine et contient lui-même une arborescence de dossiers correspondant à différents types de ressources (Tableau 3.1). Tableau 3.1 Les types majeurs de ressources avec leur répertoire associé  Toutes ces ressources sont placées, converties ou non, dans un fichier de type APK qui constituera le programme distribuable de votre application. De plus, Android crée une classe nommée R qui sera utilisée pour se référer aux ressources dans le code. 3.6 Conclusion Dans ce chapitre, nous avons présenté les notions d’activités et ressources Android. Dans le chapitre suivant, nous entamons la création des interfaces graphiques associées aux différentes activités. 14 Chapitre 4 Interfaces graphiques et widgets 4.1 Introduction Il n’y a pas de bonne application sans bonne interface utilisateur : c’est la condition de son succès auprès des utilisateurs. Les interfaces graphiques prennent une place de plus en plus importante dans le choix des applications par les utilisateurs, tant dans l’implémentation de concepts innovants qu’au niveau de l’ergonomie. Comme sur bien des plates-formes, les interfaces d’applications Android sont organisées en vues et gabarits, avec néanmoins quelques spécificités. Dans ce chapitre, nous présentons les concepts de widgets, interfaces graphiques ainsi que leur création sous Android. 4.2 Le concept d’interface Une interface n’est pas une image statique mais un ensemble de composants graphiques, qui peuvent être des boutons, du texte, mais aussi des groupements d’autres composants graphiques, pour lesquels nous pouvons définir des attributs communs (taille, couleur, positionnement, etc.). Ainsi, l’écran ci-après (Figure 4.1) peut-il être vu par le développeur comme un assemblage (Figure 4.2). Figure 4.1. Exemple d’un écran Figure 4.2. Le même écran vu par le développeur 15 La représentation effective par le développeur de l’ensemble des composants graphiques se fait sous forme d’arbre, en une structure hiérarchique (Figure 4.3). Il peut n’y avoir qu’un composant, comme des milliers, selon l’interface que vous souhaitez représenter. Dans l’arbre ci-après (Figure 4.3), par exemple, les composants ont été organisés en 3 parties (haut, milieu et bas). Figure 4.3. Arborescence de l’interface précédente Sous Android, vous pouvez décrire vos interfaces utilisateur de deux façons différentes (nous reviendrons plus tard en détail sur ce point) : avec une description déclarative XML ou directement dans le code d’une activité en utilisant les classes adéquates. La façon la plus simple de réaliser une interface est d’utiliser la méthode déclarative XML via la création d’un fichier XML que vous placerez dans le dossier /res/layout de votre projet. 4.3 Le concept de widgets Le mot widget désigne l’ensemble des vues standards incluses dans la plate-forme Android. Elles font partie du paquetage android.widget. Les vues héritant toutes de la classe View, chaque widget hérite aussi de cette classe. Ainsi l’élément Button hérite-t-il de TextView, qui lui-même hérite de classe View. L’élément CheckBox, quant à lui, hérite de la vue Button. Tout comme nous l’avions fait dans l’exemple précédent, Android vous offre la possibilité de regrouper plusieurs vues dans une structure arborescente à l’aide de la classe ViewGroup. Cette structure peut à son tour regrouper d’autres éléments de la classe ViewGroup et être ainsi constituée de plusieurs niveaux d’arborescence. L’utilisation et le positionnement des vues dans une activité se fera la plupart du temps en utilisant une mise en page qui sera composée par un ou plusieurs gabarits de vues. 4.4 Positionner les vues avec les gabarits Un gabarit, ou layout dans la documentation officielle, ou encore mise en page, est une extension de la classe ViewGroup. Il s’agit en fait d’un conteneur qui aide à positionner les objets, qu’il s’agisse de vues ou d’autres gabarits au sein de votre interface. Vous pouvez imbriquer des gabarits les uns dans les autres, ce qui vous permettra de créer des mises en forme évoluées. Comme nous l’avons dit plus haut, vous pouvez décrire vos interfaces utilisateur soit par une déclaration XML, soit directement dans le code d’une activité en utilisant les classes adéquates. Dans les deux cas, vous pouvez utiliser différents types de gabarits. En fonction du type choisi, les vues et les gabarits seront disposés différemment : LinearLayout : permet d’aligner de gauche à droite ou de haut en bas les éléments qui y seront incorporés. En modifiant la propriété orientation vous pourrez signaler au gabarit dans quel sens afficher ses enfants : avec la valeur horizontal, l’affichage sera de gauche à droite alors que la valeur verticale affichera de haut en bas ; RelativeLayout : ses enfants sont positionnés les uns par rapport aux autres, le premier enfant servant de référence aux autres ; 16 FrameLayout : c’est le plus basique des gabarits. Chaque enfant est positionné dans le coin en haut à gauche de l’écran et affiché par-dessus les enfants précédents, les cachant en partie ou complètement. Ce gabarit est principalement utilisé pour l’affichage d’un élément (par exemple, un cadre dans lequel on veut charger des images) ; TableLayout : permet de positionner vos vues en lignes et colonnes à l’instar d’un tableau. Voici un exemple de définition déclarative en XML d’une interface contenant un gabarit linéaire (le gabarit le plus commun dans les interfaces Android). Chaque gabarit possède des attributs spécifiques, et d’autres communs à tous les types de gabarits. Parmi les propriétés communes, vous trouverez les propriétés layout_width et layout_height. Celles-ci permettent de spécifier le comportement du remplissage en largeur et en hauteur des gabarits et peuvent contenir une taille (en pixels ou dpi) ou les valeurs constantes suivantes : fill_parent (much_parent) et wrap_content. La valeur fill_parent spécifie que le gabarit doit prendre toute la place disponible sur la largeur/hauteur. Par exemple, si le gabarit est inclus dans un autre gabarit – parent (l’écran étant lui- même un gabarit) – et si le gabarit parent possède une largeur de 100 pixels, le gabarit enfant aura donc une largeur de 100 pixels. Si ce gabarit est le gabarit de base – le plus haut parent – de notre écran, alors ce dernier prend toute la largeur de l’écran. Si vous souhaitez afficher le gabarit tel quel, vous pouvez spécifier la valeur wrap_content. Dans ce cas, le gabarit ne prendra que la place qui lui est nécessaire en largeur/hauteur. Vous pouvez spécifier une taille précise en px (pixel) ou dip (dpi). Notez cependant que si vous avez besoin de spécifier une taille, notamment si vous avez besoin d’intégrer une image avec une taille précise, préférez les valeurs en dip à celles en px. En effet, depuis la version 1.6, Android est devenu capable de s’exécuter sur plusieurs tailles d’écrans. Les valeurs en dip permettent un ajustement automatique de vos éléments alors que les valeurs en px prennent le même nombre de pixels quelle que soit la taille de l’écran, ce qui peut très vite compliquer la gestion de l’affichage sur la multitude d’écrans disponibles. 4.5 Créer une interface utilisateur La création d’une interface se traduit par la création de deux éléments : une définition de l’interface utilisateur (gabarits, etc.) de façon déclarative dans un fichier XML ; une définition de la logique utilisateur (comportement de l’interface) dans une classe d’activité. Cela permet d’avoir une séparation stricte entre la présentation et la logique fonctionnelle de votre application. De plus, un intégrateur graphique pourra modifier l’interface sans interférer avec le code du développeur. 4.5.1 Définir votre interface en XML Une bonne pratique est de définir intégralement votre interface dans la déclaration XML. Retenez néanmoins qu’il est aussi possible (et bon nombre de scénarios ne pourront s’en passer) d’instancier dynamiquement des vues depuis votre code. Les fichiers de définition d’interface XML sont enregistrés dans le dossier /layout de votre projet. Prenez garde à ce que le nom du fichier ne comporte que des lettres minuscules et des chiffres. 17 Chaque fichier de définition d’interface, pour peu qu’il se trouve bien dans le répertoire res/layout de votre projet, possède un identifiant unique généré automatiquement par l’environnement de développement. De cette façon, vous pouvez y faire référence directement dans votre code. Par exemple, si le fichier se nomme monLayout, vous pouvez y faire référence dans votre code grâce à la constante R.layout.monLayout. Comme vous le verrez, l’utilisation des identifiants est très courante : ils vous serviront à récupérer des éléments, à spécifier des propriétés et à utiliser les nombreuses méthodes des activités (findViewById, setContentView, etc.). Dans votre projet Android, créez un fichier main.xml dans le dossier /layout et placez-y le contenu suivant: Cette interface définit un gabarit de type Linear Layout et un composant graphique de saisie de texte de type TextView. Vous remarquerez que nous avons défini un attribut android:id avec la valeur @+id/monText. Cette valeur nous permettra de faire référence à cet élément dans le code avec la constante R.id.montext. Le complément ADT génère automatiquement un identifiant pour cette définition d’interface. Nommée main.xml et placée dans le répertoire res/layout, cet identifiant sera R.layout.main. 4.5.2 Associer votre interface à une activité et définir la logique utilisateur Dans une application, une interface est affichée par l’intermédiaire d’une activité. Vous devez donc avant toute chose créer une activité en ajoutant une nouvelle classe à votre projet dérivant de la classe Activity. Le chargement du contenu de l’interface s’effectue à l’instanciation de l’activité. Redéfinissez la méthode onCreate de l’activité pour y spécifier la définition de l’interface à afficher via la méthode setContentView. Cette méthode prend en paramètre un identifiant qui spécifie quelle ressource de type interface doit être chargée et affichée comme contenu graphique. Nous utilisons l’identifiant généré automatiquement pour spécifier l’interface que nous avons précédemment créée. 18 L’interface (code 4-2) a défini un composant graphique TextView vide. Pour y accéder depuis le code et pouvoir le manipuler, vous devez d’abord récupérer une instance de l’objet avec la méthode findViewById de l’activité. Une fois l’objet récupéré, vous pourrez le manipuler de la même façon que n’importe quel objet, par exemple pour modifier son texte. L’affichage répercutera le changement. Le code suivant récupère le composant graphique TextView que nous avons nommé monText dans l’interface, puis utilise la méthode setText pour changer le contenu de son texte. Le résultat dans l’émulateur Android est celui de la Figure 4.4. Figure 4.4. Résultat du code 4.4 4.6 Conclusion Nous avons appris dans ce chapitre la création des interfaces utilisateur sous Android et nous allons apprendre dans le chapitre suivant celle des menus et boites de dialogues. 19

Use Quizgecko on...
Browser
Browser