Développement Windows Mobile 6.x : Gestion des Forms & Machines d'états
Introduction :
Dans cet article, je vais vous présenter la méthode que j’utilise pour gérer l’apparition des différents écrans d’une application mobile…
Cela fait longtemps que j’utilise cette manière particulière de construire des interfaces mobiles, et je vous la recommande fortement. En effet, nous allons voir ensemble quels sont les avantages que nous pouvons en tirer…
Une Form = plusieurs écrans ??
Oublions tout de suite certains principes qui consistent à dire qu’une Form correspond systématiquement à un et un seul écran (développement Windows, Web, etc…).
Pour le développement mobile, je vous propose une autre approche : voir les Forms comme des machines d’états.
Partons du principe qu’une Form ne correspond plus à un unique écran, mais à une petite collection d’écrans qui concernent tous un même process métier.
En effet, une Form peut facilement être découpée en plusieurs panels différents qu’il suffirait d’afficher ou de masquer selon les actions de l’utilisateur sur l’interface graphique.
La notion de Form n’est donc plus liée à un écran particulier mais plutôt à un groupe d’écrans faisant parti du même processus logique.
Exemple :
Process “Choix d’une intervention”. 1 Form = 3 écrans
Quels avantages pouvons-nous en tirer ?
Grâce à ce regroupement, nous affichons le panel correspondant au choix de l’utilisateur, c'est-à-dire lorsqu’il clique sur un bouton de navigation.
Au lieu de changer d’écran, on change cette fois de panel. Le panel précédent se masque et le nouveau s’affiche, et c’est tout : nous ne construisons aucun écran, nous effectuons juste un affichage / masquage de panels.
Cette décomposition permet donc d’assurer une fluidité optimale dans un process particulier.
En effet, l’application charge plusieurs écrans à la fois et cela évite donc les temps de chargement au sein d’un même process. L’utilisateur sera donc ravi de bénéficier d’une rapidité optimale durant la totalité de son process. Par contre, il est évident qu’un groupe complet d’écrans est plus long à charger, mais c’est un “mal pour un bien”.
Il est à noter que cette méthodologie garantie également une meilleure stabilité du système.
Comment procéder ?
Les différentes Forms d’une application peuvent donc être regroupées en plusieurs panels.
Il est alors question de ne plus penser “écran” mais plutôt “process” afin de diviser au mieux et de former des groupes logiques d’écrans mobiles.
Une fois les groupes identifiés, il s’agit d’étirer la longueur d’une Form dans Visual Studio pour venir y placer les différents panels qui la composeront.
Les écrans les moins utilisés, quant à eux, pourront être détachés des groupements. Le fait de les créer (instruction “new”) à chaque affichage s’effectuera de manière occasionnelle et ne sera donc pas trop gênant pour l’utilisateur. Cela concerne par exemple les écrans des transferts de fichiers, de saisie de commentaires exceptionnels, ou d’autres fonctionnalités spéciales…
Au niveau du code de l’application, cela se traduit de la manière suivante :
-
Une classe complète pour la totalité de la Form que nous pouvons même décomposer avec un système de “régions” ou de “classes partielles” pour plus de clarté.
-
Une énumération principale des panels qui composent l’écran.
-
Une méthode de gestion servant à l’affichage d’un panel. Cette méthode doit prendre en paramètre un panel de l’énumération, pour le centrer et le rendre visible, et doit masquer l’ensemble des autres panels.
Exemple :
La méthode “ShowPanel” exposée ci-dessous permet de gérer facilement l’affichage et le masquage d’écrans au sein d’une même Form en se basant sur une énumération de panels :
private enum PanelEnum { None, PanelInfos, PanelAbout };
private PanelEnum _currentPanel;
///
/// Show and hide panels
///
/// The panel to show
private void ShowPanel(PanelEnum panel)
{
Panel crtPanel = null;
_currentPanel = panel;
pnlInfos.Visible = false;
pnlAbout.Visible = false;
if (_currentPanel == PanelEnum.PanelInfos)
{
crtPanel = pnlInfos;
}
if (_currentPanel == PanelEnum.PanelAbout)
{
crtPanel = pnlAbout;
}
if (crtPanel != null)
{
crtPanel.Visible = true;
crtPanel.Size = new Size(Screen.PrimaryScreen.WorkingArea.Width,
Screen.PrimaryScreen.WorkingArea.Height);
crtPanel.Location = new Point(0, 0);
crtPanel.BringToFront();
}
}
Avec la méthode “ShowPanel”, le basculement d’écran s’effectue rapidement en indiquant le panel précis à afficher suite à une action utilisateur :
private void btnAfficheEcranInfos_Click(object sender, EventArgs e)
{
ShowPanel(PanelEnum.PanelInfos);
}
Empilage de Forms :
D’autre part, il est important de signaler que dans le cadre d’applications mobiles, il est préférable, par mesure de stabilité, d’afficher les Forms à l’aide de la méthode “ShowDialog”.
Au final, cela signifie que les Forms sont constamment “empilées” ou “dépilées” selon les actions de l’utilisateur.
Exemple :
Interprétation :
(1) : Form “FormLogin”
(2) : Empilage de la Form “FormMenuPrincipal” suite à la connexion de l’utilisateur
(3) : Empilage de la Form “FormChoixIntervention” suite au choix de l’utilisateur de réaliser une intervention.
(4) : Empilage de la Form “FormCollectionMgtProcess” suite à la validation et au choix de l’intervention à réaliser.
Lorsque l’utilisateur mettra un terme à son rapport d’intervention, les deux dernières Forms vont être “dépilées” (méthode Close) et l’utilisateur reviendra ainsi sur le menu principal de l’application (2).
Conclusion :
La méthodologie que j’utilise pour construire des interfaces mobiles est celle que je viens de vous présenter. Elle consiste en 2 principales étapes :
Les avantages :
-
Découpage logique de processus.
-
Aucun temps de chargement d’écrans au sein d’un même process (rapidité de navigation optimale pour l’utilisateur).
-
Stabilité du système amélioré.
N’hésitez pas à me faire part de vos remarques concernant cette méthodologie. De la même façon, n’hésitez pas à me faire part de vos expériences personnelles.
Pi-R.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
