Partager via

Applications kiosque pour l’accès affecté : Meilleures pratiques

Dans Windows 10, vous pouvez utiliser l’accès affecté pour créer un appareil kiosque, ce qui permet aux utilisateurs d’interagir avec une seule application Windows universelle. Cet article explique comment implémenter une application kiosque et les meilleures pratiques.

Il existe deux expériences différentes que fournit l’accès affecté :

  1. Expérience kiosque à application unique

    Affectez une application à un compte. Lorsqu’un utilisateur se connecte, il a accès uniquement à cette application et rien d’autre sur le système. Pendant ce temps, l’appareil kiosque est verrouillé, avec l’application kiosque s’exécutant au-dessus de l’écran de verrouillage. Cette expérience est souvent utilisée pour les machines kiosque publiques. Pour plus d’informations , consultez Configurer un kiosque sur Windows 10 Professionnel, Entreprise ou Éducation .

  2. Expérience kiosque multi-application (disponible dans Windows 10, version 1709 et ultérieure)

    Vous pouvez affecter une ou plusieurs applications à un compte. Lorsqu’un utilisateur se connecte, l’appareil démarre dans une expérience d’interpréteur de commandes restreinte avec accès uniquement à vos applications sélectionnées. Pour plus d’informations, consultez Créer un kiosque Windows 10 qui exécute plusieurs applications .

Cet article décrit uniquement l’expérience kiosque à application unique. Dans l’expérience multi-application, les applications sélectionnées s’exécutent dans un contexte de bureau standard et ne nécessitent aucune gestion ou modification particulière.

Termes

Terme Descriptif
accès assigné Fonctionnalité qui permet à un administrateur système de gérer l’expérience de l’utilisateur en limitant les points d’entrée d’application exposés à l’utilisateur de l’appareil. Par exemple, vous pouvez restreindre les clients de votre entreprise à l’utilisation d’une application afin que votre PC agisse comme un kiosque. Chaque fois qu’une personne se connecte avec le compte spécifié, elle n’est en mesure d’utiliser qu’une seule application. Ils ne peuvent pas changer d’application ou fermer l’application à l’aide de mouvements tactiles, d’une souris, d’un clavier ou d’un bouton matériel. Ils ne voient pas non plus de notifications d’application.
application de verrouillage d'écran (ou application de verrouillage) Application qui tire parti de la possibilité de définir un papier peint dynamique ou qui tire parti du nouveau framework d’extensibilité de verrou.
application d’écran de verrouillage ci-dessus (ou application de verrouillage ci-dessus) Application qui démarre au-dessus de l’écran de verrouillage pendant l’exécution de l’application d’écran de verrouillage (par exemple, lorsque le bureau est verrouillé).
sous l’application de verrouillage Application qui s’exécute normalement, dans un contexte Windows déverrouillé.
LockApplicationHost Classe WinRT qui permet aux applications fonctionnant au-dessus de l'écran de verrouillage de demander que l’appareil se déverrouille et permet à l’application d’être avertie lorsque l’appareil commence à se déverrouiller.
Affichage ou Vue d’application Chaque vue est une fenêtre distincte dans l’application. Une application peut avoir une vue principale et créer plusieurs vues secondaires à la demande. Pour plus d’informations, consultez ApplicationView .

L'extension windows.aboveLockScreen

L’accès affecté dans Windows 10 utilise l’infrastructure de verrouillage. Lorsqu’un utilisateur d’accès affecté se connecte, une tâche en arrière-plan verrouille le bureau et lance l’application kiosque au-dessus du verrou. Le comportement de l’application peut différer, selon qu’elle utilise l’extension windows.aboveLockScreen.

L’utilisation de windows.aboveLockScreen permet à votre application kiosque d’accéder à la classe d’exécution LockApplicationHost , ce qui permet à l’application de savoir quand elle s’exécute au-dessus du verrou (et donc en cours d’exécution en tant qu’expérience kiosque). Si une instance ne peut pas être retournée, l’application s’exécute dans un contexte de bureau normal.

Lorsque l’infrastructure de verrouillage lance l’application kiosque au-dessus du verrou et que l’application dispose de l’extension windows.aboveLockScreen , l’infrastructure de verrouillage crée automatiquement une nouvelle vue secondaire au-dessus du verrou. La vue principale se trouve sous le verrou. Cette vue secondaire contient le contenu de votre application et est ce que l’utilisateur voit. Cette vue peut être utilisée avec l’extension pour personnaliser votre expérience kiosque. Par exemple, vous pouvez :

