La vie errante
Applications adaptables pour Windows Mobile
Michael Saffitz
Sommaire
Lorsque Microsoft a publié Pocket PC 2000 (et même durant les quelques années qui ont suivi) les développeurs pouvaient écrire relativement facilement une application qui s'exécutait bien sur tous les périphériques. Tous les périphériques avaient plus ou moins les mêmes fonctionnalités et caractéristiques : prise en charge tactile, résolutions d'écran, orientation portrait, ensembles d'API, etc. Par conséquent, vous pouviez vous concentrer presque exclusivement sur les fonctionnalités de votre application. Vous n'aviez pas besoin de vous soucier des autres éléments du périphérique ni certainement de leur modification éventuelle.
Mais le changement est inévitable. À mesure que le marché et la technologie se sont développés, de plus en plus de périphériques mobiles étaient disponibles avec des conceptions différentes. On arrive rapidement à 2008 et il existe maintenant plus de 140 différents téléphones Windows Mobile® disponibles qui prennent en charge une variété d'options, les claviers à 12 touches et claviers QWERTY, les styles « candy bar » et « clam shell », avec et sans GPS, les écrans carrés, portrait et paysage, les communications Wi-Fi, Bluetooth et infrarouges et d'autres fonctionnalités qui varient d'un périphérique à l'autre. Contrairement à Pocket PC 2000, il est maintenant beaucoup plus facile pour les clients de trouver un périphérique mobile qui correspond à leurs besoins, goûts et budget.
Applications adaptables
Cependant, les périphériques Windows Mobile devenant de plus en plus diversifiés, les développeurs ont dû prendre conscience de ces différences et les planifier dans leurs applications. Ils doivent maintenant créer ce qu'on appelle des applications adaptables, bien présentées et qui fonctionnent sur tous les périphériques Windows Mobile.
En tant que système d'exploitation, Windows Mobile offre l'un des ensembles d'API de base les plus cohérents de la plate-forme mobile sur tous les périphériques. Les développeurs Windows Mobile trouveront le même ensemble d'API de base (souvent conçues pour correspondre à celles de votre bureau) quel que soit l'opérateur du périphérique mobile ou le fabricant de matériel.
Par conséquent, la plupart des développeurs qui créent des applications adaptables découvriront qu'ils devront se concentrer sur la prise en charge de plusieurs résolutions d'affichage, des points par pouce (ppp) et des orientations. Pour un plus petit nombre de développeurs, les différences de fonctionnalités des périphériques (comme la présence de téléphonie, de GPS, etc.), les modifications d'API entre les versions majeures de Windows Mobile et la conception ciblant les périphériques à écran tactile et non tactiles seront également des domaines à prendre en considération.
Je vous présenterai certains outils et techniques que les développeurs peuvent utiliser pour créer des applications adaptables. J'examinerai certaines conceptions générales et certains principes d'architecture et m'intéresserai à l'adaptation aux différences d'écrans et de fonctionnalités.
Alors que certains éléments doivent être pris en compte lorsque vous choisissez de créer une application adaptable, les avantages de l'investissement premier sont souvent beaucoup plus importants que l'alternative : développer et tester une version de votre application par rapport à un périphérique actuel (et futur) ou choisir de ne pas prendre en charge un périphérique et ainsi, limiter votre base d'utilisateurs potentiels.
Conception et architecture
Lors de la création d'applications adaptables, il est essentiel de suivre des méthodes éprouvées et de bons modèles architecturaux. Du point de vue des méthodes, si vous déterminez soigneusement et explicitement vos exigences, vous serez en mesure de comprendre le profil de périphérique minimal dont votre application a besoin. Vous déterminerez également les fonctionnalités facultatives que votre application peut utiliser de manière dynamique. En adoptant cette approche, vous pouvez être sûr que votre application s'exécutera sur le plus grand nombre de périphériques sans avoir à coder jusqu'au plus petit dénominateur commun.
Supposons par exemple qu'on me demande de créer une application simple de suivi de livraison de colis. J'ai examiné mes exigences et déterminé que je dois recueillir une signature pour indiquer qu'un colis a été livré avec succès. Comme fonctionnalité pratique, mais non essentielle, l'application doit envoyer l'état du colis à un serveur pour un suivi en ligne. En raison du besoin d'une signature, mon application sera limitée aux périphériques tactiles (Windows Mobile Professional et Classic). Ayant identifié cela, je suis maintenant libre d'utiliser la fonctionnalité supplémentaire nécessitant un écran tactile (comme le contrôle Button).
En même temps, je dois faire attention en élaborant les composants de connectivité. Si je pense que mon application aura accès aux connexions de données cellulaires, par exemple, j'élimine inutilement les périphériques Classic qui ne contiennent pas un téléphone mais peuvent disposer d'une connexion Wi-Fi.
Finalement, vous devez noter que si mon client change d'avis et supprime l'exigence de signature, je ne pourrai pas forcément prendre en charge des périphériques non tactiles (Window Mobile Standard), étant donné l'utilisation ultérieure du contrôle Button.
Différences d'affichage
Comme mentionné précédemment, les différences de résolutions d'écran, de ppp et d'orientation sont souvent les problèmes les plus préoccupants lors de la création d'applications adaptables. Ici aussi, la planification de ces différences et l'analyse particulière de votre architecture aura un impact significatif lors de l'implémentation de votre solution.
Les résolutions Windows Mobile 6, les ppp, les orientations et les dimensions d'icône prises en charge sont illustrées à la figure 1. Outre ces éléments, Microsoft ajoute parfois de nouvelles configurations, des fabricants OEM (Original Equipment Manufacturers) et des opérateurs mobiles. En outre, certains périphériques prennent en charge la rotation d'orientation d'écran dynamique. Par exemple, un périphérique avec un affichage portrait 240×320 peut pivoter vers un affichage paysage 320×240 lorsque sont clavier est coulissant.
Figure 1 Options d'affichage de Windows Mobile 6
| Windows Mobile Professional et Classic (avec écran tactile) |
| Résolution |
ppp |
Orientation |
Petite icône |
Grande icône |
| 240×240 |
96 |
Carré |
16×16 |
32×32 |
| 240×320 |
96 |
Portrait et paysage |
16×16 |
32×32 |
| 240×400 |
96 |
Portrait et paysage |
16×16 |
32×32 |
| 320×320 |
128 |
Carré |
21×21 |
43×43 |
| 480×480 |
192 |
Carré |
32×32 |
64×64 |
| 240×240 |
192 |
Portrait et paysage |
32×32 |
64×64 |
| 240×240 |
192 |
Portrait et paysage |
32×32 |
64×64 |
| Windows Mobile Standard (sans écran tactile) |
| Résolution |
ppp |
Orientation |
Petite icône |
Grande icône |
| 176×220 |
96 |
Portrait |
16×16 |
32×32 |
| 240×320 |
131 |
Portrait et paysage |
22×22 |
44×44 |
| 320×320 |
131 |
Carré |
22×22 |
44×44 |
| 240×400 |
131 |
Portrait et paysage |
22×22 |
44×44 |
| 440×240 |
131 |
Paysage |
22×22 |
44×44 |
Plus que jamais, il est essentiel que votre application ne possède pas une ou plusieurs caractéristiques d'écran mais plutôt qu'elle soit écrite pour s'adapter de manière dynamique et prendre en charge toutes les résolutions, orientations et au moins 96 ppp et 131 ppp. (192 ppp est important également, mais cette résolution est souvent limitée à un nombre très restreint de périphériques. 128 ppp est assez proche de 131 ppp pour ne pas causer de problèmes majeurs).
Il existe plusieurs ressources et outils disponibles pour le développement d'applications natives et gérées qui simplifient cette tâche. J'examinerai quelques uns d'entre eux et passerai en revue certaines approches générales et certaines méthodes recommandées que vous pouvez utiliser dans le processus de création d'applications gérant la résolution.
Gestion de la résolution des applications natives
Le kit de développement logiciel Windows Mobile 6 fournit deux ressources principales pour créer des applications prenant en charge la résolution dans le code natif : la classe réutilisable ScreenLib dans l'exemple UILayout et l'en-tête DeviceResolutionAware.h. L'exemple UILayout se trouve dans le répertoire \Samples\Common\CPP\Win32 du kit de développement logiciel Windows Mobile. DeviceResolutionAware.h est installé dans le répertoire \VC\ce\atlmfc\include du répertoire d'installation Microsoft® Visual Studio®.
ScreenLib fournit une série de fonctions d'assistance pour aligner des éléments à l'écran. Par exemple, vous pouvez utiliser la fonction DockControl pour ancrer un contrôle donné à un bord d'écran, ou aux quatre bords, en remplissant la zone client. Les fonctions OptimizeWidth et OptimizeHeight alignent et redimensionnent un contrôle (ou plusieurs contrôles, dans le cas d'OptimizeWidth) avec l'affichage, en laissant une petite marge à gauche et à droite ou en haut et en bas, respectivement. Il existe des fonctions supplémentaires qui permettent l'alignement des contrôles et le redimensionnement d'une série de contrôles à la même taille. Grâce à ces fonctions, ScreenLib tend à être plus utile lorsque l'on utilise de manière intensive des applications basées sur les formulaires.
DeviceResolutionAware.h commence là où ScreenLib s'arrête et fournit plus de 20 fonctions et macros qui permettent de créer des applications adaptables plus complexes. Celles-ci démarrent avec les fonctions et les macros de base qui fournissent des blocs de construction pour les interfaces utilisateur adaptables comme GetDisplayMode (qui fournit des caractéristiques et des fonctionnalités d'affichage).
Vous trouverez SCALEX, SCALEY, SCALERECT et SCALEPT, qui mettent à l'échelle les valeurs de façon appropriée pour la résolution actuelle. Ensuite, il y a des fonctions comme StretchIcon et ImageList_StretchBitmap, qui permettent de mettre à l'échelle des images pour les caractéristiques d'affichage actuelles. Les fonctions comme RelayoutDialog peuvent être utilisées pour ajuster automatiquement la disposition d'une boîte de dialogue lorsqu'une modification d'orientation survient.
ScreenLib et DeviceResolutionAware.h fournissent une base solide pour créer vos applications qui prennent en charge la résolution. En même temps, cependant, il est important de noter qu'ils ne peuvent pas se substituer aux conceptions et solutions qui peuvent être propres à vos situations, surtout en cas d'interaction directe avec le tampon d'affichage ou de création d'une interface utilisateur complexe.
Gestion de la résolution des applications gérées
Pour les applications de code géré, Microsoft .NET Compact Framework fournit une série de propriétés d'affichage qui peuvent vous aider lors de la création d'applications prenant en charge la résolution. Comme la fonctionnalité de ScreenLib, .NET Compact Framework fournit une propriété Control.Dock qui liera le contrôle spécifié à un bord de son parent. Control.Anchor fournit une fonctionnalité similaire en liant un contrôle à une distance fixe d'un bord de son parent. L'utilisation de la propriété Control.AutoScroll ajoutera automatiquement une barre de défilement si les contrôles du formulaire ne s'ajustent pas à l'affichage. De plus, Contrôle.AutoScale assure le suivi de la résolution pour lequel le formulaire a été conçu et il mettra à l'échelle de manière dynamique le formulaire si les ppp ou la résolution changent. Comme vous pouvez l'imaginer, la propriété Contrôle.AutoScale fonctionne bien pour les formulaires plus simples, mais comme vos formulaires deviennent plus complexes, la magie qu'elle peut opérer devient plus limitée.
Pour les formulaires plus complexes, ces propriétés fournissent un point de départ, mais ils ne constituent pas nécessairement une solution complète, surtout quand il s'agit de s'adapter de manière dynamique aux modifications d'orientation. Une approche consiste à utiliser OAC (Orientation Aware Control) publié par le groupe Microsoft patterns & practices dans le cadre de Mobile Client Software Factory (
msdn2.microsoft.com/library/aa480471). L'OAC permet de cibler facilement plusieurs orientations, surtout pour les applications basées sur les formulaires.
Une fois installé, l'OAC vous permet d'utiliser le concepteur de formulaires gérés dans Visual Studio pour disposer votre interface utilisateur en mode Portrait et, à l'aide de l'OAC, pivoter vers le mode Paysage. Une fois cette nouvelle orientation choisie, vous pouvez ajuster votre interface utilisateur au mode Paysage. L'OAC assurera le suivi des modifications pour que la disposition appropriée soit utilisée au moment de l'exécution lorsque l'utilisateur final sera en mode Portrait ou Paysage.
L'utilisation de l'OAC présentent cependant des inconvénients. Tout d'abord, il vous permet essentiellement de concevoir une orientation spécifique et des combinaisons de résolution. Cette approche n'est pas recommandée puisque les orientations et les résolutions prises en charge sont susceptibles de changer. En outre, il ne vous permet pas de concevoir explicitement des ppp différents ou des écrans carrés qui sont devenus populaires récemment sur les périphériques smartphone basés sur Windows Mobile Standard. Enfin, étant donné que l'OAC crée et gère plusieurs dispositions pour chacun de vos écrans, il y a une dégradation des performances qui devient plus importante à mesure que vous ajoutez des formulaires et de la complexité (à l'extrême, cela peut augmenter sensiblement le temps de lancement de votre application).
En raison de ces inconvénients, l'équipe de Windows Mobile a encouragé les développeurs à s'éloigner de l'OAC. Le groupe publie une nouvelle version de Windows Mobile Line of Business Accelerator (
go.microsoft.com/flint/?LinkId=115317) qui inclut un composant permettant de créer des applications gérant la résolution, qui disposent d'une interface utilisateur unique et intègrent l'ancrage et d'autres techniques.
Différences de base des périphériques
Malgré les divers outils, et même avec le nouvel accélérateur, il n'existe pas de solution unique pour écrire des applications adaptables. Chaque approche a des avantages et des inconvénients qui doivent être évalués en fonction de vos besoins et de votre situation. Mais quelle que soit l'approche que vous adoptez, certaines indications générales peuvent être utiles.
Commencez avec les trois orientations de base, carré, Portrait et Paysage et pensez à la manière dont vous disposerez votre interface utilisateur pour chacune d'entre elles. Ensuite, vous pouvez vous concentrer sur la mise à l'échelle de votre interface utilisateur dans les différentes résolutions et différents ppp. Pour une interface utilisateur complexe, il peut être plus facile d'ajuster la conception et de l'étendre à plusieurs formulaires que de la garder sur un seul formulaire et la réorganiser lorsqu'une modification d'orientation est effectuée.
À mesure que vous implémentez votre application pour une adaptation visuelle, il deviendra encore plus important d'avoir une séparation nette entre votre interface utilisateur et la logique de votre application. En pensant à votre interface utilisateur comme points d'interaction et en évitant une approche reposant sur des formulaires, vous pouvez encapsuler vos éléments d'interface utilisateur dans des classes de gestion qui centralisent et analysent comment ces éléments sont mappés vers les formulaires individuels.
Il peut être tentant de concevoir exclusivement pour les écrans carrés, en ancrant les contrôles en haut et à gauche, en offrant un type d'adaptabilité permettant de réduire les orientations portrait et paysage à un carré. Mais lorsque vous faites cela, vous retirez à votre application et à l'utilisateur entre un tiers et deux tiers d'espace d'écran potentiel. En outre, ce qui paraît faire gagner du temps de développement peut finir par prendre plus de temps, avec encore moins d'espace d'écran, vous êtes obligé de concevoir votre interface utilisateur de manière plus rigoureuse ou d'inclure des écrans supplémentaires.
Autres différences de périphériques
Alors que la résolution des différences dans les caractéristiques d'affichage est souvent la partie la plus importante de l'écriture d'applications adaptables, il existe également d'autres aspects. La version de Windows Mobile est importante, puisque les API ont été introduites, modifiées et sont devenues obsolètes au cours des années. Il existe des fonctionnalités propres aux périphériques mobiles que vous pouvez utiliser lorsqu'elles sont disponibles.
Pour celles-ci et d'autres situations, il est toujours possible d'écrire des applications d'une façon qui leur permet de s'exécuter sur tous les périphériques. Une technique que vous devez prendre en considération, c'est le modèle de fabrique, surtout en combinaison avec les interfaces qui définissent les fonctionnalités de base et disposent d'implémentations propres aux périphériques mobiles.
Examinons un simple exemple qui inclut certaines conceptions et exigences rassemblant des méthodes abordées précédemment. On m'a demandé de créer le guide d'une ville comprenant des critiques de restaurants. Mes exigences principales sont d'inclure un répertoire de restaurants et de revues et la possibilité de sélectionner et d'afficher un restaurant spécifique et de lire sa critique. Mon application doit s'exécuter sur Windows Mobile 2003 et versions ultérieures. Enfin, lorsque j'utilise un périphérique qui fournit la téléphonie, j'ai une exigence qui consiste à appeler directement le restaurant à partir de l'écran de la critique.
Pour cet exemple, j'utiliserai C#, mais les concepts présentés sont applicables également en Visual Basic® et C++. Les API de téléphonie gérées ont été d'abord introduites dans Windows Mobile 5.0 et. Par conséquent, mon application devra savoir sur quelle version de Windows Mobile elle s'exécute et utiliser l'implémentation appropriée.
Je commencerai par créer une interface de téléphonie qui définit la fonctionnalité courante dont j'ai besoin, quels que soient le périphérique et l'implémentation spécifique :
interface ITelephony {
bool HasPhone {
get;
}
void MakeCall(string phoneNumber);
}
Ensuite, la figure 2 présente mes deux implémentations, une pour les périphériques avant Windows Mobile 5.0 et une pour les périphériques exécutant Windows Mobile 5.0 ou version ultérieure. Par souci de concision, j'ai omis P/Invoke qui est requis sur les périphériques avant Windows Mobile 5.0.
Figure 2 Implémentation de ITelephony
class PreWindowsMobile5 : ITelephony {
public bool supportsTelephony {
get { return File.Exists(@"\Windows\Phone.dll"); }
}
public void MakeCall(string phoneNumber) {
// call Native Phone API
}
}
class PostWindowsMobile5 : ITelephony {
public bool supportsTelephony {
get { return SystemState.PhoneRadioPresent; }
}
public void MakeCall(string phoneNumber) {
Phone thePhone = new Phone();
thePhone.Talk(phoneNumber);
}
}
Enfin, je créerai une classe TelephonyFactory qui centralise et isole les différentes implémentations à partir de la logique de base de mon application (voir la figure 3). Pour cet exemple, j'ai choisi que ma classe TelephonyFactory identifie si le périphérique prend en charge la téléphonie et, dans les cas où celle-ci n'est pas prise en charge, lance une exception. Maintenant, lorsque je souhaite utiliser la téléphonie dans mon application, il me suffit d'exécuter la commande suivante :
try {
ITelephony myTelephony =
TelephonyFactory.GetTelephony();
myTelephony.MakeCall(phoneNumber);
}
...
Figure 3 TelephoneFactory
class TelephonyFactory {
static ITelephony _myTelephony = null;
public static ITelephony GetTelephony() {
if (_myTelephony == null) {
if (Environment.OSVersion.Version.Major >= 5)
myTelephony = new PostWindowsMobile5();
else
myTelephony = new PreWindowsMobile5();
}
if ( ! myTelephony.supportsTelephony)
throw(new NotImplementedException());
return _myTelephony;
}
}
Grâce à l'utilisation de ce modèle, j’ai isolé les différences qui surviennent entre les périphériques et facilité la mise à jour et l'entretien de l'application, tout en offrant l'adaptabilité et en garantissant que mon application puisse s'exécuter sur tous les périphériques Windows Mobile.
Tests et exploration plus approfondie
Une bonne conception et un codage précis sont deux des trois aspects de l'écriture d'applications adaptables. Heureusement, l'aspect final que constitue le test est facilité par la diversité d'images d'émulateur fournies dans le cadre du kit de développement logiciel Windows Mobile et dans les packages autonomes. Les images d'émulateur vous permettent de tester votre application avec presque toutes les caractéristiques d'affichage possibles, notamment la rotation dynamique.
Les outils supplémentaires du SDK autorisent la simulation de fonctionnalités GPS, de plusieurs types de réseaux cellulaires et même de différentes configurations de sécurité, vous permettant de tester la détection et l'utilisation des fonctionnalités dynamiques. Enfin, une grande partie de l'environnement d'émulateur est programmable via les API d'automation du gestionnaire Device Emulator et l'infrastructure de connectivité de base, vous permettant d'automatiser certain aspects du test de plusieurs configurations de périphériques.
Windows Mobile fournit aujourd'hui la meilleure plate-forme de développement mobile dans laquelle une seule application peut cibler une grande diversité de périphériques. Que vous soyez expérimenté ou novice, le site Web des développeurs Windows Mobile (
msdn.microsoft.com/windowsmobile) offre la documentation, les didacticiels et les outils qui, avec la gamme d'API et de technologies avancées, ouvrent des possibilités illimitées de développement Windows Mobile. D'autres matériels et informations mises à jour sur les problèmes d'adaptabilité abordés dans cette rubrique sont disponibles à l'adresse
msdn.microsoft.com/windowsmobile/adaptyourapp.
Merci à Jim Wilson (
pluralsight.com/blogs/jimw), dont les discussions « Adapt Your App » ont inspiré cette rubrique et y ont contribué.