Partager via

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. Avec Windows 10, vous pouvez créer une application plateforme Windows universelle (UWP), qui est un package d’application unique que vos clients peuvent installer sur chaque type d’appareil. Pour plus d’informations sur Windows 10, les applications UWP et les concepts du code adaptatif et de l’interface utilisateur adaptative que nous mentionnerons dans ce guide de portage, consultez le Guide pour plateforme Windows universelle (UWP).

Lorsque vous transférez votre application Silverlight Windows Phone vers une application Windows 10, vous pourrez rattraper les fonctionnalités mobiles introduites dans Windows Phone 8.1 et aller bien au-delà de celles-ci pour utiliser le plateforme Windows universelle modèle d’application (UWP) dont le modèle d’application et l’infrastructure d’interface utilisateur sont universels sur tous les appareils Windows 10. Cela permet de prendre en charge les PC, tablettes, téléphones et un grand nombre d’autres types d’appareils, à partir d’une base de code et d’un package d’application. Et cela va multiplier l’audience potentielle de votre application et créer de nouvelles possibilités avec des données partagées, des consommables achetés, et ainsi de suite. Pour plus d’informations sur les nouvelles fonctionnalités, consultez Nouveautés pour les développeurs dans Windows 10.

Si vous choisissez de le faire, la version Silverlight de Windows Phone de votre application et la version de Windows 10 peuvent être disponibles pour les clients en même temps.

Notez que ce guide est conçu pour vous aider à porter manuellement votre application Silverlight Windows Phone vers Windows 10. Outre l’utilisation des informations contenues dans ce guide pour porter votre application, vous pouvez essayer la préversion du pont Silverlight de Mobilize.NET pour vous aider à automatiser le processus de portage. Cet outil analyse le code source de votre application et convertit les références en contrôles et API Silverlight Windows Phone en leurs équivalents UWP. Étant donné que cet outil est toujours en préversion du développeur, il ne gère pas encore tous les scénarios de conversion. Toutefois, la plupart des développeurs doivent pouvoir gagner du temps et des efforts en commençant par cet outil. Pour essayer la préversion du développeur, visitez le site web de Mobilize.NET.

XAML et .NET, ou HTML ?

Windows Phone Silverlight a 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é le langage XAML (Extensible Application Markup Language) dans votre application Silverlight Windows Phone, il est probable que XAML soit votre choix pour votre version de Windows 10, car la plupart de vos connaissances et de votre expérience seront transférées, ainsi que la plupart de votre code source et des modèles logiciels que vous utilisez. Même le balisage et la conception de votre interface utilisateur peuvent se porter facilement. Vous trouverez les API managées, le balisage XAML, l’infrastructure d’interface utilisateur et les outils familiers de manière rassurante, et vous pouvez utiliser C++, C# ou Visual Basic avec XAML dans une application UWP. Vous serez peut-être surpris de la façon dont le processus est relativement facile, même s’il y a un défi ou deux le long de la route.

Consultez feuille de route pour les applications plateforme Windows universelle (UWP) à l’aide de C# ou Visual Basic.

Notez que Windows 10 prend en charge beaucoup plus de .NET Framework 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. Par conséquent, il est très utile de porter votre windows Phone Silverlight et d’avoir votre code .NET juste compiler et travailler sur la nouvelle plateforme. Consultez les mappages d’espace de noms et de classes. Une autre excellente raison de recompiler votre code source .NET existant en une application Windows 10 est que vous bénéficierez de .NET Native, qui est une technologie de compilation anticipée qui convertit 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, sinon, vous pouvez créer une application fonctionnellement équivalente, appelant un grand nombre des mêmes API Windows Runtime, à l’aide de JavaScript, de feuilles de style en cascade (CSS) et HTML5, ainsi que de la bibliothèque Windows pour JavaScript. Bien que les frameworks d’interface utilisateur Windows Runtime de XAML et HTML soient différents de ceux que vous choisissez fonctionnent de manière universelle sur toute la gamme d’appareils Windows.

Ciblage de la famille d’appareils mobiles ou universels

L’une des options dont vous avez besoin consiste à porter votre application vers une application qui cible la famille d’appareils universelle. Dans ce cas, l’application peut être installée sur la plus grande gamme d’appareils. Si votre application appelle des API implémentées uniquement dans la famille d’appareils mobiles, vous pouvez protéger ces appels avec du code adaptatif. Vous pouvez également choisir de porter votre application vers une application qui cible la famille d’appareils mobiles auquel cas vous n’avez pas besoin d’écrire du code adaptatif.

Adaptation de votre application à plusieurs facteurs de forme

