Les bases de la mise page d’une application Android

Depuis quelques jours, vous pouvez dire que vous vous savez programmer une application Android. Pas encore de quoi révolutionner le monde de l’interface mobile, certes, mais un truc interactif avec des boutons. Seulement voilà, afficher des vues, c’est bien, mais pouvoir décider où et comment le faire, c’est tout de même mieux.

C’est la mission du jour, et dans ce tuto vous allez apprendre :

  • Placer les vues de manière grossière, mais ordonnée.
  • Décider de l’espace que prennent ces vues.

Pré-requis :

Temps : 45 minutes.

Préambule

Les possibilités de l’interface Android sont énormes. Vraiment. On peut disposer les objets un peu comme on veut, de manière automatique ou manuellement. Modifier le design d’une vue par défaut, faire des thèmes, coder des graphismes 3D… Avec des tutos aussi détaillés, il faudrait un bon bouquin pour tout couvrir. Si, si. Je rappelle que le code source de la bestiole fait tout de même 2 Go, pour un OS pour téléphone, c’est pas si mal.

On va donc vraiment effleurer le sujet, le but étant de vous rendre autonomes et capables de créer des applications publiables sur l’Android Market le plus rapidement possible. Une fois ce but atteint, donc probablement dans plusieurs mois, nous verrons les possibilités avancées du bébé.

Imbrications de vues linéaires

On peut disposer les vues de bien des façons dans Android, mais la manière la plus naturelle, et celle que l’on utilise le plus souvent pour des écrans simples, reste l’imbrication de LinearLayout. Pour rappel, les LinearLayout sont des vues qui n’affichent rien, mais dont le but et de contenir d’autres vues. Les LinearLayout affichent ensuite ces vues de manière verticale, ou horizontale, les unes à la suite des autres :

Comme un LinearLayout peut contenir autant de vues que l’on veut, y compris d’autres LinearLayout, on va les utiliser pour disposer nos vues comme on le souhaite en les imbriquant un peu à la Tetris.

Supposons que l’on veuille créer le formulaire suivant :

Il y a d’abord les vues évidentes :

  • Une vue texte pour l’en-tête.
  • Trois vues de zone de saisie.
  • Une vue bouton.

Mais en plus, pour positionner ces vues, il y aura 3 vues supplémentaires :

  • Un LinearLayout vertical comme élément à la racine du fichier main.xml. Je vous rappelle en effet que pour être valable, un XML ne peut contenir qu’un seul noeud racine. Il nous faut donc une vue pour contenir toutes les autres.
  • Un LinearLayout horizontal pour contenir les 3 zones de saisies et le bouton.
  • Un LinearLayout vertical pour grouper et aligner les zones de saisies.

Elle sont ainsi disposées :

Réalisation du modèle

Nous allons maintenant réaliser l’écran ci-dessus pas à pas. Créez un nouveau projet « LinearLayoutTuto » avec un package « net.evidence.linearlayouttuto » et une classe principale « LinearLayoutTuto ». Cette fois nous n’interviendrons pas dans le code Java, nous allons vous contenter de modifier le XML pour nous concentrer sur l’apprentissage des vues.

Ici, vous allez d’abord modifier le fichier strings.xml pour avoir une base de travail simple :

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="app_name">LinearLayoutTuto</string>
	<string name="tuto_intro">En tête de mon app Android</string>
	<string name="tuto_bouton">OK</string>
</resources>

Pour le moment rien qui ne devrait vous être inconnu. Maintenant passons aux choses sérieuse, le fichier main.xml.

Avec une structure naïve, le XML devrait ressembler à cela :

<?xml version="1.0" encoding="utf-8"?>
 
<!-- Notre fameux élément racine. android:orientation="vertical" précise que c'est un LinearLayout qui va aligner les vues de haut en bas -->
 
