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é :
Expérience kiosque à application unique
Affectez une application à un compte. Lorsqu’un utilisateur se connecte, il aura accès à cette application uniquement 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.
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 | Description |
|---|---|
| accès affecté | 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 ne pourra utiliser qu’une seule application. Ils ne pourront 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 d’écran de verrouillage (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 d’écran de verrouillage ci-dessus de demander que l’appareil se déverrouille et permet à l’application d’être avertie lorsque l’appareil commence à 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 . |
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 supplémentaire peut être utilisée avec l’extension pour adapter votre expérience kiosque. Par exemple, vous pouvez :
Sécurisez votre expérience kiosque en créant une page distincte pour afficher du contenu plein écran uniquement.
Appelez la méthode LockApplicationHost.RequestUnlock() de votre application pour ajouter un moyen de sortir du mode d’accès affecté et revenir à l’écran de connexion.
Ajoutez un gestionnaire d’événements à l’événement *LockApplicationHost.Unlocking qui se déclenche lorsqu’un utilisateur appuie sur Ctrl+Alt+Del pour quitter l’expérience kiosque. Le gestionnaire peut également être utilisé pour enregistrer des données avant de quitter.
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. L’inclusion de 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 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é.
Bonnes 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 à exécuter à la fois le verrou ci-dessus dans l’accès affecté et également dans le contexte Windows déverrouillé, vous pouvez créer une autre page pour afficher au-dessus du verrou et une autre page pour sous le verrou. 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 :
Dans le remplacement de la fonction OnLaunched dans App.xaml.cs, essayez d’obtenir une instance de la classe LockApplicationHost avant la navigation rootFrame.
Si l’appel échoue, l’application kiosque doit se lancer normalement, sous le verrou.
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 page principale différente pour masquer les informations sensibles.
L’exemple suivant montre comment procéder. AssignedAccessPage.xaml est prédéfini et l’application accède à AssignedAccessPage.xaml une fois qu’elle détecte qu’elle s’exécute en mode de verrouillage ci-dessus. 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 plein écran ne peuvent afficher qu’une seule vue par moniteur. 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 explicitement de vues, vous disposez toujours de deux vues dans l’instance de l’application.
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 tant qu’expérience kiosque, la création de vues entraîne une exception dans 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 ne peuvent 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 kiosque peut également inscrire un gestionnaire pour cet événement et effectuer des actions avant de quitter. 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 :
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.
L’utilisateur ne connaît pas le mot de passe ou n’effectue aucune action supplémentaire. Délai d’expiration de l’écran de connexion et verrouillage du bureau ; l’application d’écran de verrouillage lance à son tour 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 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 :
Ouvrez l’ Observateur d’événements. Il existe deux endroits susceptibles de trouver des erreurs d’activation.
Dans le volet Observateur d’événements (local), développez Journaux Windows, puis sélectionnez Application.
En outre, 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.
Articles connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour