Partager via

Créer une application Windows universelle multi-instance

Cette rubrique explique comment créer des applications de plateforme Windows universelle (UWP) multi-instances.

À partir de Windows 10, version 1803 (10.0 ; Build 17134) et versions ultérieures, votre application UWP peut choisir de prendre en charge plusieurs instances. Si une instance d'une application UWP multi-instance fonctionne et qu'une demande d'activation ultérieure est reçue, la plateforme n'active pas l'instance existante. Au lieu de cela, elle crée une instance qui s’exécute dans un processus distinct.

Important

L’instanciation multiple est prise en charge pour les applications JavaScript, mais la redirection d’instanciation multiple ne l’est pas. Étant donné que la redirection multi-instanciation n’est pas prise en charge pour les applications JavaScript, la classe AppInstance n’est pas utile pour ces applications.

Optez pour le comportement multi-instance

Si vous créez une application multi-instance, vous pouvez installer les modèles de projet d’application multi-instances .VSIX, disponibles à partir de la Visual Studio Marketplace. Une fois que vous avez installé les modèles, ils seront disponibles dans la boîte de dialogue Nouveau Projet sous Visual C# > Windows Universelle (ou Autres Langages > Visual C++ > Windows Universelle).

Remarque

Le modèle projet d’application multi-instance n’est plus disponible. Le modèle VSIX était pratique. Vous devrez donc modifier le projet existant, comme décrit ci-dessous. Veillez à ajouter la constante DISABLE_XAML_GENERATED_MAIN aux symboles de build du projet, car cela empêche la génération d’un main() par défaut. Cela permet d’utiliser une version spécifique à l’application spécialement écrite de Main().

Deux modèles sont installés : application UWP multi-instance, qui fournit le modèle de création d’une application multi-instance et application UWP de redirection multi-instance, qui fournit une logique supplémentaire sur laquelle vous pouvez créer une nouvelle instance ou activer de manière sélective une instance qui a déjà été lancée. Par exemple, vous ne souhaitez peut-être qu’une seule instance à la fois pour modifier le même document, de sorte que vous mettez l’instance qui a ce fichier ouvert au premier plan plutôt que de lancer une nouvelle instance.

Les deux modèles ajoutent des SupportsMultipleInstances au fichier package.appxmanifest. Veuillez noter les préfixes d'espaces de noms desktop4 et iot2: seuls les projets qui ciblent l'ordinateur de bureau ou les projets IoT (Internet des objets) prennent en charge la multi-instanciation.

<Package
  ...
  xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
  xmlns:iot2="http://schemas.microsoft.com/appx/manifest/iot/windows10/2"  
  IgnorableNamespaces="uap mp desktop4 iot2">
  ...
  <Applications>
    <Application Id="App"
      ...
      desktop4:SupportsMultipleInstances="true"
      iot2:SupportsMultipleInstances="true">
      ...
    </Application>
  </Applications>
   ...
</Package>

Redirection d’activation à plusieurs instances

La prise en charge des instances multiples pour les applications UWP va au-delà de la simple possibilité de lancer plusieurs instances d'une application. Il permet la personnalisation dans les cas où vous souhaitez sélectionner si une nouvelle instance de votre application est lancée ou une instance déjà en cours d’exécution est activée. Par exemple, si l’application est lancée pour modifier un fichier déjà modifié dans une autre instance, vous pouvez rediriger l’activation vers cette instance au lieu d’ouvrir une autre instance qui modifie déjà le fichier.

Pour la voir en action, regardez cette vidéo sur la création d’applications UWP multi-instances.

Le modèle application UWP de redirection multi-instance ajoute SupportsMultipleInstances au fichier package.appxmanifest, comme indiqué ci-dessus, et ajoute également un Program.cs (ou Program.cpp, si vous utilisez la version C++ du modèle) à votre projet qui contient une fonction Main(). La logique de redirection de l’activation passe dans la fonction Main. Le modèle de Program.cs est illustré ci-dessous.

La propriété AppInstance.RecommendedInstance représente l’instance préférée fournie par l’interpréteur de commandes pour cette demande d’activation, s’il existe un (ou null s’il n’en existe pas). Si l’interpréteur de commandes fournit une préférence, vous pouvez rediriger l’activation vers cette instance ou l’ignorer si vous le choisissez.

public static class Program
{
    // This example code shows how you could implement the required Main method to
    // support multi-instance redirection. The minimum requirement is to call
    // Application.Start with a new App object. Beyond that, you may delete the
    // rest of the example code and replace it with your custom code if you wish.

