New Windows 10 SDK and newwindows10sdk

New Windows 10 SDK and newwindows10sdk

Overview

In the previous article About Windows 10 SDK Preview Build 17110, we briefly introduced the Multi-instance UWP Apps. Today, we will give a detailed explanation of the development process.

Before Windows 10 Version 1803, UWP App can start only one instance at a time. Starting from 1803, UWP App can support multiple instances through developer configuration selection. If a multi-instance UWP App is running and an activation request is sent, the platform does not directly activate the current instance, but creates a new instance and runs in a separate process.

Development Process

Configure multi-instance support

For Multi-Instance features, you need to install a new Project template in Visual Studio: Multi-Instance App Project Templates. VSIX. After installation, you can use C # And C ++ to create a Project.

Two templates will be installed:

• Multi-Instance UWP app-create an App with multiple instances
• Multi-Instance Redirection UWP app-provides an additional logic that allows you to choose to start a new Instance or select the currently activated Instance. You can imagine the scenario when the Office opens or edits a file.

Both templates add SupportsMultipleInstances to the manifest file. The top 4 and iot2 prefixes indicate that the project only supports traditional desktop Windows and IoT systems. The manifest configuration is as follows. We only keep the newly added parts:

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

During actual operation, a new instance is started every time you click the App tile. For example, the App displays the start time. In the taskbar and run window, you can see that the two instances are running at the same time.

 

Multi-instance activation redirection

The UWP App supports multiple instances so that multiple instances of the same App can run simultaneously. It is defined by the running developer, whether to enable a new instance or redirect a currently activated application each time. For example, if you want to use an App to edit a file that is being edited in the App, you should not start a new instance, instead, you should redirect the instance that is currently editing the file. This will use the Multi-Instance Redirection UWP app template.

The Multi-Instance Redirection UWP app template is the same as the one we saw above, and the manifest file will be adjusted the same. At the same time, this template will add a Program. cs file, which contains a Main () method. This method is used to implement the redirection operation for multi-instance activation.

Let's take a look at the Main () method in the Program. cs file.

• ActivatedArgs contains the parameters that we define when the application starts. Based on these parameters, such as keys, we determine the redirection mode for multiple instances;
• AppInstance. RecommendedInstance: The instance recommended by the system. If yes, we can redirect to this instance;
• The unique identifier key generation method between multiple instances. We can customize it according to activatedArgs. In the default sample code, the random number method is used to determine the single and double numbers;
• FindOrRegisterInstanceForKey (key) queries the instance of the current corresponding key. If not, a new instance is registered;
• Check whether the instance is newly registered. If yes, It is started. If it is the original instance queried, It is redirected to that instance;

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

    // In some scenarios, the platform might indicate a recommended instance.
    // If so, we can redirect this activation to that instance instead, if we wish.
    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.
        uint number = CryptographicBuffer.GenerateRandomNumber();
        string key = (number % 2 == 0) ? "even" : "odd";
        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();
        }
    }
}

Key Construction, judgment, and post-judgment processing are the key to multi-instance redirection. Let's take a look at the comments of FindOrRegisterInstanceForKey (key) and IsCurrentInstance:

//
// Summary:
// If another instance has already registered the key, use the platform to register an application instance or find an existing instance.
//
// Parameters:
// key:
// Non-empty string as instance key.
//
// Return result:
// Application instance representing the first application of the registered key.
public static AppInstance FindOrRegisterInstanceForKey (string key);

//
// Summary:
// Whether the current instance of the application is a registered instance of the specific key defined by the instance.
//
// Return result:
// A boolean indicating whether the current application is a registered instance of the application.
public bool IsCurrentInstance {get;} 

 

Background tasks and multiple instances

For multiple instances of background tasks, the official instructions are as follows:

• Background tasks outside the process support multiple instances. Generally, each newly triggered result is stored independently in an instance of the background task;
• Background tasks in the process do not support multiple instances;
• Background Music tasks do not support multiple instances;
• When an application registers a background task, it usually first checks whether the task has been registered, if it has been registered, or deletes it and re-creates it, or maintains the current registration. This is also a typical feature of Multi-instance applications. However, a multi-instance application may register a different backend task name based on each instance. The same trigger is registered multiple times, and multiple task instances are activated when the trigger is triggered;
• The application service starts a separate instance for the connection of each background task of the Application Service, which remains unchanged for the applications of multiple instances, that is, each instance of a Multi-instance application obtains its own background task instance of the Application Service;

 

Other considerations

For multi-instance applications, the official documentation also prompts some additional considerations:

• UWP applications that support multi-instance applications can only be applied to traditional desktop systems and IoT;
• To avoid competition conditions and resource competition, multi-instance applications need to take measures to set access permissions for partitions and synchronization, and apply local storage and any other resources (such as user files, data storage, etc.) to share among multiple instances. Standard synchronization mechanisms include mutexes, semaphores, and events;
• If the SupportsMultipleInstances field exists in the Package. appxmanifest file of the application, supportsmulultipleinstances does not need to be declared in its extension;
• If you add SupportsMultipleInstances to any extension other than the background task and Application Service, and the application hosting the extension does not declare SupportsMultipleInstances in Package. appxmanifest, a mode error occurs;
• Applications can use ResourceGroup in manifest to group multiple background tasks to the same host. This conflicts with multiple instances, and each activity will appear in a separate host. Because an application cannot declare SupportsMultipleInstances and ResourceGroup at the same time;

 

The introduction of multi-instance applications is here. You can use multiple instances based on your actual application scenarios and set key and judgment conditions more rationally. Thank you!