Passer de Silverlight pour Windows Phone à UWP

  • Article

Si vous êtes un développeur disposant d’une application Silverlight pour Windows Phone, vous pouvez tirer parti de vos compétences et de votre code source pour le passage à Windows 10. Grâce à Windows 10, vous pouvez créer une application de plateforme Windows universelle (UWP), à savoir un package d’application unique que vos clients peuvent installer sur tout type d’appareil. Pour plus d’informations sur Windows 10, sur les applications UWP et sur les concepts de code adaptatif et d’interface utilisateur adaptative que nous mentionnerons dans ce guide de portage, consultez le Guide des applications pour la plateforme Windows universelle (UWP).

Lorsque vous portez votre application Silverlight pour Windows Phone vers une application Windows 10, vous êtes en mesure de tirer parti des fonctionnalités mobiles qui ont été introduites dans Windows Phone 8.1, et d’en étendre bien davantage les possibilités en utilisant la plateforme Windows universelle (UWP) dont le modèle d’application et l’infrastructure d’interface utilisateur sont universels sur tous les appareils Windows 10. Cette approche permet de prendre en charge des PC, des tablettes, des téléphones et un grand nombre d’autres types d’appareils à partir d’une même base de code et avec un seul package d’application. Cela élargit également le public cible potentiel de votre application et crée de nouvelles possibilités avec les données partagées, les consommables achetés, etc. Pour plus d’informations sur les nouvelles fonctionnalités, voir Nouveautés pour les développeurs dans Windows 10.

Si vous le souhaitez, vous pouvez mettre à disposition des clients les versions Silverlight pour Windows Phone et Windows 10 de votre application.

Remarque Ce guide est conçu pour vous aider à porter manuellement votre application Silverlight pour Windows Phone vers Windows 10. Outre l’utilisation du présent guide pour porter votre application, vous pouvez tester la version préliminaire pour développeurs de Mobilize.NET Silverlight Bridge, conçue pour faciliter l’automatisation du processus de portage. Cet outil analyse le code source de votre application et convertit les références aux API et aux contrôles Silverlight pour Windows Phone en leurs équivalents UWP. Étant donné que cet outil est toujours en version préliminaire, il ne gère pas encore tous les scénarios de conversion. Toutefois, il devrait permettre à la plupart des développeurs de gagner du temps et leur simplifier la tâche. Pour tester la version préliminaire pour développeurs, visitez le site web Mobilize.NET.

XAML et .NET ou HTML ?

Windows Phone Silverlight dispose d’une infrastructure d’interface utilisateur XAML basée sur Silverlight 4.0, et vous programmez sur une version du .NET Framework et un petit sous-ensemble d’API Windows Runtime. Étant donné que vous avez utilisé XAML (Extensible Application Markup Language) dans votre application Silverlight pour Windows Phone, vous choisirez probablement XAML pour votre version Windows 10, car vous transférerez ainsi la plupart de vos connaissances et expériences, ainsi que la majeure partie de votre code source et des modèles de logiciels que vous utilisez. Même le balisage d’interface utilisateur et la conception peuvent être facilement portés. Vous retrouverez les API managées, le balisage XAML, l’infrastructure d’interface utilisateur et les outils que vous connaissez bien, et vous pouvez utiliser C++, C# ou Visual Basic avec XAML dans une application UWP. La relative simplicité de ce processus peut être surprenante, même s’il existe quelques écueils.

Voir Feuille de route pour les applications de plateforme Windows universelle (UWP) en C# ou Visual Basic.