    static void Main(string[] args)
    {
        // First, we'll get our activation event args, which are typically richer
        // than the incoming command-line args. We can use these in our app-defined
        // logic for generating the key for this instance.
        IActivatedEventArgs activatedArgs = AppInstance.GetActivatedEventArgs();

        // If the Windows shell indicates a recommended instance, then
        // the app can choose to redirect this activation to that instance instead.
        if (AppInstance.RecommendedInstance != null)
        {
            AppInstance.RecommendedInstance.RedirectActivationTo();
        }
        else
        {
            // Define a key for this instance, based on some app-specific logic.
            // If the key is always unique, then the app will never redirect.
            // If the key is always non-unique, then the app will always redirect
            // to the first instance. In practice, the app should produce a key
            // that is sometimes unique and sometimes not, depending on its own needs.
            string key = Guid.NewGuid().ToString(); // always unique.
                                                    //string key = "Some-App-Defined-Key"; // never unique.
            var instance = AppInstance.FindOrRegisterInstanceForKey(key);
            if (instance.IsCurrentInstance)
            {
                // If we successfully registered this instance, we can now just
                // go ahead and do normal XAML initialization.
                global::Windows.UI.Xaml.Application.Start((p) => new App());
            }
            else
            {
                // Some other instance has registered for this key, so we'll 
                // redirect this activation to that instance instead.
                instance.RedirectActivationTo();
            }
        }
    }
}

Main() est la première chose à s’exécuter. Il s’exécute avant onLaunched et OnActivated . Cela vous permet de déterminer s’il faut activer cette instance ou une autre instance avant l’exécution d’un autre code d’initialisation dans votre application.

Le code ci-dessus détermine si une instance existante ou nouvelle de votre application est activée. Une clé est utilisée pour déterminer s’il existe une instance existante que vous souhaitez activer. Par exemple, si votre application peut être lancée pour Gérer l’activation de fichiers, vous pouvez utiliser le nom de fichier comme clé. Vous pouvez ensuite vérifier si une instance de votre application est déjà inscrite auprès de cette clé et l’activer au lieu d’ouvrir une nouvelle instance. Il s’agit de l’idée derrière le code : var instance = AppInstance.FindOrRegisterInstanceForKey(key);

Si une instance inscrite avec la clé est trouvée, cette instance est activée. Si la clé est introuvable, l’instance actuelle (l’instance en cours d’exécution Main) crée son objet d’application et commence à s’exécuter.

Tâches d'arrière-plan et instances multiples

  • Les tâches en arrière-plan hors processus prennent en charge l'instanciation multiple. En règle générale, chaque nouveau déclencheur entraîne une nouvelle instance de la tâche en arrière-plan (bien que techniquement, plusieurs tâches en arrière-plan puissent s’exécuter dans le même processus hôte). Néanmoins, une autre instance de la tâche en arrière-plan est créée.
  • Les tâches en arrière-plan en processus ne prennent pas en charge la multi-instanciation.
  • Les tâches audio en arrière-plan ne prennent pas en charge les instances multiples.
  • Lorsqu’une application inscrit une tâche en arrière-plan, elle vérifie généralement si la tâche est déjà inscrite, puis supprime et réinscrit celle-ci ou ne fait rien pour conserver l’inscription existante. Il s’agit toujours du comportement classique avec les applications multi-instances. Toutefois, une application de multi-instanciation peut choisir de s'enregistrer avec un nom de tâche d'arrière-plan différent pour chaque instance. Cela entraîne plusieurs inscriptions pour le même déclencheur, et plusieurs instances de tâche en arrière-plan seront activées lorsque le déclencheur est déclenché.
  • App Services lance une instance distincte de la tâche d'arrière-plan du service de l'application pour chaque connexion. Cela reste inchangé pour les applications multi-instances, c’est-à-dire que chaque instance d’une application multi-instance obtient sa propre instance de la tâche en arrière-plan app-service.

Considérations supplémentaires

  • L'instanciation multiple est prise en charge par les applications UWP qui ciblent les projets de bureau et d'Internet des objets (IoT).
  • Pour éviter les problèmes de concurrence et de contention, les applications multi-instances doivent prendre des mesures pour partitionner/synchroniser l’accès aux paramètres, au stockage local d’application et à toute autre ressource (comme les fichiers utilisateur, un magasin de données, etc.) qui peuvent être partagées entre plusieurs instances. Les mécanismes de synchronisation standard tels que les mutex, les sémaphores, les événements, etc. sont disponibles.
  • Si l’application a SupportsMultipleInstances dans son fichier Package.appxmanifest, ses extensions n’ont pas besoin de déclarer SupportsMultipleInstances.
  • Si vous ajoutez SupportsMultipleInstances à une autre extension, en dehors des tâches en arrière-plan ou des services d’application, et que l’application qui héberge l’extension ne déclare pas non plus SupportsMultipleInstances dans son fichier Package.appxmanifest, une erreur de schéma est générée.
  • Les applications peuvent utiliser la déclaration ResourceGroup dans leur manifeste pour regrouper plusieurs tâches en arrière-plan dans le même hôte. Cela est en conflit avec la multi-instanciation, où chaque activation est placée dans un hôte distinct. Par conséquent, une application ne peut pas déclarer SupportsMultipleInstances et ResourceGroup dans son manifeste.

Échantillon

Consultez l'échantillon multi-instance pour un exemple de redirection d’activation multi-instance.

Voir aussi

AppInstance.FindOrRegisterInstanceForKeyAppInstance.GetActivatedEventArgsAppInstance.RedirectActivationToGérer l’activation des applications