<LinearLayout
    <!-- N'oubliez jamais xmlns:android en tout début de fichier ! -->
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
>
 
    <!--  Un TextView pour l'en-tête, comme prévu -->
 
    <TextView
	    <!--  On fait référence au texte dans strings.xml -->
	    android:text="@string/tuto_intro"
 
    />
 
    <!--  La LinearLayout HORIZONTAL qui va mettre côte à côte les zones de saisie et le bouton « ok » -->
 
    <LinearLayout android:orientation="horizontal" >
 
         <!--  La LinearLayout VERTICAL qui aligner les zones de saisie sur la même colonne  -->
 
         <LinearLayout android:orientation="vertical" >
 
             <!--  Nos 3 zones de saisie -->
 
	     <EditText  />
 
	     <EditText  />
 
	     <EditText  />
 
	  </LinearLayout>
 
          <!--  Le bouton -->
 
	  <Button android:text="@string/tuto_bouton" />
 
    <!--  On oublie pas de fermer les balises layout, sinon gare à la casse -->  
 
    </LinearLayout>
 
</LinearLayout>

On essaye de lancer le programme, et… Ça ne marche pas ! Pourtant nous n’avons pas touché au code Java, mais les erreurs du XML sont tout aussi importantes pour Android. Il manque en effet quelque chose de crucial à notre code : déclarer explicitement quelle place doivent prendre les vues à l’écran. Vous vous souvenez des instructions « layout_width » et « layout_height » ?

Hauteur et largeur des vues dans Android

Android n’attribue pas de taille par défaut aux vues, il faut lui dire explicitement ce qu’il doit faire. Il y a 3 comportements :

  • Prendre le minimum de place possible : un bouton aura la taille du texte qu’il affiche, une zone de saisie aura la taille du texte que l’utilisateur tape, etc.
  • Prendre le maximum de taille possible : la vue prendra toute la place dans son parent. Son parent est la vue qui la contient.
  • Prendre une place donnée : la vue aura une taille définie en pixels ou en DIP.

Généralement, on privilégie les 2 premiers comportements, car ils s’adaptent automatiquement à la taille de l’écran. Souvenez vous qu’Android fonctionne sur des téléphones différents, avec des écrans différents. De plus, sur le même téléphone, on peut avoir l’écran en mode « portrait » ou « paysage ». Sur le HTC Dream, à chaque fois que l’on ouvre ou ferme le clavier, on change de mode ! Donc avoir une mise en page élastique est plutôt une bonne chose. On réservera la définition manuelle de la taille pour des ajustements de détails.

Ces comportements se définissent au travers des attributs « layout_width » pour la largeur, et « layout_height » pour la hauteur. Toutes les vues acceptent ces attributs. On leur donnera donc les valeur suivantes :

  • fill_parent : remplir le parent, donc prendre toute la place possible.
  • wrap_content : coller au plus près du contenu, donc prendre le minimum de place.
  • xx uté : une value numérique et son unité comme « 10px » ou « 5dip ».

Appliquons immédiatement cela à notre XML. Commençons par tout définir en wrap_content :

<?xml version="1.0" encoding="utf-8"?>
 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    >
 
	<TextView
	    android:layout_width="wrap_content"
	    android:layout_height="wrap_content"
	    android:text="@string/tuto_intro"
	    />
 
	<LinearLayout
	    android:orientation="horizontal"
	    android:layout_width="fill_parent"
	    android:layout_height="wrap_content"
	    >
 
		    <LinearLayout
		    android:orientation="vertical"
		    android:layout_width="wrap_content"
		    android:layout_height="wrap_content"
		    >
 
			    <EditText android:layout_width="wrap_content"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="wrap_content"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="wrap_content"
			              android:layout_height="wrap_content"
			    />
 
		    </LinearLayout>
 
	           <Button android:layout_width="wrap_content"
			   android:layout_height="wrap_content"
			   android:text="@string/tuto_bouton"
	            />
 
	</LinearLayout>
 
</LinearLayout>

Ce qui nous donne :

Un bon point, ça marche, mais le résultat n’est pas exactement celui attendu. Certes, les vues sont alignées comme souhaitées avec les LinearLayout. Mais tout est très petit : c’est normal, nous avons demandé aux vues de prendre le moins de place possible. Si vous entrez du texte dans une zone de saisie, celle-ci va s’allonger. Un peu déroutant. La hauteur est correcte pour la vue texte et les zones de saisie, mais on voulait que le bouton soit aussi haut que les trois EditText. Il va falloir faire des corrections.

Essayons de changer le dernier point. Demandons à la hauteur du bouton de prendre toute la place possible en hauteur :

