Partager via

Résumé du chapitre 5. Gestion des tailles

  • Article

Remarque

Ce livre a été publié au printemps 2016 et n’a pas été mis à jour depuis. Il y a beaucoup dans le livre qui reste précieux, mais certains documents sont obsolètes, et certains sujets ne sont plus entièrement corrects ou complets.

Jusqu’à présent, plusieurs tailles Xamarin.Forms ont été rencontrées :

  • La hauteur de la barre d’état iOS est de 20
  • La BoxView largeur et la hauteur par défaut sont 40
  • La valeur par défaut Padding dans un Frame est 20
  • La valeur par défaut Spacing est StackLayout 6
  • La Device.GetNamedSize méthode retourne une taille de police numérique

Ces tailles ne sont pas des pixels. Au lieu de cela, ils sont des unités indépendantes des appareils reconnues indépendamment par chaque plateforme.

Pixels, points, dps, DIPs et DIUs

Au début des histoires du Mac Apple et de Microsoft Windows, les programmeurs ont travaillé en unités de pixels. Toutefois, l’avènement d’affichages à résolution supérieure nécessite une approche plus virtualisée et abstraite des coordonnées d’écran. Dans le monde Mac, les programmeurs ont travaillé en unités de points, traditionnellement 1/72 pouces, tandis que les développeurs Windows utilisaient des unités indépendantes des appareils (DIU) basées sur 1/96 pouces.

Toutefois, les appareils mobiles sont généralement beaucoup plus proches du visage et ont une résolution plus élevée que les écrans de bureau, ce qui implique qu’une plus grande densité de pixels peut être tolérée.

Les programmeurs ciblant Apple i Téléphone et les appareils iPad continuent de fonctionner en unités de points, mais il y a 160 de ces points au pouce. Selon l’appareil, il peut y avoir 1, 2 ou 3 pixels au point.

Android est similaire. Les programmeurs fonctionnent en unités de pixels indépendants de la densité (dps), et la relation entre dps et pixels est basée sur 160 dps à pouce.

Les téléphones Windows et les appareils mobiles ont également établi des facteurs de mise à l’échelle qui impliquent quelque chose de près de 160 unités indépendantes de l’appareil au pouce.

Remarque

Xamarin.Forms ne prend plus en charge un téléphone windows ou un appareil mobile.

En résumé, un Xamarin.Forms programmeur ciblant les téléphones et tablettes peut supposer que toutes les unités de mesure sont basées sur le critère suivant :

  • 160 unités au pouce, équivalent à
  • 64 unités au centimètre

Les propriétés en lecture seule Width et Height définies par VisualElement défaut ont des valeurs « fictives » de –1. Uniquement lorsqu’un élément a été dimensionné et pris en charge dans la disposition, ces propriétés reflètent la taille réelle de l’élément dans les unités indépendantes de l’appareil. Cette taille inclut n’importe quel Padding jeu sur l’élément, mais pas le Margin.

Un élément visuel déclenche l’événement SizeChanged lorsqu’il HeightWidth a changé. L’exemple WhatSize utilise cet événement pour afficher la taille de l’écran du programme.

Tailles métriques

MetricalBoxView utilise WidthRequest et HeightRequest affiche un BoxView pouce de haut et un centimètre de large.

Tailles de police estimées

L’exemple FontSizes montre comment utiliser la règle de 160 unités à pouces pour spécifier des tailles de police en unités de points. La cohérence visuelle entre les plateformes utilisant cette technique est meilleure que Device.GetNamedSize.

Ajustement du texte à la taille disponible

Il est possible d’ajuster un bloc de texte dans un rectangle particulier en calculant un FontSize des Label critères suivants :

  • L’espacement des lignes est de 120 % de la taille de police (130 % sur les plateformes Windows).
  • La largeur moyenne des caractères est de 50 % de la taille de police.

L’exemple EstimatedFontSize illustre cette technique. Ce programme a été écrit avant la disponibilité de la Margin propriété. Il utilise donc un PaddingContentView paramètre pour simuler une marge.

Capture d’écran triple de la taille de police estimée

Horloge adaptée à la taille

L’exemple FitToSizeClock montre comment Device.StartTimer démarrer un minuteur qui avertit régulièrement l’application lorsqu’il est temps de mettre à jour l’horloge. La taille de police est définie sur un sixième de la largeur de page pour rendre l’affichage aussi grand que possible.

Problèmes d’accessibilité

Le programme EstimateFontSize et le programme FitToSizeClock contiennent tous deux un défaut subtil : si l’utilisateur modifie les paramètres d’accessibilité du téléphone sur Android ou Windows 10 Mobile, le programme ne peut plus estimer la taille du texte en fonction de la taille de la police. L’exemple AccessibilityTest illustre ce problème.

Texte empiriquement adapté

Une autre façon d’ajuster le texte à un rectangle consiste à calculer empiriquement la taille du texte rendu et à l’ajuster vers le haut ou vers le bas. Le programme dans le livre appelle GetSizeRequest un élément visuel pour obtenir la taille souhaitée de l’élément. Cette méthode a été déconseillée et les programmes doivent plutôt appeler Measure.

Pour un Label, le premier argument doit être la largeur du conteneur (pour autoriser l’habillage), tandis que le deuxième argument doit être défini pour Double.PositiveInfinity rendre la hauteur non contrainte. L’exemple EmpiriqueFontSize illustre cette technique.