L’option que vous choisissez dans la section précédente détermine la plage d’appareils sur lesquels votre application ou vos applications s’exécutent, et cela peut être un très large éventail d’appareils. Même limiter votre application à la famille d’appareils mobiles vous laisse toujours avec un large éventail de tailles d’écran à prendre en charge. Par conséquent, étant donné que votre application s’exécute sur des facteurs de forme qu’elle n’a pas précédemment pris en charge, testez votre interface utilisateur sur ces facteurs de forme et apportez toute modification nécessaire afin que votre interface utilisateur s’adapte correctement à chacun d’eux. Il s’agit d’une tâche post-portage ou d’un portage d’étirements, et il existe un exemple dans la pratique de l’étude de cas Bookstore2 .

Approche du portage de couche par couche

  • Affichage. La vue (avec le modèle d’affichage) constitue l’interface utilisateur de votre application. Dans l’idéal, la vue se compose de marques liées aux propriétés observables d’un modèle d’affichage. Un autre modèle (courant et pratique, mais uniquement à court terme) est destiné au code impératif dans un fichier code-behind pour manipuler directement les éléments de l’interface utilisateur. Dans les deux cas, une grande partie de votre balisage et conception de l’interface utilisateur , et même le code impératif qui manipule les éléments de l’interface utilisateur, sera simple à porter.
  • Afficher les modèles et les modèles de données. Même si vous n’adoptez pas formellement les modèles de séparation des préoccupations (tels que MVVM), il existe inévitablement du code présent dans votre application qui effectue la fonction de modèle de vue et de modèle de données. Afficher le code du modèle utilise des types dans les espaces de noms de l’infrastructure d’interface utilisateur. Le modèle d’affichage et le code du modèle de données utilisent également le système d’exploitation non visuel et les API .NET (y compris les API pour l’accès aux données). Et la grande majorité de celles-ci sont disponibles pour une application UWP. Vous pouvez donc vous attendre à pouvoir porter une grande partie de ce code sans modification. N’oubliez pas, cependant : un modèle d’affichage est un modèle, ou une abstraction, d’une vue. Un modèle d’affichage fournit l’état et le comportement de l’interface utilisateur, tandis que la vue elle-même fournit les visuels. Pour cette raison, toute interface utilisateur que vous adaptez aux différents facteurs de forme que L’UWP vous permet d’exécuter sur aura probablement besoin de modifications de modèle d’affichage correspondantes. Pour la mise en réseau et l’appel des services cloud, vous avez généralement la possibilité d’utiliser des API .NET ou Windows Runtime. Pour connaître les facteurs impliqués dans la prise de cette décision, consultez les services cloud, la mise en réseau et les bases de données.
  • Services cloud. Il est probable que certaines de vos applications (peut-être une grande quantité) s’exécutent dans le cloud sous la forme de services. La partie de l’application en cours d’exécution sur l’appareil client se connecte à celles-ci. Il s’agit de la partie d’une application distribuée qui restera probablement inchangée lors du portage de la partie cliente. Si vous n’en avez pas encore, une bonne option de services cloud pour votre application UWP est Microsoft Azure Mobile Services, qui fournit des composants principaux puissants que les applications Windows universelles peuvent appeler pour des services allant de notifications simples pour les mises à jour de vignettes actives jusqu’au type d’extensibilité lourde qu’une batterie de serveurs peut fournir.

Avant ou pendant le portage, déterminez si votre application peut être améliorée en la refactorisant afin que le code ayant un objectif similaire soit rassemblé dans des couches et non dispersé arbitrairement. Le fait de factoriser votre application UWP en couches comme celles décrites ci-dessus vous permet de rendre votre application correcte, de la tester, puis de la lire et de la gérer. Vous pouvez rendre les fonctionnalités plus réutilisables et éviter certains problèmes de différences d’API d’interface utilisateur entre les plateformes en suivant le modèle Model-View-ViewModel (MVVM). Ce modèle conserve les données, l’entreprise et les parties de l’interface utilisateur de votre application séparément les unes des autres. Même dans l’interface utilisateur, il peut conserver l’état et le comportement distincts, et séparément testables, à partir des visuels. Avec 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. Il est probable que vous serez en mesure de réutiliser une grande partie du modèle d’affichage et des parties d’affichage sur les appareils.

Une ou deux exceptions à la règle

Lorsque vous lisez ce guide de portage, vous pouvez faire référence aux mappages d’espaces de noms et de classes. Le mappage relativement simple est la règle générale, et la table des mappages d’espaces de noms et de classes décrit les exceptions.