<Button android:layout_width="wrap_content"
			            android:layout_height="fill_parent"
			            android:text="@string/tuto_bouton"
/>

Et hop :

Exactement ce qu’il nous faut. Et cohérent : le bouton s’étend jusqu’à remplir tout son parent. Son parent est un LinearLayout qui contient le bouton et trois zones de saisies. La hauteur du LinearLayout est sur « wrap_content », donc il fait exactement la taille de la hauteur des 3 zones de saisie !

Bien, puisque « fill_parent » à l’air de nous porter chance, on va l’appliquer à la largeur des zones de saisie qui sont un peu rachitiques :

<EditText android:layout_width="fill_parent"
	  android:layout_height="wrap_content"
/>
 
<EditText android:layout_width="fill_parent"
	  android:layout_height="wrap_content"
/>
 
<EditText android:layout_width="fill_parent"
	  android:layout_height="wrap_content"
/>

Wooops ! Ça ne change rien. Logique, les zones de saisie remplissent tout leur parent, mais leur parent est un LinearLayout vertical qui à sa largeur sur « wrap_content », donc elles remplissent tout un conteneur, mais le conteneur essaye de prendre le minimum de place. Changeons la largeur de tous les conteneurs alors !

<?xml version="1.0" encoding="utf-8"?>
 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    >
 
	<TextView
	    android:layout_width="fill_parent"
	    android:layout_height="wrap_content"
	    android:text="@string/tuto_intro"
	    />
 
	<LinearLayout
	    android:orientation="horizontal"
	    android:layout_width="fill_parent"
	    android:layout_height="wrap_content"
	    >
 
		    <LinearLayout
		    android:orientation="vertical"
		    android:layout_width="fill_parent"
		    android:layout_height="wrap_content"
		    >
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
		    </LinearLayout>
 
	            <Button android:layout_width="fill_parent"
			    android:layout_height="fill_parent"
			    android:text="@string/tuto_bouton"
	            />
 
	</LinearLayout>
 
</LinearLayout>

On obtient :

Hum, les zones de saisie sont larges, mais le bouton à disparu ! Une erreur que les débutants on beaucoup de mal à comprendre, alors lisez bien ce qui va suivre :

« fill_parent » donne le droit à une vue de remplir tout l’espace de son parent. TOUT l’espace. Pas juste l’espace disponible restant. Comme les zones de saisies sont déclarées en premières dans le XML, elles prennent tout l’espace. Et il ne reste rien pour le bouton.

Quelle solution alors ?

On pourrait déclarer la taille taille des zones de saisie en pixels par exemple. Ce qui donnerai ceci :

<LinearLayout android:orientation="vertical"
	      android:layout_width="200px"
	      android:layout_height="wrap_content"
>
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
</LinearLayout>

Côté téléphone :

Mieux, mais pas très souple. Que se passe-t-il sur un écran plus petit ou plus grand ? Ou en mode « paysage » ? L’idéal serait de pouvoir déclarer la largeur en « % » comme en CSS, mais cela n’existe pas sur Android.

Utiliser intelligemment « layout_weight »

« layout_weight » est un propriété des vues souvent très mal employées. Elle sert à donner un « poids » aux vues pour leur attribuer de l’espace. Elle n’a pas d’effet quand on définit partout « wrap_content », et un effet très peu intuitif avec « fill_parent ». Pourtant c’est dans ce dernier cas qu’on la rencontre souvent.

Étrange, car cette propriété très mal comprise, est pourtant très simple. Quand des tailles fixes sont définies, elle distribue l’espace qui reste comme des parts de gâteaux, en donnant le plus de part aux plus gros poids. Il faut que des tailles fixes soient définies, ça ne marche pas avec « wrap_content », et ça marche à l’envers avec « fill_parent ».

Donc le plus simple pour donner un pourcentage de l’espace, est de définir la taille de toutes les vues à 0, puis de donner des poids. Oui, c’est un peu étrange, je l’accorde, mais très efficace.

Dans notre cas nous allons :

  • Donner une largeur nulle au LinearLayout qui contient les zones de saisie.
  • Donner une largeur nulle au bouton.
  • Donner un poids de 1 au bouton.
  • Donner un poids de 2 au LinearLayout, pour qu’il prenne « deux fois plus de place que le bouton ».

