Portage de Windows Runtime 8.x vers UWP pour les E/S, l’appareil et le modèle d’application

La rubrique précédente était Portage XAML et 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)

Pour une application Universelle 8.1, il existe une fenêtre de deux secondes entre le moment où l'application devient inactive et celui où le système déclenche l'événement de suspension. L’utilisation de cette fenêtre de débounce comme temps supplémentaire pour suspendre l’état est dangereuse et pour une application de plateforme Windows universelle (UWP), il n’existe aucune fenêtre debounce du tout ; 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.

Audio d’arrière-plan

Pour la propriété MediaElement.AudioCategory, ForegroundOnlyMedia et BackgroundCapableMedia sont désormais désuets pour les applications Windows 10. Utilisez plutôt le modèle d’application du Windows Phone Store. Pour plus d’informations, consultez Audio de fond.

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

La façon de réfléchir aux modifications de ciblage des applications avec Windows 10. Le nouveau modèle conceptuel est qu’une application cible la 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.

Si vous avez du code dans votre application Universal 8.1 qui détecte le système d’exploitation sur lequel il s’exécute, vous devrez peut-être modifier cela en fonction de la raison de la logique. Si l’application transmet la valeur et n’agit pas dessus, vous pouvez continuer à collecter les informations du système d’exploitation.

Remarque 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 (voir compilation conditionnelle et le 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 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 (consultez 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 façon impérative et la rubrique ResourceContext.QualifierValues décrit le cas d’usage plus classique de la classe lors du chargement des 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 compilation conditionnelle, etcode adaptatif.

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. Cela est vrai si l’application est une application du Windows Phone Store ou une application Windows 10. Donc, si votre application affiche sa propre invite de consentement personnalisée ou offre un commutateur marche-arrêt, vous devrez le supprimer afin que l’utilisateur final ne soit invité qu’une seule fois.