Dans mes appli sur d'autres OS , je récupere au lancement du programme la résolution utilisée et le ratio hauteur/largeur
je resize alors mes composants et la taille de la fonte en fonction de ces données.
Donc a quoi peut bien servir ces DIP ?
Si sur un écran de 320pix je crée un bouton de 107pix il fera environ le 1/3 de la taille
Maintenant si l'appli est lancée sur un ecran de 640 il suffit de resizer le bouton a 107*(640/320) pour obtenir le même ratio ou d'utiliser la place supplémentaire pour afficher autre chose
Une résolution de 800 pixels c'est la même chose chez acer, samsung, ou tartampion
DIP veut dire Density Independent Pixels.
C'est utile lorsqu'on définit des mises en page (layout) pour des appareils de mêmes dimensions physiques mais de résolutions différentes, dans ce cas un seul et fichier 'layout' avec une variante peut suffire.
Mais la réalité actuelle est nettement différente avec des appareils de dimensions physiques et résolutions différentes.
Actuellement il faut considérer au moins trois dimensions physiques:
Smartphones 3.5'
Tablettes 7'
Tablettes 10'
Pour couvrir ces trois dimensions il faut au moins 3 variantes par orientation.
Mais prenons l'exemple des Smartphones, dimension des écrans environ 3.5':
Mais avec trois résolutions différentes:
pixels dendité échelle
240 * 320 120 0.75
320 * 480 160 1
480 * 800 240 1.5
Une même variante de layout satisfait ces trois résolutions si les dimensions sont données en dip.
Le système calcule les positions et dimensions des objets en tenant compte de l'échelle.
Les valeurs entrées dans le Designer sont d'ailleurs considérées comme des dimensions en dip.
Par contre, pour les trois résolutions ci-dessus, le rapport hauteur/largeur n'est pas le même.
Par rapport à 320 * 480 il manque de l'espace en hauteur pour la résolution 240 * 320 et pour la résolution 480 * 800 il y a plus d'espace disponible.
Donc si on veut exploiter vraiment tout l'espace disponible il faut soit les adapter dans le code, tel que tu le proposes, ou établir autant de variantes que nécessaire.
Mais pour des écrans de dimension physiques différentes et des résolutions quasi identiques il est préférable de définir des variantes voire des fichiers layouts différents pour profiter de l'espace supplémentaire.
Tes explications confirment bien ce que j'avais compris.
Les Dip sont un pis-aller.
On se rend bien compte du problème en lançant des appli smatphone sur une tablette !
De toute façon, il n'y a pas vraiment de solution, avec la disparité de matériel le choix est cornélien.
Soit on multiplie les layout soit on se prend le choux avec les ratios.
KLAUS , 4 questions relatives à ce sujet :
1)
pouvez vous confirmer que le DESIGNER de basic4A traduit tous nos positionnements en DIP ;
2)
Comment , au run-time , les dimensions indiquées dans le designer ( TOP , LEFT , WIDTH , HEIGHT ) sont elles converties en valeurs adaptées à l'appareil , par rapport à l'AVD utilisé à la conception (par exemple , j'utilise un AVD GPhone 2.2 indiquant type WVGA 800*480 , un DPI=96 , une densité 240).
3)
Ensuite, depuis la version 1.70, il y a en plus un ABSTRACT DESIGNER , mais celui-ci ne donne pas le même rendu visuel que l'AVD , principalement en Hauteur : un listView avecTop=100 et H=480 laisse une place libre égale à 50% environ de sa hauteur en dessous de lui, alors que dans l'Abstract Designer, cette place n'est que de 20%.
4)
Comment se positionne une View qui est contenu dans une autre view ?
Dans un outil tel que DELPHI (sous WinXP) , le positionnement du contenu est relatif au container : ainsi un bouton situé à Left=100 et contenu dans un Panel qui lui même est à Left=80 , sera à 100+80=180 du bord gauche de l'écran.
2) Par défaut, la valeur de la densité est de 160 échelle 1.
Lors du lancement du programme le système tient compte de l'échelle du layout, de l'échelle de l'appareil (ou émulatuer) et recalcule les valeurs des propriétés Left, Top, Right et Bottom en conséquence.
Attention: si on définit un layout 480/800/240 les valeurs seront corrigées avec le facteur 1.5 (240/160) pour un layout de 480/800/160 !
3) Je n'ai pas encore beaucoup travaillé avec l'Abstarct Designer. Mais si les dimensions des deux écrans sont définis pour une même résolution et échelle, le résultat devrait être le même. Dans l'Abstarct Designer on peut sélectionner des résolutions différentes de celle affichée dans le Designer.
4) La position d'une View à l'intérieur d'une autre est relative au ZERO de la View parent, donc 180 du bord de l'écran dans votre exemple.
je découvre un parametre pernicieux , inconnu dans le monde WinXP , à savoir la "Densité" ;
on connait en général la taille de l'écran du smartPhone ou tablet utilisé, mais on trouve jamais (ou rarement ?) cette densité dans la doc commerciale.
Je vais creuser ce sujet, car cela explique peut-etre pourquoi, alors qu'un bouton , un text-view ou autre élément, parfaitement visible dans le Designer , disparait à l'exécution, principalement quand il est placé en bas de l'écran.
Mais quelle est la définition de la DENSITé ?
Est-ce la même chose que ce qu'on appelle ailleurs les DPI (Dips per Inch = Pixels per Inch) ?
Si OUI, l'écran de ma Tablet 7 pouces faisant 86 x 155 mm (diagonale 177 mm = 6,97 inch), et annoncé comme étant un 480 x 800 pixels , j'en déduit que :
-- la densité en largeur est de 142
-- la densité en hauteur est de 131
Je suis donc assez loin des densités théoriques de 160 ou 240.
Un calcul similaire pour un Sony Xperia X10 MINI PRO , donné pour 240*320 pixels , l'écran faisant 39 * 52 mm (diag 65mm = 2,56 inch) :
-- densité largeur = 156
-- densité hauteur = 156
ici , on est effectivement aux 160 de densité (aux erreur de mensuration près)
Oui, la notion de densité est en principe équivalente aux DPI (dots per inch)
DIP = density independant pixel.
Sauf que Android donc B4A ne tient pas compte de la densité exacte mais des densités suivantes.
- 160 densité normale, échelle 1
écrans environ 3.5'' 320*480
écrans environ 7'' 480*800
écrans environ 10'' 800*1280
- 120 densité faible, échelle 0.75
écrans environ 3.5'' 240*320
- 240 densité élevée, échelle 1.5
écrans environ 3.5'' 480*800
La liste n'est pas exhaustive.
Les densités de 142 et 131 DPIs sont assimilées comme étant 160.
La différence est la différence des dimensions physiques.
Par exemple des écrans de 9.5'' et 10.1'' avec des résolutions identiques mais avec des dimensions physiques différentes mais semblables et des densités physiques différentes (150 et 160) et aussi semblables sont considérés comme ayant des densités identiques par B4A.
la façon dont android traite le problème ne risque t elle pas de devenir un gros casse-tete avec la multiplication des formats d'écrans , tels que :
les LG-C550 , Sony XPERIA Mini a clavier coulissant
écran seulement 2,8 " 240 * 320
les Motorola Defy , écran 3,7" mais 480 * 854
les écrans 4" et 4,3" en 480*800 des LG-P970 ou ZTE Skate43
et j'en oublie d'autres !
je n'arrive pas à comprendre l'utilité et l'usage de cette notion de densité , pour moi seules devraient comptées les dimensions en pixels de l'écran ; l'OS n'ayant qu'a faire un redimensionnement proportionnel entre l'écran de développement et l'écran réel de l'usager
la façon dont android traite le problème ne risque t elle pas de devenir un gros casse-tete avec la multiplication des formats d'écrans ...
Oui, et ça ira de mal en pis !
Quote:
je n'arrive pas à comprendre l'utilité et l'usage de cette notion de densité , pour moi seules devraient comptées les dimensions en pixels de l'écran ; l'OS n'ayant qu'a faire un redimensionnement proportionnel entre l'écran de développement et l'écran réel de l'usager
Non, c'est à mon sens plus compliqué que ça.
Prenons l'exemple de deux appareils l'un avec 480*800/240 et l'autre avec 480*800/160 mais de dimensions physiques différentes.
Sur l'appareil 480*800/160 on peut mettre plus d'objets de même dimensions physiques que sur l'appareil 480*800/240 car il a des dimensions physiques plus grandes donc une surface plus grande.
De même que sur un écran 7'' on peut mettre plus de d'objets de dimensions semblables que sur un écran de 3.5''. Et c'est là la grande différence, quels objets veut-on mettre sur les différentes tailles d'écran.
Je trouverais aberrant de mettre sur un écran de 7'' les mêmes objets mais de dimensions doubles que sur un écran de 3.5'', je préférerais avoir plus d'objets de dimensions semblables sur l'écran 7''.
KLAUS , ton raisonnement tient la route , mais le mien aussi , chacun étant valable pour certains types d'applications.
Effectivement, on a des petits écrans avec beaucoup de pixels (un 4" densité 240 donnant 480*800) , et une tablet 7" donnant aussi 480*800 avec une densité plus faible de 160 (ou 140 plus précisément).
Si je fais un bouton de 120 pîxels sur l'écran 4", soit 12 mm de large, c'est que j'estime que ce bouton est de la taille ad-hoc pour l'usage prévu (pas trop petit , sinon difficulté pour cliquer dessus et pour y lire le texte, pas trop grand pour qu'il y ait de la place pour les autres composants visuels).
La ou nos raisonnements différent , c'est que :
* pour toi, si l'usager achete un plus grand appareil, c'est pour avoir plus de choses sur son écran , deux fois plus d'images, de boutons, de lignes dans les ListView.
* pour moi, c'est pour avoir une ergonomie adaptée à sa vue , à la grosseur de ses doigts, et aux éléments de sa capacité gestuelle.
As-tu remarqué (en France en tout cas) , que la miniaturisation à outrance, qui semble convenir aux jeunes usagers, ne convient pas du tout aux personnes agées , au point qu'une marque ( DORO ici) s'est spécialisée dans les téléphones à grosses touches ?
En conclusion, au lieu que Android prétende régler ces problèmes, d'une façon obscure et toujours imparfaite, il serait préférable que la maitrise en soit entièrement faite par le concepteur de l'application : quel paramètre faut-il régler pour interdire à Android de changer quoi que ce soit aux dimensions en pixels ?
Question sur DIP
Linear Mode