Si l’application n’a pas l’extension windows.aboveLockScreen , aucune vue secondaire n’est créée et l’application démarre comme si elle s’exécute normalement. En outre, étant donné que l’application n’aura pas accès à une instance de LockApplicationHost, elle ne pourra pas déterminer si elle s’exécute dans un contexte normal ou pour une expérience kiosque. Ne pas inclure l’extension présente des avantages, tels que la possibilité de prendre en charge plusieurs moniteurs

Que votre application utilise l’extension, veillez à sécuriser ses données. Pour plus d’informations, consultez les instructions relatives aux applications d’accès attribuées .

À compter de Windows 10, version 1607, il n’existe plus de restriction sur l’extension de plateforme Windows universelle (UWP), de sorte que la plupart des applications peuvent être affichées dans Paramètres lorsque l’utilisateur configure l’accès affecté.

Meilleures pratiques

Cette section s’applique à une application Kiosque qui utilise l’extension windows.aboveLockScreen .

Sécuriser vos informations

Si l'application kiosque est destinée à s'exécuter à la fois au-dessus de l'écran de verrouillage dans l'accès assigné et également dans le contexte de Windows déverrouillé, vous pouvez créer une page différente pour s'afficher au-dessus de l'écran de verrouillage et une autre page pour s'afficher sous l'écran de verrouillage. Cela vous permet d’éviter d’afficher des informations sensibles en mode plein écran, car le mode plein écran signifie généralement un accès anonyme. Voici les étapes que vous devez suivre pour utiliser deux pages différentes, une pour sous le verrou et une pour au-dessus du verrou :

  1. Dans le remplacement de la fonction OnLaunched dans App.xaml.cs, essayez d’obtenir une instance de la classe LockApplicationHost avant la navigation rootFrame.

  2. Si l’appel échoue, l’application kiosque doit se lancer normalement, sous le verrou.

  3. Si l’appel réussit, l’application kiosque doit se lancer au-dessus du verrou en mode d’accès affecté. Vous souhaiterez peut-être que cette version de l’application kiosque dispose d’une autre page principale pour masquer les informations sensibles.

L’exemple suivant montre comment procéder. AssignedAccessPage.xaml est prédéfini et l'application navigue vers AssignedAccessPage.xaml lorsqu'elle détecte qu'elle s'exécute en mode au-dessus du verrouillage. Par conséquent, la page normale s’affiche uniquement dans le scénario de verrouillage.

Vous pouvez utiliser cette méthode pour déterminer si l’application s’exécute au-dessus de l’écran de verrouillage à tout moment dans le cycle de vie de l’application et réagir en conséquence.

using Windows.ApplicationModel.LockScreen;

// inside the override OnLaunched function in App.xaml.cs

if (rootFrame.Content == null)
{
    LockApplicationHost host = LockApplicationHost.GetForCurrentView();
    if (host == null)
    {
        // if call to LockApplicationHost is null, this app is running under lock
        // render MainPage normally
        rootFrame.Navigate(typeof(MainPage), e.Arguments);
    }
    else
    {
        // If LockApplicationHost was successfully obtained
        // this app is running as a lock screen app, or above lock screen app
        // render a different page for assigned access use
        // to avoid showing regular main page to keep secure information safe
        rootFrame.Navigate(typeof(AssignedAccessPage), e.Arguments);
    }
}

Affichages multiples, fenêtres et threads

À compter de Windows 10, version 1803, plusieurs vues sont prises en charge dans l’expérience kiosque pour les applications qui n’ont pas l’extension windows.aboveLockScreen . Pour utiliser plusieurs affichages, vérifiez que l’option Affichages multiples de l’appareil kiosque est définie pour étendre ces affichages.

Lorsqu’une application avec plusieurs vues (et sans windows.aboveLockScreen) est lancée pendant une expérience kiosque, la vue principale de l’application est affichée sur le premier moniteur. Si une nouvelle vue est créée par l’application à l’aide de CreateNewView(), elle est rendue sur le deuxième moniteur. Si l’application crée une autre vue, elle passe au troisième moniteur, et ainsi de suite.

Important

