French Question sur DIP

[scrat]

Bonjour

j'ai un petit souci de compréhension sur les DIP

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

Non ?

 

[klaus]

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.

Meilleures salutations.

 

[scrat]

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.

Merci

 

[zouriteman]

DIP et Designer

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.

 

[klaus]

1) Oui

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.

Meilleures salutations.

 

[zouriteman]

Merci

un 2eme grand merci pour cette réponse précise.

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)

 

[klaus]

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.

Meilleures salutations.

 

[zouriteman]

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

 

[klaus]

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 !

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''.

Meilleures salutations.

 

[zouriteman]

plus ou moins d'objets

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 ?

 

[scrat]

Salut

Perso je n'utilise pas le designer.
Je peux donc spécifier la taille des composants en pixels et leurs appliquer un coefficient comme bon me semble.

 

[klaus]

* 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?

Je pense que chaque développeur doit définir quel public cible il veut viser.
Malgré mes 66 ans je préfère toujours le premier point ci-dessus, mais ça n'est que mon point de vue.

Perso je n'utilise pas le designer.
Je peux donc spécifier la taille des composants en pixels et leurs appliquer un coefficient comme bon me semble.

Tout à fait d'accord, c'est le seul moyen d'avoir un contrôle complet de la situation. Rien n'empêche d'utiliser le Disigner pour une première mise en page visuelle puis de modifier le layout dans le code en fonction des différentes résolutions, tailles et orientations. L'utilisation du Abstract Designer (depuis la version 1.7 de B4A) permet actuellement de disposer plus facilement les objets pour différentes résolutions et tailles. Mais la solution la plus universelle reste la disposition par code.

Meilleures salutations.

 

[zouriteman]

Salut

Perso je n'utilise pas le designer.
Je peux donc spécifier la taille des composants en pixels et leurs appliquer un coefficient comme bon me semble.

Est-ce a dire que tu définis TOUT par le code ?
par exemple , pour un simple Label :
* au minimum Top , L , H , W , Text (soit 5 lignes d'instructions)
* et si tu veux sortir des valeurs par défaut :
- Color (du fond)
- Text Style : Typeface , H.Align , V.Align , SIZE , Color (du texte) , Style
- Corner radius
soit jusqu'à 8 lignes d'instructions

Et ceci répété pour chaque composant ( label , bouton , ... )

Bien sur , si tu as un modele unifié (une sorte de SKIN) , et que tu es bien organisé , tu peux effectivement rassembler cela dans une procedure unique , du genre :
Sub DESIGNER_LABEL ( oLABEL as Label , T , L , X , Y as int)
oLABEL.Color = xxxxxx
oLABEL.Top = T
end sub

Mais dans ce cas, tu n'est déja plus un "JUNIOR" :icon_clap:

 

[zouriteman]

PORTRAIT ou LANDSCAPE

pour KLAUS , qui semble tout connaitre :

Si j'ai bien compris Android , dès qu'on bascule l'écran à 90° , Portrait en landscape (ou vice versa) , l'application se réinitialise et on repasse dans la
Sub Activity_Create.
On sait si c'est la 1ERE fois, mais comment sait-on le sens de l'appareil ?

De plus , aucun appareil n'est symétrique : le haut et le bas ne sont pas identiques , et dans les appareils avec clavier coulissant genre Sony X10 Mini Pro , la gauche et la droite , ce n'est pas pareil (comme en politique :sign0089

As-t-on un indicateur précis de l'orientation de l'appareil ?


autre question : Activity.Width ( et .Top .Height .left) donnent la taille de l'Activity (ça semble être toujours la taille de l'écran : à confirmer ?) , mais lorsqu'on bascule l'écran , ces éléments restent-ils fixes ou basculent-ils ( échange entre Width et Height ) ?


derniere question : les tailles données par Activity.xxxx tiennent-elles compte des portions d'écran en haut et en bas (zones ou il y a de petites icones).

 

[klaus]

pour KLAUS , qui semble tout connaitre

Oh non, de loin pas tout.

Si j'ai bien compris Android , dès qu'on bascule l'écran à 90° , Portrait en landscape (ou vice versa) , l'application se réinitialise et on repasse dans la
Sub Activity_Create.

Oui.

As-t-on un indicateur précis de l'orientation de l'appareil ?

Oui. Si c'est pour les layouts, il suffit de tester si Activity.Height > Activity.Width donc l'orientation est portrait. A droite ou à gauche n'a pas d'incidence pour le layout le haut sera toujours le haut. Mon Nexus One, par exemple, ne fonctionne pas 'le tête en bas' en mode portrait. Sinon il y a la fonction PhoneOrientation dans la librairie Phone, moins évidente à utiliser.

Activity.Width ( et .Top .Height .left) donnent la taille de l'Activity (ça semble être toujours la taille de l'écran : à confirmer ?) , mais lorsqu'on bascule l'écran , ces éléments restent-ils fixes ou basculent-ils ( échange entre Width et Height )

