La migration d'une application existante est une question que tout développeur ayant fait le pari de Windows Mobile dans ces versions précédentes doit se poser avec Windows Phone 7. En effet, même si auparavant d'une version sur l'autre, les changements étaient mineurs et la compatibilité globalement assurée, le changement radical opéré par Windows Phone 7 oblige à étudier de nouveaux runtimes (Silverlight et XNA vs .NET Compact Framework 2.0 et 3.5) et de nouveaux outils (Visual Studio 2010 et Expression Blend 4 vs Visual Studio 2008). Loin de se vouloir exhaustive, cette fiche a pour but d'aider un développeur Windows Mobile 6.5 à évaluer « facilement » la tache de portage de son application.
Modèle de l'application
Le modèle actuel de votre application va jouer un rôle primordial dans le portage. Si le découpage interface/ métier de votre application Windows Mobile 6.5 était bien pensé, le portage sera d'autant plus aisé. Les couches IHM seront complètement à récrire, mais les couches logique métiers et modèles de données pourront être réutilisée telles quelles ou portée à quelques deltas près.
Windows Mobile 6.5 | Windows Phone 7 |
Le pattern MVC pouvait être utilisé afin de découpler la couche IHM de la couche métier. Ainsi l'application était composée d'un contrôleur régissant les échanges entre la vue et la couche métier. Si aucun design pattern n'a été suivi, la séparation est plus compliquée, mais c'est aussi l'occasion de restructurer tout ce code ! | Utilisation de Silverlight, le pattern MVVM est plus adapté pour utiliser le data binding et tirer la quintessence de Silverlight. |
L'expérience utilisateur
Comme vu dans le paragraphe précédent, l'interface est donc la partie à refondre complètement, le cas échant l'expérience utilisateur pourra être revue et adaptée à la nouvelle expérience Windows Phone 7.
Windows Mobile 6.5 | Windows Phone 7 |
Aucune recommandation n'était préconisée en termes d'IHM, chacun faisait comme il l'entendait. | Il est souhaitable de coller au langage de design de Windows Phone 7, Metro. L'idée est de faire quelque chose de simple à la manière du guidage dans les aéroports et dans le métro, l'identité graphique est fortement basée sur la typographie, les pictogrammes et les espaces négatifs. L'interface doit rester sobre, fluide et sans chrome |
Afin de ne pas monopoliser le thread d'UI, les traitements complexes doivent être déportés dans autres threads. | Afin de ne pas monopoliser le thread UI, les traitements complexes doivent être déportés dans des autres threads. Ce thread « métier » effectuera le traitement asynchrone et notifiera l'IHM des modifications à la fin du traitement : new { // Traitements à réaliser { // Mise à jour de l'IHM });
}).Start(); |
Les contrôles
La plupart des contrôles de Windows Mobile 6.5 sont disponibles sur Phone 7 avec des propriétés et des possibilités de customisation beaucoup plus évoluées. Le positionnement des contrôles dynamique sera grandement facilité grâce des panels évolués comme le stackpanel ou la grid.
Windows Mobile 6.5 | Windows Phone 7 |
PhoneApplicationFrame | |
Form | PhoneApplicationPage |
MainMenu | Application bar |
System tray | |
Panel | Canvas, StackPanel, Grid |
Button | Button |
TextBox | TextBox |
PictureBox Les PNG transparents ne sont pas gérés nativement, les APIs native d'Alpha Blend doivent être wrappées | Image Le format PNG est supporté nativement et son support est accéléré par GPU |
ListView Difficilement personnalisable | ListBox Très facilement personnalisable à l'aide des Templates disponibles dans Silverlight |
ProgressBar | ProgressBar |
Utilisation d'un panel et des évènements de reconnaissance geste | ScrollViewer |
Label | TextBlock |
Composant MediaPlayer importé depuis l'ActiveX MediaPlayer via un wrapper d'objet COM | Le nouveau composant Media Element est directement accessible depuis le code Silverlight et décode nativement les formats de vidéos suivants : H263 WMV MPEG-4 |
Navigateur WEB System.Windows. Forms.WebBrowser | WebBrowserTask |
Prendre une photo Microsoft.WindowsMobile. Forms.CameraCaptureDialog |
CameraCaptureTask |
Appeler un contact Microsoft. WindowsMobile.Telephony. Phone |
PhoneCallTask |
Envoyer un SMS Microsoft.WindowsMobile .PocketOutlook. SmsMessage |
SmsComposeTask |
Les APIs
Sur Phone 7 fini les spécificités de code et cas particuliers mis en place pour chaque terminal, tout est unifié grâce à un hardware homogène et une API unifiée pour accéder aux différents capteurs du téléphones.
Windows Mobile 6.5 | Windows Phone 7 |
Très fastidieux de récupérer les informations liées au téléphone notamment pour les points suivants : - Accéléromètre - GPS - Radio FM - Gestion des boutons du téléphone Car il est nécessaire de faire appel à des API natives bas-niveau liées au constructeur du téléphone et rarement fournies. | Gestion unifiée des APIs : Accéléromètre (Microsoft.Devices. Sensors.Accelerometer) GPS (System.Device.Location. GeoCoordinateWatcher) Orientation de l'écran Radio FM Gestion des boutons du téléphones |
Orientation de l'écran Microsoft.WindowsCE. Forms.SystemSettings. ScreenOrientation |
PhoneApplicationPage.Orientation PhoneApplicationPage. SupportedOrientation |
La reconnaissance de gestes
Sur Phone 7, l'accès au code natif depuis le C# n'est plus autorisé : finis les wrappers d'API natives, tout est directement utilisable depuis le C# via des classes avec des méthodes et évènements ; c'est typiquement le cas de la reconnaissance des gestes de l'utilisateur sur l'écran.
Windows Mobile 6.5 | Windows Phone 7 |
Import de code natif pour utiliser l'API Gesture qui n'était pas disponible en code managé. (traitement des messages WM_GESTURE) | Chaque contrôle dispose d'évènements de manipulation : ManipulationStarted ManipulationDelta ManipulationCompleted Avec pour chacun des paramètres tels que la vélocité, l'angle… |
Stockage des données en mémoire
Sur Windows Phone 7, le système de fichiers du terminal n'est « accessible » qu'à travers l'Isolated Storage de l'application et aucun SGBD n'est disponible pour l'instant. La persistance des données sera donc mise en œuvre via à l'aide de fichiers XML stockés dans la SandBox ou via des solutions tierces comme SQLite ou Perst.NET.
Windows Mobile 6.5 | Windows Phone 7 |
Utilisation de SQLCE | Utilisation de fichiers XML stockées dans l'Isolated storage et utilisation de LINQ pour requêtes sur les données. Sinon solutions tierces comme SQLite ou Perst.NET. |
Accès au système de fichier | Accès à l'Isolated Storage System.IO.IsolatedStorage.* |
Sauvegarde de settings : Base de registre DB Fichiers | Sauvegarde des settings dans le dictionnaire de l'IsolatedStorage prévu à cet effet : IsolatedStorageSettings Ce dictionnaire permet de sauvegarder des types sérialisables et le « statut » de l'application indépendamment de fichiers ou d'une base de donnée. |
Réseau
L'accès à des données d'un serveur se fera uniquement via un canal http et en mode asynchrone. Pour les évènements asynchrones provenant d'un serveur il est possible d'utiliser des Push Notifications (cf. paragraphe suivant et article sur le sujet)
Windows Mobile 6.5 | Windows Phone 7 |
Sockets | Pas d'accès au socket : pas de TCP ou d'UDP |
HttpWebRequest synchrone | Les WebRequest sont asynchrones, il est conseillé d'utiliser l'objet WebClient qui permet de réaliser une requête http et d'obtenir dont résultat via une callback. Cela peut donc complexifier un peu le code, mais c'est pour le mieux d'un point de vue réactivité de l'interface. |
L'application peut subsister en background et à tout moment prendre le focus ou gérer des évènements comme le réveil de l'application via un SMS entrant. | Système de notifications en push Ce système permet de remonter des informations à une application fermée et d'afficher en permanence un statut à l'utilisateur sur l'icône de l'application par exemple |
Cycle de vie d'une application
Windows Mobile 6.5 | Windows Phone 7 |
L'application reste en background et n'est jamais fermée sauf demande explicite ou soft reset du téléphone | Dès qu'on sort de l'application, cette dernière est fermée et les données ne sont pas automatiquement sauvegardées. Le mécanisme dit de « tombstoning » permet de sauvegarder l'état de l'application et lors du lancement de l'application le restituer. Quatre évènements seront déclenchés afin de mettre en œuvre les comportements adéquats : Launching / Activated : récupération et chargement des données Deactivated / Closing : Sauvegarde des données dans un dictionnaire prévu à cet effet (PhoneApplicationService) |
Outils de debug et de monitoring des performances
Reste un point important à traiter qui impacte directement l'expérience utilisateur, ce sont les performances. Voici, de quoi réaliser quelques benchs afin de vérifier que votre application sera à la hauteur du résultat attendu notamment en termes de fluidité.
Windows Mobile 6.5 | Windows Phone 7 |
Outils du pack Power Toys Remote Performance Monitor NETCF CLR Profiler Remote Logging Configuration Tool … | Les compteurs de performance : (Application.Current.Host. Settings.EnableFrameRateCounter) Compositeur frame rate (fréquence de rafraichissement de l'écran) UI thread frame rate (fréquence du thread UI) Mémoire utilisée pour les textures Nombre de surfaces allouées (Application.Current.Host. Settings.EnableCacheVisualization) (Application.Current.Host.Settings. EnableRedrawRegions) |
Bien que cet article ne soit pas exhaustif, vous avez maintenant les grandes lignes et pièges à éviter pour porter vos applications Windows Mobile 6.5 vers la nouvelle plateforme Windows Phone 7.
Les étapes suivantes résument la démarche à suivre :
- Création du projet WP7
- Ebauche d'un squelette d'application
- Identification des vues et vues-modèles associées aux données à afficher (datacontext)
- Mise en place de la logique de navigation avec passage des données entre les différentes pages
- Import des ressources textuelles dans les différentes langues si l'application est localisée
- Import des ressources graphiques en PNG ou JPG
- Réalisation des différentes pages en gardant bien en tête l'ergonomie Metro (si possible réalisation d'un storyboard de l'application au préalable pour visualiser l'intégralité de l'application), ne pas oublier de tirer parti des nouveaux composants disponibles pour le positionnement des contrôles
- Si besoin réalisation de composants personnalisés pour répondre aux besoins de l'application
- Mise en place du code relatif aux activités vers les services et tâches Windows Phone 7
- Migration des couches métiers
- Identifier les accès aux serveurs distants et « asynchroniser » les traitements pour coller au modèle Windows Phone 7. Afin de réaliser une application fluide, il est de rigueur de pas réaliser de traitements lourds ou bloquants dans le thread UI.
- Identifier le stockage de donnée et mettre en place des classes sérialisables pour stockage en XML dans l'IsolatedStorage.
- Le filtrage et traitement des données via des requêtes LINQ pourra être réutilisé tel quel
- Appel des couches métiers depuis les vues-modèles
- Tests de l'intégration des différentes couches interface et métiers
- Optimisation
Le monitoring des performances pourra être réalisé via le biais des compteurs de performances vus plus haut.
Le portage de votre application Windows Mobile 6.5 ne sera pas forcément trivial au premier abord, mais de nombreux composants métiers resteront réutilisables. Vous verrez rapidement que la nouvelle batterie d'outils et le framework mis à disposition sont très complets et seront vos alliés pour réaliser facilement et rapidement des applications avec une expérience utilisateur sans précédent… L'important est de bien étudier la méthode de migration avant de se lancer dans le code !
2 comments:
C'est pas exactement ce que j’appellerai un portage, mais l'article est sympa, merci.
En clair, on doit réécrire l'essentiel du code quand les services métier étaient déporté sur un serveur
Post a Comment