Comprendre les bases - Tutoriel Android

Maintenant que nous savons utiliser des vues nous allons chercher à les mettre en page, via les layouts. Le principe des layouts est de déclarer soit en XML, soit via du code, des règles de positionnement de nos vues à l'écran. Alors on peut effectivement le faire en code. Cela dit, ce n'est absolument pas recommandé pour plusieurs raisons La première déjà, c'est que c'est beaucoup plus complexe ça demande énormement de code pour arriver à avoir le même résultat que ce qu'on aurait en XML, C'est moins documenté, puisque justement ce n'est pas recommandé officiellement, donc vu qu'il y a moins d'informations, la plupart des guides vous parleront du WML et pas de l'utilisation via du code. Et en plus de ça, il est souvent recommandé de séparer la logique de présentation de la logique du code. Donc il y a très peu d'intérêt à le faire via code. Des fois, vous n'aurez pas le choix. Donc si vous avez quelque chose qui se génère parce que, suite à avoir télécharger sur Internet, et que vous ne pouvez pas passer par du XML parce que vous ne savez pas à l'avance les contenus, donc éventuellement vous pouvez dans ce cas-là, le générer via du code, mais il faut vraiment le réserver au cas particulier. Autre concept à savoir, vous avez deux types de vue. Vous avez des vues simples, ce qu'on a vu jusqu'à présent, des views, et vous avez les ViewGroup. Une vue a pour responsabilité d'afficher du contenu, un ViewGroup, alors ça hérite de View, sauf que ça n'affiche pas de contenu, ça sert à grouper des vues enfants. C'est à dire qu'un ViewGroup peut avoir une ou plusieurs vues enfants qui elles seront soit à leur tour des ViewGroups, soit des vues qui afficheront quelque chose. Et le seul but du ViewGroup, c'est d'organiser l'espace pour ces vues enfants. Pour chacune des vues, que ce soit une View ou un ViewGroup, Vous avez deux notions, les mêmes que celles qu'on a en CSS, par exemple, si vous avez déjà fait du développement sur le web. C'est à dire que vous avez des marges et du padding. Les marges, je les ai symbolisées en vert, indiquent l'espacement que vous voulez entre la vue et ces voisins proches, alors ça peut être soit entre la vue et son parent, soit entre la vue et une autre vue dans le même groupe, qui seraient côte à côte. En plus des marges, vous avez le padding. Le padding délimite à l'intérieur de la vue où sera dessiné le contenu. Mais si je prends cette vue avec une couleur de fond, la couleur de fond ira jusqu'au bord de la vue, par contre, si cette vue affiche du contenu, du texte ou autre à l'intérieur, il ne dépassera jamais les pointillés jaunes qu'on voit à l'intérieur, à cause du padding. Donc ces règles s'appliquent à la fois au View et au ViewGroup. Autre chose qu'il faut savoir, chacune de ces vues va préciser en XML notamment ou en code, plusieurs types d'attributs. Vous avez des attributs spécifiques à la vue, par exemple, l'ID ou alors le padding, puisqu'il est à l'intérieur de la vue, c'est la vue qui le gère par elle-même, Et vous avez aussi des attributs plus spécifiques à chacune des vues. Si je prends un TextView, comme on avait vu là, tout à l'heure, dans lequel on le « hello world », il a un attribut texte qu'n'est pas présent sur une image Vieuw, qui elle aura un attribut SRC pour afficher le lien de l'image. Donc en fonction du type de vue, on aura des attributs à cette vue-là : en plus des attributs spécifiques à la vue vous avez des paramètres de layout, c'est à dire que si la vue est dans un ViewGroup de tel type, elle aura des attributs spécifiques au type de ViewGroup dans lequel elle est, et qu'elle pourra préciser dans le XML. Donc ça dépend du type du groupe, nous on en verra trois. On verra le frame layout le linear layout et le relative layout, c'est les trois plus utilisés. Il en existe d'autres, on en verra des plus avancés aussi dans la suite du cours, mais, avec ces trois-là, vous pouvez faire quasiment tout ce que vous avez besoin de faire sur Android. Les infos minimales que doit fournir un élément par rapport à son ViewGroup c'est la largeur et la hauteur qu'il voudrait faire. Avec des attributs layout_width et layout_height. Il y a trois types de valeur qui sont possibles pour chacun de ces deux attributs. Soit l'élément demande à être aussi grand que son parent, donc match_parent, C'est un mot-clé particulier qui dit : je sais pas la taille de mon ViewGroup, mais je voudrais toucher ses bords. Si c'est pour la largeur, il va essayer de toucher les bords en largeur, et si pour la hauteur, il va toucher les bords en hauteur. Si au lieu de mettre match_parent, il choisit wrap_content, ça, ça veut dire : je voudrais être aussi grand que mon contenu. Par exemple, un TextView va essayer de faire pile la taille de son texte. S'il le précise en hauteur, il va faire pile la taille de la police, s'il précise un wrap_content en largeur, ça veut dire qu'il va aller de la première lettre à la dernière lettre. Et il n'essaiera pas d'aller plus loin, sauf le padding bien sûr. Ensuite, vous avez un dernier point, une dernière possibilité, c'est de préciser une taille fixe. Par exemple, si vous voulez faire 300 dp. Alors je parle de dp et pas de pixels, par rapport à ce qu'on a vu dans les premiers cours, je vous laisse le revoir si vous ne vous en rappelez pas. On parle toujours en pixel indépendant de la densité, donc vous pouvez fixer 10 dp, 20 dp, 100 dp, 1 000 dp, à vous de voir en fait ce que vous voulez comme taille fixe. Vous pouvez choisir n'importe laquelle de ces trois valeurs, mais vous devez, pour la largeur et la hauteur, en choisir une des trois. Donc voici un exemple, je prends une ImageView qui aurait des attributs qui lui sont spécifiques comme l'ID, le contentDescription et la source qui donnent des infos qui sont spécifiques à l'ImageView, et en plus, comme elle est dans un relative layout, elle a plusieurs infos, la largeur et la hauteur : elle demande à faire 25 dp de largeur et de hauteur, et en plus de ça, le haut de l'ImageView doit être aligné avec le haut de la rainbowFeedTable, qui doit être un autre élément dans la même vue. En plus de ça, elle demande à être alignée à droite de son parent, avec une marge à droite de 7 dp. On va revenir sur un exemple de notre projet, donc ici, j'ai mon TextView et mon bouton qui sont dans un relative layout. Le TextView demande à faire wrap_content, la largeur de son texte, et la hauteur de son texte. On ne le voit pas parce qu'il est transparent, mais si j'ajoute un background ici en disant : color je veux une couleur, donc colorAccent, que je relance mon projet, on voit que là, il est en rose, c'est juste pour pouvoir le voir que j'ai fait ça, pour vous le montrer, on voit qu'il fait pile la taille de son contenu. Parce qu'il demande du wrap_content, un wrap, c'est envelopper le contenu. le bouton par contre, il demande en largeur à faire match_parent et en hauteur wrap_content. Donc en hauteur, il fait pile la taille de son contenu, avec un peu de padding puisque justement un bouton à toujours un peu de padding, ça fait plus joli. et en largeur, par contre, match_parent il va essayer à être le plus grand possible par rapport à son parent. Et comme on est dans un relative layout, on a des infos complémentaires. Donc il peut dire : je veux être situé en dessous de ID/welcome_label, c'est à dire welcome_label, c'est lui, celui qui est au-dessus. Donc il est placé en dessous du label. Et il essaie de toucher les bords de son parent. Alors il n'y arrive pas. Pourquoi ? Parce que le parent a appliqué du padding. Donc les vues qui sont à l'intérieur doivent respecter forcément ce padding. Alors depuis tout à l'heure, je parle au conditionnel quand je parle des tailles. quand je dis, il aimerait envelopper le contenu. Pourquoi je parle comme ça ? Parce que ce n'est pas garanti. Si le relative layout n'a pas assez de place pour faire plaisir à tout le monde, il va devoir faire des concessions. Il va essayer au maximum de respecter ce que veut chacune des vues. Mais comme il y a plusieurs vues, imaginez que je mette un autre bouton, à côté de celui-ci, qui lui aussi voudrait être aussi grand que son parent, mais on ne pourrait pas avoir deux boutons aussi grands les uns que les autres, donc c'est le relative layout qui va faire des choix s'il n'arrive pas à satisfaire toutes les demandes de chacun.