Microsoft a mis à disposition des développeurs une première version du SDK Windows 10 cette semaine. Dans cette mouture, il y a pleins de bonnes nouvelles choses pour faire de la communication inter-applications et notamment AppService ! C’est un sujet qui m’intéresse tout particulièrement car c’est une problématique cruciale dans le cadre de développement d’applications B2B. Etudions un peu ce que c’est !

(Attention, nous ne sommes encore que sur une preview du SDK !)

Qu’est ce que c’est ?

Actuellement, la communication inter-applications est assez limitée à ces options :

• via un protocole implémenté par l’application cible : limité à un passage d’arguments sous forme de caractères
• via une extension de fichier “gérée” par l’application cible.
• via le contrat de partage.

Pour chacune de ces possibilités, on ne peut (malheureusement) pas cibler une application en particulier et il n’y a pas de communication “en retour” par l’application lancée. C’est assez limitant et cela implique aussi d’avoir l’application cible qui se lance de façon visible pour l’utilisateur.

AppService propose une nouvelle façon de communiquer. En une phrase, cela permet d’exposer une sorte de service web local hébergé dans votre application aux autres applications Windows Store.

Comment le mettre en place ?

Concrètement, AppService est implémenté sous la forme d’une BackgroundTask. Il faut donc implémenter l’interface IBackgroundTask et implémenter celle-ci. On pourra caster les informations de celle-ci en AppServiceTriggerDetails pour avoir plus de détails.

public sealed class AppServiceBackgroundTaskImpl : IBackgroundTask
{
    public void Run(IBackgroundTaskInstance taskInstance)
    {
        var appServiceInfo = taskInstance.TriggerDetails as AppServiceTriggerDetails;
        if (appServiceInfo != null)
        {
            //nom du service lancé
            var name = appServiceInfo.Name;

        }
    }
}

Il est aussi nécessaire de la déclarer dans le fichier de manifest de l’application de façon assez classique :

<Extensions>
  <uap:Extension Category="Windows.appservice"
                 EntryPoint="AppServiceBackgroundTask.AppServiceBackgroundTaskImpl"/>
  <uap:AppService Name="NousAInfiniteSquareAppService"/>
</Extensions>

Comment communiquer entres applications ?

La communication se fait ensuite de façon assez classique par rapport à un appel réseau  depuis l’app cliente : 

1. Ouverture de la communication. L’API nous indique le succès, l’échec mais aussi si l’application n’est pas présente sur le PC pour que l’on puisse demander l’installation à l’utilisateur.
2. Définition d’un message sous la forme clef/valeur
3. Envoi du message
4. Fermeture de la connexion.

using (var appServiceConn = new AppServiceConnection())
{
    //Configuration pour cibler la bonne app
    appServiceConn.AppServiceName = "NousAInfiniteSquareAppService";
    appServiceConn.PackageFamilyName = "PackageFamilyNameDeLAppli";

    //Ouverture de la connection
    var status = await appServiceConn.OpenAsync();

    //On peut savoir si l'app est installée aussi
    if (status != AppServiceConnectionStatus.Success)
    {
        return;
    }

    //Définition du message
    var message = new ValueSet();
    message.Add("Command", "Dis bonjour");

    //Envoi du message
    var resp = await appServiceConn.SendMessageAsync(message);

    if (resp.Status != AppServiceResponseStatus.Success)
    {
        //Message d'erreur
    }
}

Dans la background task (côté serveur), l’utilisation du principe de “deferal” est de mise. Il s’agit de récupérer un deferral pour la durée de vie du service dans le premier “Run” de la background task et ensuite d’en utiliser un pour chaque requête.

Le code est au final très simple et consiste à s’abonner à un évènement puis traité les messages reçus.

Dans la méthode “run”, on ajoute :

//Abonnement à la reception d'une requete
appServiceInfo.AppServiceConnection.RequestReceived 
    += AppServiceConnection_RequestReceived;

//Récupération du deferral pour le service
_seviceDeferral = taskInstance.GetDeferral();

Et le traitement de chaque requete est implémenté de cette façon :

private async void AppServiceConnection_RequestReceived
    (AppServiceConnection sender, AppServiceRequestReceivedEventArgs args)
{
    var requestDeferral = args.GetDeferral();

    //lecture de la commande
    var commande = args.Request.Message.FirstOrDefault(k => k.Key == "Command");

    switch (commande.Value as string)
    {
        case "Dis bonjour":
            var response = new ValueSet();
            response.Add("response", "bonjour");
            await args.Request.SendResponseAsync(response);
            break;
        case "Quit":

            //Fin du service
            _seviceDeferral.Complete();
            break;
    }

    //Fin de la requete
    requestDeferral.Complete();
}

Quelles sont les limitations ?

La bonne nouvelle est qu’il n’y a pas de limite annoncée en termes de consommation “CPU” comme cela est le cas sur une background task classique. Attention, il est cependant toujours possible que la background task correspondant à l’AppService ne soit pas lancé par manque de ressources sytèmes.

Par contre, il y a une limitation au niveau du volume de données échangées : seulement quelques centaines de Ko. Je pense cependant que cela est suffisant pour un grand nombre de scenarii.

Autre limitation : cette communication ne fonctionne qu’entre deux applications Windows Store actuellement. Il sera peut être possible de le faire avec une application Desktop à terme (comme il est possible d’utiliser des APIs WinRT).

Conclusion

Ce n’est qu’une version “preview” de ce que sera le SDK mais on peut déjà voir ici que Microsoft a décider de faciliter la vie des développeurs d’applications d’entreprise. Cela permet aussi de nombreux scenarii pour les applications grand public et les développeurs que nous sommes. Imaginez par exemple que Facebook expose un AppService aux autres applications

Dans de prochains articles, nous verrons les autres améliorations apportées dans ce SDK Windows 10.