Les appareils de kiosque ne peuvent afficher qu'une seule vue par écran. Par exemple, si l’appareil kiosque n’a qu’un seul moniteur, il affiche toujours l’affichage principal de l’application kiosque. Les nouvelles vues créées par l’application ne seront pas affichées.

Lorsqu’une application kiosque a l’extension windows.aboveLockScreen et s’exécute au-dessus du verrou, elle est initialisée différemment. Sa vue principale se trouve sous le verrou, avec une vue secondaire au-dessus de celle-ci. Cette vue secondaire est ce que l’utilisateur voit. Même si vous ne créez pas de nouvelles vues explicitement, vous disposez toujours de deux vues dans l’instance de l’application.

Ordre z pour les vues lorsque l'application fonctionne en mode verrouillage.

Vous pouvez exécuter le code suivant dans la fenêtre principale de votre application (en mode d’accès affecté) pour afficher le nombre d’affichages et déterminer si l’écran actuel est l’affichage principal.

using Windows.ApplicationModel.Core;

CoreApplication.GetCurrentView().IsMain //false
CoreApplication.Views.Count //2

Répartiteur

Chaque vue ou fenêtre a son propre répartiteur. Étant donné que l’affichage principal est masqué à l’utilisateur, utilisez GetCurrentView() pour accéder à la vue secondaire de l’application s’exécutant au-dessus du verrou au lieu de MainView().

using Windows.ApplicationModel.Core;

private async void Button_Click(object sender, RoutedEventArgs e)
{
    button.IsEnabled = false;

    // start a background task and update UI periodically (every 1 second)
    // using MainView dispatcher in below code will end up with app crash
    // in assigned access mode, use GetCurrentView().Dispatcher instead
    await CoreApplication.GetCurrentView().Dispatcher.RunAsync(
        CoreDispatcherPriority.Normal,
        async () =>
        {
            for (int i = 0; i < 60; ++i)
            {
                // do some background work, here we use Task.Delay to sleep
                await Task.Delay(1000);
                // update UI
                textBlock1.Text = "   " + i.ToString();
            }
            button.IsEnabled = true;
        });
}

Lorsque l'application a windows.aboveLockScreen et s'exécute en mode kiosque, la création de nouvelles vues entraîne une exception pour l'application :

Windows.ApplicationModel.Core.CoreApplication.CreateNewView(); //causes exception

En raison de cela, vous ne pouvez pas avoir plusieurs vues ou exécuter sur plusieurs moniteurs. Si votre application doit prendre en charge l’une ou l’autre, vous devez supprimer l’extension windows.aboveLockScreen de votre application.

Ajouter un moyen de sortir de l’accès affecté

Dans certains cas, le bouton d’alimentation, le bouton d’échappement ou d’autres boutons utilisés pour arrêter une application peuvent ne pas être activés ou disponibles sur le clavier. Dans ces situations, fournissez un moyen d’arrêter l’accès affecté, par exemple une clé logicielle. Le gestionnaire d’événements suivant montre comment arrêter le mode d’accès affecté en répondant à un événement de sélection de bouton qui peut être déclenché par une clé logicielle.

LockApplicationHost^ lockHost = LockApplicationHost::GetForCurrentView();
    if (lockHost != nullptr)
    {
        lockHost->RequestUnlock();
    }

Gestion du cycle de vie

Le cycle de vie d’une application kiosque est géré par l’infrastructure d’accès affectée. Si l’application se termine de façon inattendue, le framework tente de le relancer. Si toutefois, un utilisateur appuie sur Ctrl+Alt+Del pour afficher l’écran de connexion, un événement de déverrouillage est déclenché. L’infrastructure d’accès affectée écoute l’événement et tente de mettre fin à l’application.

Votre application de kiosque peut également inscrire un gestionnaire pour cet événement et effectuer des actions avant de quitter l'application. L’enregistrement de toutes les données est un exemple de ceci. Consultez le code ci-dessous pour obtenir un exemple d’inscription d’un gestionnaire.

using Windows.ApplicationModel.LockScreen;

public AssignedAccessPage()
{
    this.InitializeComponent();

    LockApplicationHost lockHost = LockApplicationHost.GetForCurrentView();
    if (lockHost != null)
    {
        lockHost.Unlocking += LockHost_Unlocking;
}
}

