Portage de Silverlight Windows Phone vers UWP pour les E/S, l’appareil et le modèle d’application

La rubrique précédente portait le code XAML et l’interface utilisateur.

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.

Cycle de vie des applications (gestion de la durée de vie des processus)

Votre application Silverlight Windows Phone contient du code permettant d’enregistrer et de restaurer son état d’application et son état d’affichage afin de prendre en charge l’exécution de pierres tombstone et par la suite réactivé. Le cycle de vie des applications plateforme Windows universelle (UWP) a de fortes parallèles avec celles des applications Silverlight Windows Phone, car elles sont toutes deux conçues avec le même objectif d’optimiser les ressources disponibles pour l’application que l’utilisateur a choisi d’avoir au premier plan à tout moment. Vous constaterez que votre code s’adaptera facilement au nouveau système.

Notez que l’appui sur le bouton Précédent matériel met automatiquement fin à une application Silverlight Windows Phone. Appuyer sur le bouton Précédent matériel sur un appareil mobile ne termine pas automatiquement une application UWP. Au lieu de cela, il devient suspendu, puis il peut être arrêté. Toutefois, ces détails sont transparents pour une application qui répond de manière appropriée aux événements de cycle de vie des applications.

Une « fenêtre debounce » est la période entre l’application devenant inactive et le système qui déclenche l’événement de suspension. Pour une application UWP, il n’existe aucune fenêtre de débogage ; l’événement de suspension est déclenché dès qu’une application devient inactive.

Pour plus d’informations, consultez cycle de vie des applications.

Appareil photo

Le code de capture de la caméra Silverlight windows Phone utilise les classes Microsoft.Devices.Camera, Microsoft.Devices.PhotoCamera ou Microsoft.Phone.Tasks.CameraCaptureTask . Pour porter ce code vers le plateforme Windows universelle (UWP), vous pouvez utiliser la classe MediaCapture. Il existe un exemple de code dans la rubrique CapturePhotoToStorageFileAsync. Cette méthode vous permet de capturer une photo dans un fichier de stockage, et nécessite que les fonctionnalités du microphone et de l’appareil webcamsoient définies dans le manifeste du package d’application.

Une autre option est la classe CameraCaptureUI, qui nécessite également les fonctionnalités du microphone et de l’appareil webcam.

Les applications Lens ne sont pas prises en charge pour les applications UWP.

Détection de la plateforme sur laquelle votre application s’exécute

La façon d’envisager le ciblage d’application change avec Windows 10. Le nouveau modèle conceptuel est qu’une application cible le plateforme Windows universelle (UWP) et s’exécute sur tous les appareils Windows. Il peut ensuite choisir d’éclairer les fonctionnalités qui sont exclusives à des familles d’appareils particulières. Si nécessaire, l’application a également la possibilité de se limiter à cibler une ou plusieurs familles d’appareils spécifiquement. Pour plus d’informations sur les familles d’appareils et sur la façon de déterminer la famille d’appareils à cibler, consultez Guide des applications UWP.

Notez que nous vous recommandons de ne pas utiliser le système d’exploitation ou la famille d’appareils pour détecter la présence de fonctionnalités. L’identification du système d’exploitation ou de la famille d’appareils actuel n’est généralement pas la meilleure façon de déterminer si une fonctionnalité de famille d’appareils ou de système d’exploitation particulière est présente. Au lieu de détecter le système d’exploitation ou la famille d’appareils (et le numéro de version), testez la présence de la fonctionnalité elle-même (consultez compilation conditionnelle et code adaptatif). Si vous devez exiger un système d’exploitation ou une famille d’appareils particulier, veillez à l’utiliser comme version minimale prise en charge, plutôt que de concevoir le test pour cette version.

Pour adapter l’interface utilisateur de votre application à différents appareils, il existe plusieurs techniques que nous vous recommandons. Continuez à utiliser des éléments de taille automatique et des panneaux de disposition dynamiques comme vous l’avez toujours fait. Dans votre balisage XAML, continuez à utiliser des tailles en pixels effectifs (anciennement afficher des pixels) afin que votre interface utilisateur s’adapte à différentes résolutions et facteurs d’échelle (voir Affichage/pixels effectifs, distance d’affichage et facteurs d’échelle). Utilisez également les déclencheurs adaptatifs et les setters de Visual State Manager pour adapter votre interface utilisateur à la taille de la fenêtre (voir Guide des applications UWP).

Toutefois, si vous avez un scénario où il est inévitable de détecter la famille d’appareils, vous pouvez le faire. Dans cet exemple, nous utilisons la classe AnalyticsVersionInfo pour accéder à une page adaptée à la famille d’appareils mobiles, le cas échéant, et nous nous assurons de revenir à une page par défaut dans le cas contraire.

   if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
        rootFrame.Navigate(typeof(MainPageMobile), e.Arguments);
    else
        rootFrame.Navigate(typeof(MainPage), e.Arguments);

Votre application peut également déterminer la famille d’appareils sur laquelle elle s’exécute à partir des facteurs de sélection de ressources qui sont en vigueur. L’exemple ci-dessous montre comment procéder de manière impérative et la rubrique ResourceContext.QualifierValues décrit le cas d’usage plus classique pour la classe lors du chargement de ressources spécifiques à la famille d’appareils en fonction du facteur de famille d’appareils.

var qualifiers = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues;
string deviceFamilyName;
bool isDeviceFamilyNameKnown = qualifiers.TryGetValue("DeviceFamily", out deviceFamilyName);

Consultez également la compilation conditionnelle et le code adaptatif.

État de l'appareil

Une application Silverlight Windows Phone peut utiliser la classe Microsoft.Phone.Info.DeviceStatus pour obtenir des informations sur l’appareil sur lequel l’application s’exécute. Bien qu’il n’existe pas d’équivalent UWP direct pour l’espace de noms Microsoft.Phone.Info , voici quelques propriétés et événements que vous pouvez utiliser dans une application UWP à la place d’appels à des membres de la classe DeviceStatus .

Emplacement

Lorsqu’une application qui déclare la fonctionnalité Emplacement dans son manifeste de package d’application s’exécute sur Windows 10, le système invite l’utilisateur final à donner son consentement. Par conséquent, si votre application affiche sa propre invite de consentement personnalisée ou si elle fournit un bouton bascule désactivé, vous souhaiterez supprimer cela afin que l’utilisateur final ne soit invité qu’une seule fois.

Orientation

L’application UWP équivalente aux propriétés PhoneApplicationPage.SupportedOrientations et Orientation est l’élément uap :InitialRotationPreference dans le manifeste du package d’application. Sélectionnez l’onglet Application s’il n’est pas déjà sélectionné et cochez une ou plusieurs cases sous Rotations prises en charge pour enregistrer vos préférences.

Toutefois, vous êtes encouragé à concevoir l’interface utilisateur de votre application UWP pour qu’elle soit idéale, quelle que soit l’orientation de l’appareil et la taille de l’écran. Il y a plus d’informations à ce sujet dans Portage pour les facteurs de forme et l’expérience utilisateur, qui est la rubrique après la prochaine.

La rubrique suivante consiste à porter des couches métier et de données.