Activity.Width et Activity.Height donnent les dimensions intérieures de l'écran qui sont à disposition et non la hauter totale de l'écran et changent avec l'orientation.

 

[zouriteman]

Phone Library

J'ai bien la PHONE library disponible dans mon B4A , mais je n'arrive pas à trouver une documentation sur celle-ci
j'ai peut être mal cherché , mais savez vous s'il existe un Help , ou une doc , un tutorial ?

TOut ce que j'ai trouvé , c'est un sujet dans le forum, avec un exemple d'usage de PhoneSensors
** du 21/11/2010 , par EREL , titre= Orientation and Accelerometer **

dans la foulée j'a testé l'exemple donné SENSORS, et sur un Xperia-X10-Mini-Pro cela donne en pratique les infos suivantes :
* Accelerometer = résultats et variations indéchiffables
* light = très efficace pour donner une indication sur la lumière ambiante ( 0=noir , 1600= intérieur maison , 90000 =
en plein jour )
ORIENTATION = le plus interessant
X = direction horizontale de l'appareil en degrés 0=le nord , 180=le sud , donc de 0 à 360 degrés
Y = donne une direction dans le plan vertical , tel que :
appareil à plat sur votre table Y = 0
appareil vertical tête en haut Y = -90° (négatif)
appareil vertical tête en bas Y = +90°
appareil en l'air , au dessus de vous (imaginez vous êtes allongés sur la plage,) Y = 180°

Je n'ai hélas pas trouvé la combinaison de chiffres X/Y/Z donnant la réponse à mes questions,
d'autant plus que les chiffres varient rapidement et sont instables (plage de + ou - 5 à 10°) , même si l'appareil est totalement au repos.

 

[zouriteman]

Dip

pour en revenir aux DIP , je découvre dans l'exemple cité ci-dessus , ceci :

activity.AddView(lbl, 10dip, 10dip + 50dip * i, 100%x - 10dip, 45dip)


le help contextuel de AddView indique que les 4 arguments sont des INT.

Nulle part j'ai vu qu'une constante nombre entier pouvait être écrite sous la forme 10dip , et pourtant cela compile OK !

Derriere cela, y a t il une astuce diabolique qui ferait que 10dip serait remplacé, à l'exécution , par un nombre variable fonction de la densité ?

 

[klaus]

Derriere cela, y a t il une astuce diabolique qui ferait que 10dip serait remplacé, à l'exécution , par un nombre variable fonction de la densité ?

Oui, diabolique je ne pense pas.

Un Button d'une largeur de 100dip aura:
densité / pixels
160 / 100 standard
120 / 75
240 / 150
320 / 200

Meilleures salutations.

 

[zouriteman]

autre exemple

et dans un autre exemple du forum, au sujet de la librairy animation , je trouve ceci :

panels(i).AddView(lbl, 20%x, 40%y, 60%x, 30dip)
Activity.AddView(panels(i), 100%x, 0, 100%x, 100%y - 60dip) 'add the panel to the layout

j'en cconclue qu'il y a des formules magiques non documentées,

car en essayant cela , je constate que
20%x positionne le label à 20% à gauche de l'écran (8 mm sur 40mm de large)

par contre le 40% en hauteur est faux , sauf si le 100%y-60dip reduit la hauteur véritable du panel : 18mm sur H=38 ou 46mm (47% ou 39%)

en conclusion, sommes nous sur la bonne voie pour maitriser les positions des composants ?


NOTA : par contre ces formules semblent uniquement valables avec des vraies constantes telles que 34%x
une formulation avec variable telle que :
dim JJJ as int
JJJ = 34
JJJ%x ne marche pas

 

[klaus]

20%x correspond à 20% de la largeur nette de l'écran (0.2*Activity.Width) et
20%y correspond à 20% de la hauteur nette de l'écran (0.2*Activity.Height).

dim JJJ as int
JJJ = 34%x
ça fonctionne.

La documentation peut être trouvée ici.
Documentation sur la libraire Phone.

Meilleures salutations.