Interfaces professionnelles avec Windows Mobile (Part 2)

Dans la première partie, nous avons vu un aperçu des problématiques et des limitations de Windows Mobile lors la création de formulaires.

Dans cette seconde partie, nous allons examiner les outils mis à notre disposition afin de créer des formulaires Windows Mobile et voir les avantages et les inconvénients de chacun.

A noter que les notions présentées ici sont valables en Windows Forms.

Designer de Visual Studio

Tout d’abord parlons de Visual Studio, et plus exactement de son éditeur de formulaire. Plutôt agréable et simple, très proche de l’éditeur de Windows Forms, il permet de créer très rapidement des formulaires. Son principal intérêt est qu’il permet d’avoir un aperçu des formulaire (voir la figure 1). Autre caractéristique tout aussi intéressante, vous pouvez modifier la propriété FormFactor des fenêtres afin de visualiser le résultat sur d’autres émulateurs.

 Figure 1 : Aperçu d’un formulaire dans Visual Studio.

Pour le reste, il suffit de faire glisser un contrôle depuis la Toolbox et de le positionner à l’endroit souhaité.

AutoScaleMode

Un des problématiques dans la création d’interface est la gestion des différentes résolutions : 320x240, 640*480 (VGA), 497x480 (QVGA), WVGA, etc.

Pourquoi est-ce un problème ? Tout simplement parce qu’un écran VGA est 2 fois plus grand qu’un écran classique. Pour qu’une interface garde le même aspect, il faudrait donc multiplier toutes les dimensions par 2. 

Heureusement les fenêtres réalisent automatiquement ce changement d’échelle lorsque la propriété AutoScaleMode de la fenêtre est positionnée à Dpi (valeur par défaut).

En résumé le problème de la résolution est considérablement réduit grâce à cette propriété et toutes les interfaces que vous réaliserez resterons identiques quelque soit la résolution du mobile.

Nous verrons plus tard que dans le cadre du développement de contrôle personnalisé que la notion d’AutoScale doit être prise en compte.

Positionnement

Si on devait simplifier, la conception d’une interface graphique revient à positionner et dimensionner des contrôles dans une fenêtre. Pour cela, vous avez plusieurs possibilités :

• Soit faire du positionnement manuel
• Soit faire du positionnement “automatique”

Pour illustrer mes propos j’utiliserais un formulaire très simple composé de trois éléments :

• Un Label positionné en haut du formulaire
• Un bouton positionné en bas du formulaire et centré horizontalement
• Une ListBox qui occupera l’espace restant dans la partie centrale

Positionnement manuel

Le positionnement manuel consiste à définir une position (Location) et une taille (Size) fixe. Le code pour le formulaire d’exemple ressemble à ceci :

this.label1.Location = new System.Drawing.Point(3, 0);

this.label1.Size = new System.Drawing.Size(234, 17);

this.listBox1.Location = new System.Drawing.Point(4, 21);

this.listBox1.Size = new System.Drawing.Size(233, 212);

this.button1.Location = new System.Drawing.Point(84, 245);

this.button1.Size = new System.Drawing.Size(72, 20);

Voici le résultat sur l’émulateur “Classic” en version portrait (à gauche), paysage (au centre) et sur l’émulateur “Square” (à droite).

Figure 2 : Positionnement manuel

Plusieurs problèmes se posent :

• Les marges (semi-automatiques avec le designer de VS) sont hétérogènes donnant une impression d’interfaces non finalisées.
• Le mode paysage ne fonctionne pas correctement
• Toutes les résolutions ne sont pas prise en charge

Les problèmes d’orientation d’écran et de résolutions sont parfaitement normaux étant donné que la position et la taille sont fixes.

Il existe un moyen simple pour contourner ce problème : les ancres (Anchor).

Les ancres peuvent être définies sur les 4 cotés (gauche, droite, bas, bouton) des contrôles à l’aide de la propriété Anchor des contrôles. Elles permettent de “coller” les côtés d’un contrôle aux côtés de son parent. Exemple, un bouton avec une ancre en bas à droite restera coller en bas à droite quelque soit la résolution ou l’orientation.

