De 4 à 40″ : développer des applications Windows sur plusieurs form factors

Session originale : From 4 to 40 inches: Developing Windows Applications across Multiple Form Factors

Plus grand écran = plus de pixels = plus de contenu
Plus grand dpi = plus de pixels = meilleurs graphismes

Ces deux constats sont vrais mais cachent une certaine complexité, notamment avec l’arrivée de Windows Phone 8.1 qui amène son lot de changements. S’adapter à tous les formats et résolutions n’est pas toujours évident, nous allons aborder les points clés à retenir et quelques techniques.

La mise à jour de Windows Phone Silverlight 8.0 à Silverlight 8.1 se fait sans douleur et conserve globalement la même résolution qu’auparavant.

Par exemple, que ce soit en WXGA ou WVGA, on reste sur du 480×800, indépendamment de la résolution. Ce comportement est conservé avec Silverlight 8.1, et le support des écrans larges est facultatif (plus d’informations ici : https://aka.ms/WpSLLarge). Ceci est valable pour WP Silverlight et demeure différent pour les Windows Phone Store Apps.

Agenda

• Layout : Positionner les éléments graphiques sur l’écran
  • Taille physique et format
  • Distance de vue
  • Résolution effective
• Assets : Images, vidéos et autres graphismes
  • Niveau de détails
  • Scale Factor
  • Maîtrise

LAYOUT

Taille et forme

La taille d’une application est importante (pas la résolution)
Le format d’affichage est importante (pas l’orientation)

Le plus important est de s’adapter à la taille et format de l’application. Sur Windows 8.1, une application peut être redimensionnée jusqu’à 320 px de largeur minimum. Entre 320 et 500px, on n’a pas la même place ou la même orientation qu’entre 500 et 800px. Il convient d’adapter le contenu pour occuper tout l’espace sans être étriqué. Chaque format (portrait, paysage, carré, colonne) doit proposer un affichage adapté.

Distance de vue

Les objets proches semblent plus larges que ceux qui sont éloignés. Il s’agit d’une question de perspective toute simple et pourtant pas toujours évidente.

Résolution effective

La résolution effective représente la résolution physique normalisée au dpi courant. A 96 dpi, la résolution effective est la même que la résolution physique. Dans d’autres dpis, la résolution effective doit être redimensionnée proportionnellement.

Concrètement, un écran de téléphone situé à 1 mètre semble avoir la même taille qu’un écran 40″ de TV à 5m. Pour obtenir un contenu à la même taille selon ce point de vue, Windows s’adapte automatiquement et par exemple affichera le contenu à 100% sur le téléphone, et à 200% sur la TV.

Ceci embrasse le concept de distance de vue.

La résolution effective est importante (pas la taille de l’app)

Démonstration

La démo montre l’utilisation des VisualStates pour changer l’apparence de l’application et s’adapter à taille de l’app. On y retrouve des VisualStates pour chaque format : Wide, Square, Thin, Rail.

Une classe helper a été développée pour l’exemple : LayoutRulesBasedPage. En passant un ensemble de règle en paramètres, cette simple classe permet de basculer sur le bon VisualState.

Exemple de règle :

• WidthLayoutRule : règle basée sur la largeur de l’application (MinWidth) et qui bascule sur un VisualState donné (VisualStateName)

Construire des applications responsives

• Ajuster le layout en fonction de la taille disponible et la forme
• Séparer proprement la vue du modèle ne fait pas de mal (MVVM)

ASSETS

Niveau de détails

La taille de l’image est importante et embarque un certain nombre de détails.

Redimensionner une grande icône pleine de détails pour une version plus petit ne délivre pas le même niveau d’information, il y a de la perte.

Plusieurs représentations peuvent être nécessaires en fonction de la taille, pour continuer à voir les détails qui sont importants. Si l’asset est petit, il vaut mieux produire une icône sémantiquement équivalente mais avec moins de détails, pour qu’elle reste compréhensible.

Scale Factors

La densité relative des pixels est importante (pas le DPI)

En fonction du scaling de l’OS, on peut fournir des assets qui correspondent grâce à une nomenclature simple : “monimage.scale-240.png” où 240 représente le scale factor. Le système choisit automatiquement l’asset lorsque l’affichage correspond à ce scale factor.

Attention à bien spécifier la taille de l’image en XAML/HTML pour éviter que le système redimensionne l’image au lieu de prendre l’image correspondante.

La génération d’assets en quelques étapes :

• Déterminer la taille du layout désiré (en pixel effectifs)
• Générer les assets dans cette taille (pour le Shared Project)
• Multiplier la taille du layout par 2.4
• Générer les assets dans cette taille (pour Phone uniquement)
• Visualiser le résultat sur un téléphone
  • L’émulateur est insuffisant pour vérifier les assets, toujours vérifier sur un téléphone !
• Si ça semble bon, c’est terminé !
• Sinon, tenter avec d’autres scales factors (par ex. 1.4 ou 1.8)

Assets originaux

Il faut toujours conserver des assets originaux dans la meilleure résolution possible, idéalement il vaut mieux utiliser du vectoriel. Autrement, générer des bitmaps avec un scaling supérieur à 400% par rapport à ce qui est utilisé.

Exporter au bon scale factor en fonction du besoin, et ne pas oublier le niveau de détail minimum !

Et le code dans tout ça ?

On n’a jamais parlé de taille physique ou résolution de device.
On n’a jamais parlé de code.

Dans la plupart des cas, le code n’intervient pas dans l’affichage, mis à part via les VisualStates.

Une APIs qui peuvent servir :

• DisplayInformation.GetForCurrentView()
  • ResolutionScale : scale factor (enum) pour Windows
  • RawPixelsPerViewPixel : scale factor (double) pour Windows Phone
  • RawDpiX, RawDpiY : ignorer à moins de mesurer des objets réels (règles ou autre)
  • LogicalDpi : éviter à moins de travailler en Direct2D ou code hérité qui suppose un dpi de 96

En résumé

• Utilisez le bon vocabulaire !
  • Bon : résolution effective / format d’affichage / scale factor
  • Mauvais : résolution physique / orientation / DPI
• Architecturez pour un design flexible
• • Préférez des parties de composants vs pages monolithiques
  • Laissez le système travailler pour vous
• Concentrez-vous sur des assets au bon format
  • Commencez avec les originaux en haute résolution
  • Générez uniquement les scale factors dont vous avez besoin (par ex. 100% et 240%)
  • Assurez-vous d’un niveau de détail approprié