Remarque Windows 10 prend en charge .NET Framework dans une bien plus large mesure qu’une application du Windows Phone Store. Par exemple, Windows 10 a plusieurs espaces de noms System.ServiceModel.* ainsi que System.Net, System.Net.NetworkInformation et System.Net.Sockets. Le moment est donc bien choisi pour porter votre application Silverlight pour Windows Phone et pour compiler et faire fonctionner votre code .NET en toute facilité sur la nouvelle plateforme. Voir Mappages des espaces de noms et des classes. Une autre excellente raison de recompiler votre code source .NET existant dans une application Windows 10 réside dans le fait que vous pourrez bénéficier du code natif .NET, dont une technologie de compilation d’avant-garde qui convertit le MSIL en code machine exécutable en mode natif. Les applications .NET Native démarrent plus vite, utilisent moins de mémoire et consomment moins de batterie que leurs équivalents MSIL.

Ce guide de portage se concentre sur XAML, mais vous pouvez également créer une application fonctionnellement équivalente, appelant la plupart des mêmes API Windows Runtime, à l’aide de JavaScript, de feuilles de style en cascade (CSS) et de HTML5 avec la bibliothèque Windows pour JavaScript. Bien que les infrastructures d’interface utilisateur Windows Runtime des langages XAML et HTML soient différentes l’une de l’autre, celle que vous choisirez fonctionnera de façon universelle dans toute la gamme des appareils Windows.

Ciblage de la famille d’appareils universels ou mobiles

L’une des possibilités qui s’offre à vous consiste à porter votre application vers une application ciblant la famille d’appareils universels. Dans ce cas, l’application peut être installée sur l’éventail d’appareils le plus diversifié. Si votre application appelle des API qui ne sont implémentées que dans la famille d’appareils mobiles, vous pouvez protéger ces appels avec du code adaptatif. En guise d’alternative, vous pouvez choisir de porter votre application vers une application qui cible la famille d’appareils mobiles, auquel cas vous n’avez pas besoin d’écrire de code adaptatif.

Adaptation de votre application à plusieurs facteurs de forme

L’option que vous avez choisie à la section précédente détermine la gamme d’appareils sur laquelle vos applications s’exécuteront, ce qui peut représenter un très large éventail d’appareils. Même si vous limitez votre application à la famille d’appareils mobiles, vous devez encore prendre en charge un grand nombre de tailles d’écran. Par conséquent, étant donné que votre application doit s’exécuter sur des facteurs de forme qu’elle ne prenait pas en charge auparavant, testez votre interface utilisateur sur ces facteurs de forme et apportez les modifications nécessaires pour qu’elle s’adapte à chacun d’eux de manière appropriée. Vous pouvez considérer qu’il s’agit d’une tâche de post-portage ou d’un redimensionnement du portage, dont vous trouverez un exemple pratique dans l’étude de cas Bookstore2.