Let’s go :

<LinearLayout android:orientation="vertical"
	       android:layout_width="0px"
               android:layout_weight="2"
	       android:layout_height="wrap_content"
>
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
    <EditText android:layout_width="fill_parent"
	      android:layout_height="wrap_content"
    />
 
</LinearLayout>
 
<Button android:layout_width="0px"
        android:layout_weight="1"
        android:layout_height="fill_parent"
        android:text="@string/tuto_bouton"
/>

Maintenant, même en retournant l’écran :

Petite astuce : Ctrl + F11 et Ctrl + F12 pour faire pivoter l’écran de l’émulateur.

Beaucoup, beaucoup mieux, n’est-pas ? Que nous manque-t-il ? Positionner tout le formulaire au centre de la page. Et ensuite améliorer l’en-tête.

Alignement vertical et horizontal avec Android

La propriété « gravity » peut prendre énormément de valeurs différentes, et sert à contrôler finement l’alignement des vues dans Android. Nous allons nous intéresser seulement à quelques unes de ses valeurs :

  • left : aligne à gauche
  • right : aligne à droite
  • center : aligne complètement au centre
  • center_horizontal : aligne au milieu mais uniquement au niveau horizontal
  • center_vertical : aligne au milieu mais uniquement au niveau vertical
  • bottom : colle la vue tout en bas de son parent
  • top : colle la vue tout en haut de son parent

Il est possible d’utiliser plusieurs valeurs en même temps en les séparant par des barres verticales « | » (pipes). Par exemple :

android:gravity="left|bottom"

Cela va aligner la vue en bas, à gauche.

Dans notre cas, nous voulons tout aligner au centre verticalement, et aligner la vue texte au centre horizontalement :

<?xml version="1.0" encoding="utf-8"?>
 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
 
<!--  On utilise la conteneur racine pour tout aligner au centre verticalement-->
 
    android:gravity="center_vertical"
 
<!--  Pour cela on doit changer la hauteur également pour que l'application prenne tout l'écran -->
 
    android:layout_height="fill_parent"
 
>
 
	<TextView
	    android:layout_width="fill_parent"
	    android:layout_height="wrap_content"
	    android:text="@string/tuto_intro"
 
	<!--  Alignement pour la text view -->
 
	    android:gravity="center_horizontal"
	/>
 
	<LinearLayout
	    android:orientation="horizontal"
	    android:layout_width="fill_parent"
	    android:layout_height="wrap_content"
	>
 
            <LinearLayout
		    android:orientation="vertical"
		    android:layout_width="0px"
                    android:layout_weight="2"
		    android:layout_height="wrap_content"
            >
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
			    <EditText android:layout_width="fill_parent"
			              android:layout_height="wrap_content"
			    />
 
           </LinearLayout>
 
          <Button android:layout_width="0px"
	          android:layout_weight="1"
	          android:layout_height="fill_parent"
	          android:text="@string/tuto_bouton"
	   />
 
	</LinearLayout>
 
</LinearLayout>

Et c’est terminé, vous avez enfin l’écran présenté au début du tuto.

Le petit mot de la fin

Présenter des données est un art en programmation, et Android propose déjà de nombreuses sophistications. Si vous avez des envies exotiques, de nombreuses possibilités s’offrent à vous : TableLayout pour aligner les éléments sur une grille, RelativeLayout pour positionner les éléments par rapport à leur parent ou voisins, mais aussi des vues toutes faites pour afficher des galeries photos, des listes, des arbres, des onglets, etc. Dans le plus poussé des cas, vous pouvez tout dessiner à la main.

Les vues XML sont des objets très gourmands en ressources. A chaque fois que vous écrivez un écran Android, pensez à obtenir le résultat voulu avec le moins de vues possibles. Moins vous utilisez de LinearLayout, moins vous utilisez de mémoire, de temps CPU et de batterie, ce qui est très important sur un téléphone portable.

Souvent, on utilise plus de vues que nécessaire pour enrober d’autres vues ou les positionner par facilité. Concevoir une bonne application Android prend du temps, mais n’oubliez pas que si vos utilisateurs voient la batterie siphonnée à chaque fois qu’elle ouvre votre application, elle finira à la poubelle.