Au niveau de la fonctionnalité, les bonnes nouvelles sont qu’il y a très peu de choses qui ne sont pas prises en charge dans UWP. La plupart de votre jeu de compétences et du code source se traduisent très bien en applications UWP, car vous allez lire dans le reste de ce guide de portage. Toutefois, voici les quelques fonctionnalités Silverlight de Windows Phone que vous avez peut-être utilisées pour lesquelles il n’existe pas d’équivalent UWP.

Fonctionnalité pour laquelle il n’existe aucun équivalent UWP Documentation Silverlight sur Windows Phone pour la fonctionnalité
Microsoft XNA. En général, Microsoft DirectX à l’aide de C++ est le remplacement. Consultez Développement de jeux et d’interopérabilité DirectX et XAML. Bibliothèque de classes XNA Framework
Applications Lens Lentilles pour Windows Phone 8

 

Sujet Description
Mappages d’espaces de noms et de classes Cette rubrique fournit un mappage complet des API Silverlight Windows Phone à leurs équivalents UWP.
Portage du projet Vous commencez le processus de portage en créant un projet Windows 10 dans Visual Studio et en copiant vos fichiers.
Dépannage Nous vous recommandons vivement de lire jusqu’à la fin de ce guide de portage, mais nous comprenons également que vous êtes impatient d’aller de l’avant et de passer à l’étape où votre projet génère et s’exécute. À cette fin, vous pouvez faire des progrès temporaires en commentant ou en stubbant n’importe quel code non essentiel, puis en retournant pour rembourser cette dette ultérieurement. Le tableau des symptômes de résolution des problèmes et des remèdes dans cette rubrique peut vous être utile à ce stade, même s’il n’est pas un substitut à la lecture des rubriques suivantes. Vous pouvez toujours vous référer au tableau à mesure que vous progressez dans les rubriques ultérieures.
Portage du balisage XAML et de l’IU La pratique de la définition de l’interface utilisateur sous la forme de balisage XAML déclaratif se traduit très bien par Windows Phone Silverlight vers les applications UWP. Vous constaterez que les grandes sections de votre balisage sont compatibles une fois que vous avez mis à jour les références de clé de ressource système, modifié certains noms de types d’éléments et modifié « clr-namespace » par « using ».
Portage des E/S, des appareils et du modèle d’application Le code qui s’intègre à l’appareil lui-même et à ses capteurs implique l’entrée et la sortie vers l’utilisateur. Il peut également impliquer le traitement des données. Toutefois, ce code n’est généralement pas considéré comme la couche d’interface utilisateur ou la couche de données. Ce code inclut l’intégration avec le contrôleur de vibration, l’accéléromètre, le gyroscope, le microphone et le haut-parleur (qui se croisent avec la reconnaissance vocale et la synthèse), l’emplacement (géo) et les modalités d’entrée telles que le toucher, la souris, le clavier et le stylet.
Portage des couches métier et de données Derrière votre interface utilisateur, vous trouverez vos couches métier et de données. Le code de ces couches appelle le système d’exploitation et les API .NET Framework (par exemple, traitement en arrière-plan, emplacement, caméra, système de fichiers, réseau et autres accès aux données). La grande majorité de ces applications sont disponibles pour une application UWP. Vous pouvez donc vous attendre à pouvoir porter une grande partie de ce code sans modification.
Portage du facteur de forme et de l’expérience utilisateur Les applications Windows partagent une apparence commune entre les PC, les appareils mobiles et de nombreux autres types d’appareils. L’interface utilisateur, les entrées et les modèles d’interaction sont très similaires, et un utilisateur qui se déplace entre les appareils accueille l’expérience familière.
Étude de cas : Bookstore1 Cette rubrique présente une étude de cas sur le portage d’une application Silverlight Windows Phone très simple vers une application UWP Windows 10. Avec Windows 10, vous pouvez créer un package d’application unique que vos clients peuvent installer sur un large éventail d’appareils, et c’est ce que nous allons faire dans cette étude de cas.
Étude de cas : Bookstore2 Cette étude de cas, qui s’appuie sur les informations fournies dans Bookstore1, commence par une application Silverlight Windows Phone qui affiche des données groupées dans un LongListSelector. Dans le modèle d’affichage, chaque instance de la classe Author représente le groupe des livres écrits par cet auteur, et dans LongListSelector, nous pouvons afficher la liste des livres regroupés par auteur ou nous pouvons effectuer un zoom avant pour afficher une liste de raccourcis d’auteurs.

Documentation

Articles du magazine

Présentations

  • L’histoire d’apporter de la musique Nokia de Windows Phone à Windows 8