Si on modifie sensiblement notre exemple en ajoutant des ancres sur les trois contrôles :

this.label1.Anchor = AnchorStyles.Top | AnchorStyles.Left | AnchorStyles.Right;

this.listBox1.Anchor = AnchorStyles.Top | AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right;

this.button1.Anchor = AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right;

On obtient le résultat suivant :

Figure 3 : Positionnement manuel avec ancrage

Cette fois-ci, le résultat est satisfaisant.

D’une manière générale on utilise des ancres lorsqu’on fait du positionnement manuel.

Attention toutefois ce mode de positionnement à une limite : si un élément de l’interface change dynamiquement de taille, les autres éléments ne suivront pas ! De plus la gestion des marge avec Visual Studio est une véritable prise de tête, il faut généralement repasser derrière le Designer pour avoir quelque chose de plus propre.

Positionnement automatique

A la différence du positionnement manuel, le positionnement automatique ne vous permet de définir ni la position ni la taille des contrôles : c’est le système qui les calcule automatiquement.

Le positionnement automatique se fait en utilisant la propriété Dock. Le “docking” permet :

• D’empiler votre contrôles soit à droite, à gauche, en bas ou en haut
• ou de définir que votre prend tout l’espace disponible

La figure ci-dessous montre un exemple avec 5 contrôles qui utilisent les différents modes de docking.

Figure 4 : Différents modes de Dock

Donc si on “dock” une bouton en haut (figure 4):

• Sa position est (0, 0) soit en haut à gauche.
• Sa largeur est la largeur de l’écran et n’est pas modifiable
• Sa hauteur sera la hauteur que vous lui avez fixé.

Fonctionnalité intéressante : lorsqu’on dock plusieurs contrôles en haut (figure 5), les contrôles s’empilent les uns en dessous des autres.

Figure 5 : Plusieurs boutons dockés en haut

Voici le code et le résultat de l’interface de test avec du positionnement automatique.

this.label1.Dock = System.Windows.Forms.DockStyle.Top;

this.listBox1.Dock = System.Windows.Forms.DockStyle.Fill;

this.button1.Dock = System.Windows.Forms.DockStyle.Bottom;

Figure 6 : Positionnement automatique

Le résultat est correct sur les différentes résolutions et orientations d’écrans. Cependant on remarques plusieurs défauts :

• Le bouton prend toute la largeur de l’écran
• Les marges sont incorrectes : les contrôles sont collés au bord. 
• Un espacement excessif est mis entre le la liste et le bouton.

Il est possible de contourner le problème du bouton en utilisant un Panel :

• Le Panel est docké en bas
• Le bouton est positionné dans le Panel
• On utilise du positionnement manuel au niveau du bouton

A noter que le positionnement automatique a un avantage majeur : il prend dynamiquement en compte le changement de la taille des contrôles. Autrement dit, si un contrôle est redimensionné, la position des autres contrôles sera automatiquement ajustée.

Conclusion

Nous venons de voir qu’avec le positionnement manuel, l’utilisation d’ancre et quelques retouches on obtient un très bon résultat. Mais la modification de ce type d’interface est complexe.

A l’inverse avec le positionnement automatique il est très simple d’ajouter ou modifier des contrôles : l’affichage se mettra automatiquement à jour. Malheureusement le système calculant tout automatiquement, on n’obtient pas toujours le résultat attendu.

Généralement si j’en restais là, je vous conseillerais d’utiliser à la fois le positionnement manuel et automatique.

Mais je ne vais pas m’arrêter là car ce mécanisme n’est pas satisfaisant. L’objectif ici est de créer des interfaces professionnelles, homogènes, intelligentes, simple à créer, simple à manipuler et maintenables.

Rendez-vous donc dans la prochaine partie où nous verrons comment faire mieux en prenant le meilleurs des deux types de positionnements que nous venons de voir (oui il y aura du code !).

D’ici quelques jours, vous pourrez retrouver cet article (et bien d’autres) sur le site de Bewise.