Méthode de portage couche par couche

  • Vue. L’affichage (ainsi que le modèle d’affichage) constitue l’interface utilisateur de votre application. Dans l’idéal, l’affichage se compose de balises liées aux propriétés observables d’un modèle d’affichage. Une autre méthode (courante et pratique, mais uniquement sur le court terme) consiste à faire en sorte que le code impératif d’un fichier code-behind manipule directement des éléments de l’interface utilisateur. Dans les deux cas, la majeure partie du balisage et de la conception de votre interface utilisateur (et même du code impératif qui manipule les éléments de l’interface utilisateur) se révèlera simple à porter.
  • Modèles d’affichage et modèles de données. Même si vous n’adoptez pas pleinement les modèles avec séparation des responsabilités (comme MVVM), il existe inévitablement du code dans votre application, qui joue le rôle de modèle d’affichage et de modèle de données. Le code du modèle d’affichage utilise des types dans les espaces de noms de l’infrastructure de l’interface utilisateur. Le code du modèle de données et celui du modèle d’affichage utilisent également un système d’exploitation non visuel, ainsi que des API .NET (y compris les API d’accès aux données). La grande majorité de ces éléments sont disponibles pour une application UWP. Vous devriez donc être en mesure de porter la plus grande partie de ce code sans avoir à le modifier. N’oubliez pas : un modèle d’affichage correspond à un modèle, ou une abstraction, d’un affichage. Un modèle d’affichage fournit l’état et le comportement de l’interface utilisateur, tandis que l’affichage lui-même fournit les éléments visuels. Par conséquent, pour toute interface utilisateur que vous adaptez aux différents facteurs de forme sur lesquels UWP autorise l’exécution, vous devrez sans doute modifier le modèle d’affichage correspondant. Pour la mise en réseau et l’appel de services cloud, vous avez généralement la possibilité d’utiliser .NET ou Windows Runtime API. Pour connaître les facteurs qui entrent en jeu dans cette décision, voir Services cloud, mise en réseau et bases de données.
  • Services cloud. Il est probable que certains éléments de votre application (peut-être la plus grande partie) s’exécutent sur le cloud, sous la forme de services. La partie de l’application qui s’exécute sur l’appareil du client se connecte à ces services. Il s’agit de la partie d’une application distribuée qui a de grandes chances de rester intacte lors du portage de la partie destinée au client. Si vous n’avez pas encore envisagé cette possibilité, nous vous recommandons d’opter pour des services cloud pour votre application UWP. Ainsi, Microsoft Azure Mobile Services propose des composants principaux puissants et efficaces, que les applications Windows universelles peuvent appeler pour bénéficier de services allant de la simple notification de mise à jour des vignettes dynamiques aux différentes fonctions d’évolutivité ultra-puissantes que peut offrir une batterie de serveurs.

Avant ou pendant le portage, vérifiez si vous pouvez améliorer votre application en la refactorisant, afin de regrouper l’ensemble du code présentant une finalité similaire sous la forme de couches, ce qui vous permet d’éviter toute répartition arbitraire. La factorisation de votre application UWP en couches comme celles que nous venons de décrire vous permet de vous assurer que votre application est correcte, de la tester, puis de l’exécuter et de l’entretenir en toute simplicité. Vous pouvez faire en sorte que certaines fonctionnalités soient davantage réutilisables et éviter ainsi certains problèmes de différences d’API d’interface utilisateur d’une plateforme à l’autre en suivant le modèle MVVM (Model-View-ViewModel). Ce modèle gère de manière séparée les éléments de l’interface utilisateur, les composants professionnels et les données. Même au sein de l’interface utilisateur, ce modèle peut séparer les états et les comportements des éléments visuels, qui seront testés séparément. Grâce au modèle MVVM, vous pouvez écrire vos données et votre logique métier une seule fois et l’utiliser sur tous les appareils, quelle que soit l’interface utilisateur. En outre, ce modèle vous permettra probablement de réutiliser la majeure partie du modèle d’affichage et des zones d’affichage sur l’ensemble des appareils.

Une ou deux exceptions à la règle

Lorsque vous lisez ce guide de portage, vous pouvez vous référer à l’article Mappages des espaces de noms et des classes. En général, le mappage est relativement simple, et le tableau relatif aux mappages des espaces de noms et des classes décrit les éventuelles exceptions.

Concernant les fonctionnalités, il est bon de noter qu’UWP en prend en charge une très grande majorité. Vous pourrez transférer très facilement la majeure partie de vos compétences et de votre code source vers des applications UWP, comme vous le découvrirez dans le reste de ce guide de portage. Mais voici les rares fonctionnalités de Silverlight pour Windows Phone que vous avez peut-être utilisées et pour lesquelles il n’existe pas d’équivalent UWP.

Fonctionnalité sans équivalent UWP Documentation Silverlight pour Windows Phone relative à la fonctionnalité
Microsoft XNA. En règle générale, Microsoft DirectX en C++ est utilisé en remplacement. Voir Développement de jeux et Interopérabilité de DirectX et XAML. Bibliothèque de classes de XNA Framework
Applications de filtre Lenses for Windows Phone 8 (en anglais)

 