private void LockHost_Unlocking(LockApplicationHost sender, LockScreenUnlockingEventArgs args)
{
    // save any unsaved work and gracefully exit the app
    App.Current.Exit();
}

Une fois que l’utilisateur appuie sur Ctrl+Alt+Del et qu’un écran de connexion s’affiche, deux choses peuvent se produire :

  1. L’utilisateur connaît le mot de passe du compte d’accès affecté et déverrouille le bureau. L’infrastructure d’accès affectée démarre, verrouille le bureau et l’application d’écran de verrouillage lance à son tour l’application kiosque.

  2. L’utilisateur ne connaît pas le mot de passe ou n’effectue aucune action supplémentaire. L'écran de connexion expire et le bureau se verrouille à nouveau ; puis l'application de l'écran de verrouillage se lance, et à son tour, lance l'application kiosque.

Ne créez pas de fenêtres ou de vues en mode d’accès affecté

L’appel de fonction suivant se termine par une exception d’exécution si elle est appelée en mode d’accès affecté. Si la même application, lorsqu’elle est utilisée sous verrou, appelle la fonction, elle n’entraîne pas d’exception d’exécution. Il est utile d’utiliser LockApplicationHost pour déterminer le mode d’accès attribué de l’application et coder votre application en conséquence, par exemple, de ne pas créer de vues si l’application est en mode d’accès affecté.

Windows.ApplicationModel.Core.CoreApplication.CreateNewView(); //causes exception

Annexe 1 : Extension UWP

L’exemple de manifeste d’application suivant utilise l’extension UWP windows.aboveLockScreen.

À compter de Windows 10, version 1607, il n’existe plus de restriction sur l’extension de plateforme Windows universelle (UWP), de sorte que la plupart des applications peuvent être affichées dans Paramètres lorsque l’utilisateur configure l’accès affecté.

<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" IgnorableNamespaces="uap mp">
  <Identity Name="bd4df68b-dc18-4748-a14e-bc21dac13736" Publisher="Contoso" Version="1.0.0.0" />
  <mp:PhoneIdentity PhoneProductId="bd4df68b-dc18-4748-a14e-bc21dac13736" PhonePublisherId="00000000-0000-0000-0000-000000000000" />
  <Properties>
    <DisplayName>AboveLock</DisplayName>
    <PublisherDisplayName>Contoso</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.0.0" MaxVersionTested="10.0.0.0" />
  </Dependencies>
  <Resources>
    <Resource Language="x-generate" />
  </Resources>
  <Applications>
    <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="AboveLock.App">
      <uap:VisualElements DisplayName="AboveLock" Square150x150Logo="Assets\Square150x150Logo.png" Square44x44Logo="Assets\Square44x44Logo.png" Description="AboveLock" BackgroundColor="transparent">
        <uap:DefaultTile Wide310x150Logo="Assets\Wide310x150Logo.png">
        </uap:DefaultTile>
        <uap:SplashScreen Image="Assets\SplashScreen.png" />
      </uap:VisualElements>
      <Extensions>
        <uap:Extension Category="windows.lockScreenCall" />
        <uap:Extension Category="windows.aboveLockScreen" />
      </Extensions>
    </Application>
  </Applications>
  <Capabilities>
    <Capability Name="internetClient" />
  </Capabilities>
</Package>

Annexe 2 : Résolution des problèmes

Normalement, si une application kiosque ne parvient pas à s’activer au-dessus de l’application d’écran de verrouillage, vous pouvez trouver le code d’erreur d’activation dans l’écran de verrouillage. Utilisez le code d’erreur pour découvrir le problème en recherchant des codes d’erreur système Windows. En outre, l’Observateur d’événements contient plus d’informations sur les échecs d’activation. Pour ce faire :

  1. Ouvrez l’ Observateur d’événements. Il existe deux endroits susceptibles de trouver des erreurs d’activation.

  2. Dans le volet Observateur d’événements (local), développez Journaux Windows, puis sélectionnez Application.

  3. De plus, dans l’Observateur d’événements (local), développez Applications et journaux des services, développez Windows, développez Applications, puis sélectionnez Microsoft-Windows-TWinUI/Operational.

Étant donné que les applications kiosque avec accès affecté ne s’exécutent pas en mode plein écran, ApplicationView.GetForCurrentView(). IsFullScreenMode retourne false.

Accès affecté

Afficher plusieurs vues pour une application