Sur cette conclusion joyeuse et optimiste, on se revoit au prochain tuto où nous découvrirons comment jouer avec les marges, la taille des polices, le gras, l’italique, et comment désactiver une vue.

13 Réponses à “Les bases de la mise page d’une application Android”

  1. Julien Dit:

    Et bien voilà, je viens de me faire tous tes tuto cette après midi, une vrai mine d’or ! Si je peux te rendre la pareille (à mon niveau) …. n’hésites pas :)

    Ps: coquille, c’est le htc dream qui a un clavier, pas le magic ;)

  2. kevin Dit:

    Merci Julien. Tu as déjà fais la moitié du boulot, en effet le feedback est ce qu’il y a de plus important pour ce genre de travail. N’hésite pas notamment à souligner les détails qui restent flous ou que tu aimerais voir aborder. J’écris généralement mes tutos en fonction des mails que je reçois et des formations que je fais pour savoir ce que les gens ont besoin de comprendre.

    Tu peux aussi tester l’application android In Context et me faire la liste de ce que tu penses être un problème.

    Coquille corrigée :-)

    P.S : hum, si tu as fais tous les tutos en une après-midi, faudra peut-être que je revois le temps que j’annonce en début de tuto…

  3. Julien Dit:

    Pas de détails floues pour le moment (enfin je nage encore un peu mais je n’ai jamais touché au java de ma vie). Pour le temps d’apprentissage, ne change rien, j’ai un peu triché car le 1er tuto je l’avais déjà fait via le site officiel d’android, pour le reste on va dire que mes notions de javascript/actionscript et mon esprit logique m’ont bien aidé

    Pour ton appli :

    *Lorsque je secoue le téléphone, j’ai de temps en temps une erreur (http://img142.imageshack.us/img142/4232/debug1.png).
    *Je n’ai pas compris le OU “Commencer à écrire”.
    *Le curseur texte centre verticalement ça fait louche (http://img44.imageshack.us/img44/3051/debug2.png)
    *Pas de bouton pour valider la tache, c’est assez déroutant (j’ai hésité à appuyer sur le bouton retour)
    *La flèche qui pointe vers la droite dans la liste des taches n’est pas indispensable
    *Petit bug au niveau du cochage. J’ai d’abord coché mes 2 taches, puis quand j’ai voulu décocher la 2ème c’est la 1ère qui c’est décochée, ensuite quand elles sont toutes les 2 décochées, si je coche la 1ère c’est la 2ème qui se coche et le bug est persistant. (Pour info: un tache est réglé pour demain et l’autre pour hier/retard)

    Le reste est OK, le basculement est normal est l’interface est claire. Manque peut-être juste une catégorisation et un petit widget avec les prochaines taches.

    Voilà tout ;)

  4. kevin Dit:

    Merci pour le test !

    - Pour la secousse, il faut vraiment que je change l’algo, il est peu efficace.

    - “Commencer à écrire”, c’est à dire juste taper sur le clavier.

    - ok, pour le cursuer vertical. Il était volontairement mis au centre, je n’avais pas concience que c’était perturbant.

    - Pas de bouton “valider la tache” car c’est ainsi que tout fonctionne sur le téléphone : contacts, calendrier, musique. Il faut garder l’interface cohérente avec le système.

    - Sans flèche de droite, comment rajouterais tu une sous tâche ?

    - Pas de bug au niveau du cochage. Tu as du tester l’appli avec deux taches et en cochant la première, elle se retrouve en bas de la liste, c’est le comportement attendu.

    Encore merci pour le test, il y a des amélioration que je ne peux faire que comme ça.

  5. Julien Dit:

    Ok pour le “Commencer à écrire”, en fait ça ne concerne que les possesseurs de Dream (clavier physique)

    Pour la flèche de droite je parle juste du symbole a droite de chaque item de la liste :)

    Et sorry pour le cochage, effectivmeent ça bascule bien (j’avais créer 2 taches avec quasi le même nom du coup j’avais pas fait gaffe)

    ça roule donc :)

  6. kevin Dit:

    Oui, oui, on est d’accord pour le symbole de droite en face de chaque Item. Il permet d’accéder aux sous tâches. In Context permet de définir une infinité de niveaux de sous tâche, théoriquement sans ralentissement du fait de l’algo utilisé pour la récursivité des traitements.

    Je vais bientôt changer l’architecture des layers de présentation donc autant avoir toute les infos sur la précédente.

  7. E-vidence » Archive du blog » Tailles, marges et visibilité des vues sur Android Dit:

    [...] vous êtes un élève assidu, vous connaissez maintenant les premières arcanes de l’interface d’Android, de quoi commencer le développement de votre propre application. Or, on reconnaît la qualité [...]

  8. Clément Dit:

    Bonjour,

    Tout d’abord,merci pour ces tutos, ils sont simples et précis.

    J’ai une question sur la mise en page.
    La barre de titre de l’application (ici “LinearLayoutTuto”) peut-elle être manipulé ? Déplacement, couleurs, cachés, texte …

    J’ai regardé dans la doc des view et il n’y a rien sur cette barre.

    Merci d’avance pour la/les réponse(s)

  9. kevin Dit:

    Hello Clément,

    Comme à peu près tout sur Android on peut bien sûr personaliser la barre de titre. Je n’entrerai pas dans ces détails dans les tutos avant bien longtemps, alors pour le moment je te recommande de voir cet example de code :

    http://developer.android.com/guide/samples/ApiDemos/src/com/example/android/apis/app/CustomTitle.html

    La plus grande partie de la magie se trouve à :

    // demander une barre de titre modifiée
    // on peut même demander l'absence d'une barre de titre
    requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);
    setContentView(R.layout.custom_title);
    // associer une vue perso à la barre de titre
    getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE, R.layout.custom_title_1);

    A noter que c’est un code qui fait appel à un hook système, donc typiquement le genre de snippet qui change d’une API à l’autre. Pas de garantie que ça marche de la même manière sur Cupcake ou Donut.

  10. Herve Dit:

    Bonjour,
    Bravo et merci pour ces cours d’initiation à Android, ils sont très accessibles et encourageants :-)
    Une petite question-remarque concernant le “poids” à affecter aux Layouts: on affecte donc une valeur de 1 ou 2 à layout_weight associée à un layout_width=”0px”… effectivement le zéro pixel est très perturbant, sachant qu’une multiplication par 0 fait bien souvent 0… Aussi, emporté par un zèle fou, je me suis permis dans le tuto d’initialiser les layout_width à 1px. Ainsi, je vis mieux la multiplication de la pondération… Ai-je bien fait ?

  11. kevin Dit:

    Bonjour Herve,

    1px ? Mais ça ne va pas, tu es fou ? Il faut suivre le tuto point par point, à la lettre, sans ça l’émulateur risque le stack overflow, la division par zéro et le NullPointerException, EN MÊME TEMPS. 1px ? Bill gates a déplacé le menu “démarrer” d’un 1px, et tu sais ce que ça a donné ? Vista !

    Plus sérieusement, voilà ce qui va se passer : les deux vues vont prendre 1 px chacune, puis diviser les x pixels restant et se les partager selon la pondération.

    Par exemple, sur 100px avec une vue A de poids 1, et une vue B de poids 2 :

    - Avec 1 px de largeur -

    La vue A prend 1px et la vue B prend 1px. Restent 98px.
    B est de poids 2, il en prend 2/3 (65px) et mesure donc 65+1 = 66px.
    A est de poids 1, il prend 1/3 (32px) et mesure donc 32+1 = 33px.

    - Avec 0 px de largeur -

    La vue A prend 0px et la vue B prend 0px. Restent 99px.
    B est de poids 2, il en prend 2/3 (66px) et mesure donc 66 + 0 = 66px.
    A est de poids 1, il prend 1/3 (33px) et mesure donc 33 + 0 = 33px.

    Il n’y a donc strictement aucune différence. A priori, tu peux faire du zèle sans risquer une attaque terroriste.

    Bienvenue sur http://www.e-vidence.net :-)

  12. elwanis Dit:

    merci
    beaucoup

  13. Tons_1 Dit:

    Super tuto, très bien expliqué!
    Merci!

Ça se comprend tout seul