Rubrique Description
Mappages des espaces de noms et des classes Cette rubrique présente le mappage complet des API de Silverlight pour Windows Phone sur leurs équivalents UWP.
Portage du projet Commencez le processus de portage en créant un projet Windows 10 dans Visual Studio, puis en copiant vos fichiers dans ce dernier.
Dépannage Nous vous recommandons vivement de lire ce guide de portage jusqu’à la fin, mais nous comprenons également que vous soyez impatient d’avancer et de passer à l’étape de développement et d’exécution de votre projet. À cette fin, vous pouvez avancer provisoirement en commentant ou en remplaçant du code non essentiel, pour revenir ensuite afin de combler cette lacune ultérieurement. Le tableau de résolution des problèmes et des solutions de cette rubrique peuvent vous être utiles à ce stade, même s’il ne se substitue pas à la lecture des rubriques suivantes. Vous pouvez toujours revenir au tableau lorsque vous avancez dans les rubriques ultérieures.
Portage du balisage XAML et de la couche interface utilisateur La pratique de définition de l’interface utilisateur sous la forme de balisage XAML déclaratif se transpose extrêmement bien entre les applications Silverlight pour Windows Phone et les applications UWP. Vous allez découvrir que des sections importantes de votre balisage sont compatibles une fois que vous avez mis à jour les références de clés des ressources système, modifié certains noms de type d’élément et remplacé « clr-namespace » par « using ».
Portage pour le modèle d’E/S, d’appareil et d’application Le code qui s’intègre à l’appareil proprement dit et à ses capteurs implique des entrées de l’utilisateur et des sorties vers ce dernier. Il peut également impliquer le traitement des données. Néanmoins, ce code n’est généralement pas pensé comme la couche interface utilisateur ni comme la couche de données. Ce code inclut l’intégration au contrôleur de vibrations, à l’accéléromètre, au gyroscope, au microphone et au haut-parleur (qui rejoignent la reconnaissance et la synthèse vocales), à la (géo)localisation et aux modalités d’entrée telles que l’écran tactile, la souris, le clavier et le stylet.
Portage des couches métier et des couches de données Derrière votre interface utilisateur se trouvent les couches métier et les couches de données. Le code de ces couches appelle le système d’exploitation et les API .NET Framework (par exemple, pour le traitement en arrière-plan, l’emplacement, l’appareil photo, le système de fichiers, le réseau et l’accès à d’autres données). La grande majorité de ces éléments sont disponibles pour une application UWP. Vous devriez donc être en mesure de porter la plus grande partie de ce code sans avoir à le modifier.
Portage pour différents facteurs de forme et expériences utilisateur Les applications Windows présentent le même aspect, que ce soit sur PC, sur appareil mobile ou sur tout autre type d’appareil. Les modèles d’interaction, d’entrée et d’interface utilisateur sont similaires ; un utilisateur passant d’un type d’appareil à un autre ne pourra que se féliciter de ces similitudes.
Étude de cas : Bookstore1 Cette rubrique présente une étude de cas de portage d’une application Silverlight pour Windows Phone très simple vers une application UWP Windows 10. Grâce à Windows 10, vous pouvez créer un package d’application unique que vos clients peuvent installer sur un large éventail d’appareils. C’est ce que nous allons faire dans la présente étude de cas.
Étude de cas : Bookstore2 Cette étude de cas, qui repose sur les informations fournies dans Bookstore1, commence par une application Silverlight pour Windows Phone qui affiche des données groupées dans un élément LongListSelector. Dans le modèle d’affichage, chaque instance de la classe Author représente l’ensemble des livres écrits par l’auteur en question ; dans l’élément LongListSelector, nous pouvons visualiser la liste des livres regroupés par auteur ou nous pouvons effectuer un zoom arrière pour afficher une liste de raccourcis relatifs aux auteurs.

Documentation

Articles de magazine

Présentations

  • Le passage de Nokia Musique de Windows Phone à Windows 8