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 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)

Pour une application Universelle 8.1, il existe une fenêtre de délai de deux secondes entre l’application devenant inactive et le système qui déclenche l’événement de suspension. L’utilisation de cette fenêtre de débogage comme délai supplémentaire pour suspendre l’état est dangereuse et, pour une application 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.

Contenu audio en arrière-plan

Pour la propriété MediaElement.AudioCategory , ForegroundOnlyMedia et BackgroundCapableMedia sont déconseillés pour les applications Windows 10. Utilisez plutôt le modèle d’application du Windows Phone Store. Pour plus d’informations, consultez l’audio en arrière-plan.

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.

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.

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 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.

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. 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.