Windows Azure Mobile Services : Aperçu

Suite au Windows App Day et à l’excellente session de Kristof Rennen sur les Mobile Services, je me suis dit que je pourrais également faire un article sur le sujet. J’en avais parlé à l’occasion du premier Café Numérique de Tournai. Voici en quelques mots de quoi il s’agit 🙂

Les technologies évoluent, et les utilisateurs sont de mieux en mieux équipés et deviennent plus exigeants. Comment faire en sorte de créer une application qui soit à la hauteur de la demande des utilisateurs ?

Il y a en quelque sorte un minimum requis d’office. Des features indispensables. Et cela peut parfois décourager le développeur qui souhaiterait se lancer. Par exemple, une application uniquement offline aura peu de chance de survivre après une réinstallation ou un changement de device, parce que l’utilisateur sera frustré d’avoir perdu ses données…

Plusieurs difficultés s’opposent aux développeurs qui veulent se démarquer. Ils doivent par exemple :

• Mettre au point un service web, sans spécialement savoir comment s’y prendre
• Rendre ce service disponible via internet
• S’habituer à la programmation asynchrone
• Mettre en place et maintenir un moyen d’identification de l’utilisateur pour des scénarios un peu plus avancés

Tout cela demande de l’investissement et du temps. Et c’est là qu’il est bon de parler de Windows Azure Mobile Services.

A eux seuls, les Mobile Services d’Azure résolvent les 4 points cités ci-dessus, et permettent encore davantage !

• Ils permettent de créer une API de type REST en quelques clics, sans avoir à écrire une seule ligne de code.
• Ils sont directement hébergés sur le cloud de Windows Azure, et sont pour le moment gratuits (jusqu’à 10 services).
• Ils sont accompagnés d’un SDK disponible sur Windows 8, Windows Phone 8 et iOS et qui permet de communiquer hyper simplement avec le service, facilitant ainsi le développement.
• Ils proposent de prendre en charge pour vous la gestion de l’identification avec différents providers tels que Microsoft (live), Facebook, Twitter et Google. Cela signifie que vous n’avez plus besoin de vous occuper vous mêmes des évolutions des APIs de chacun des providers. Microsoft le fait pour vous !

Création d’un service

La création en elle-même prend quelques secondes. Cela se passe en deux étapes. Choix du nom du service et association d’une base de données.

On propose un nom de service. Azure vérifie que ce nom soit disponible. Si oui, on choisit entre la création et la réutilisation d’une base de données, et on passe à l’étape suivante qui est la configuration de cette dernière. Une fois qu’on a rempli ce rapide formulaire, Azure fait son boulot pour nous fournir un service mobile tout neuf.

Une fois le service créé, on a accès à l’habituel tableau de bord (dashboard) qui permet de contrôler rapidement l’utilisation du service en temps réel. Dès lors, le service est bel et bien disponible ! 30 secondes pour créer un service, c’est l’une des forces du cloud.

Pour pouvoir commencer à utiliser ce service et stocker des données, on va commencer par créer une nouvelle table via le portail.

Et c’est comme ça qu’en quelques clics, on résout les deux premiers problèmes du développeur ! Nous avons une API qui permet de stocker des données dans une table TodoItem, et qui est accessible via internet.

Utilisation du Mobile Services SDK

Si vous n’êtes pas familier avec les HttpClient et n’avez aucune idée de comment interroger un service REST en C#, ce n’est pas grave. Lorsque vous créez votre premier service, Azure vous propose de télécharger une application d’exemple utilisant le Mobile Service SDK.

Ce SDK va vous faciliter la vie pour communiquer avec le service mobile et notamment pour effectuer les opérations de base que sont la lecture, l’insertion, la mise à jour et la suppression de données.

Cette application contient une interface minimale pour gérer nos Todo.

Si on regarde un peu les sources, on peut trouver dans la classe App un bout de code qui instancie un MobileServiceClient grâce à l’url du service et à la clé secrète de l’API (que l’on peut trouver sur le portail Azure) :

        public static MobileServiceClient MobileService = new MobileServiceClient(
            "https://cafentournai.azure-mobile.net/",
            "ryPMCIcJjtbkqmWrkGphhiHJXdIyoI27"
            );

Et là, vous vous dites sans doute qu’on n’a même pas encore défini ce qu’était un TodoItem…

En fait, par défaut, le Mobile Service travaille avec des tables à schéma dynamique. Cela signifie que des colonnes sont automatiquement ajoutées pour pouvoir stocker toutes les propriétés des objets envoyés lors des requêtes ! Il n’y a donc pas besoin de décrire les tables côté service. On va simplement définir la classe côté client, avec quelques attributs :

    public class TodoItem
    {
        public int Id { get; set; }

        [DataMember(Name = "text")]
        public string Text { get; set; }

        [DataMember(Name = "complete")]
        public bool Complete { get; set; }
    }

A partir de là, on peut faire appel au service avec un peu de Linq. Par exemple, récupérer la liste des TodoItems qui n’ont pas encore été complété.

        List<TodoItem> items;

        private async void RetrieveUncompleteTodoItems()
        {
            IMobileServiceTable<TodoItem> todoTable = App.MobileService.GetTable<TodoItem>();

            // The query excludes completed TodoItems
            items = await todoTable
                .Where(todoItem => !todoItem.Complete)
                .ToListAsync();
        }

Laisser Azure gérer l’identification

Pour finir, ajouter une identification dans vos applications peut être un gros plus ! Pour garder un backup des données de l’utilisateur, ou permettre la synchronisation de données entre différents devices.

Cela permet également de donner des droits d’accès plus spécifiques à chaque table : si vous vous rappelez de l’étape de création de la table TodoItem, vous vous souvenez sans doute qu’il était possible de préciser des différents niveaux de permissions pour chaque fonction CRUD :

• Everyone : cette option rend toutes vos données accessibles par défaut
• Anyone with the Application Key : cette option restreint l’utilisation aux applications/utilisateurs possédant la clé secrète
• Only Authenticated Users : les utilisateurs doivent être identifiés pour pouvoir communiquer avec l’API
• Only Scripts and Admins : limite l’utilisation à la clé maître, ou aux scripts côté serveur.

Pour configurer tout ça, il suffit d’aller dans la partie Identity du portail, et de fournir des « clés » qui vous nous identifier auprès de différents providers tels que Microsoft, Facebook, Twitter, …

On peut donc aller sur https://developers.facebook.com/ ou https://dev.twitter.com/, créer une « application » pour obtenir des clés, et laisser nos utilisateurs s’identifier grâce à leurs propres comptes.

Pour les comptes Microsoft, il faut aller sur le portail http://manage.dev.live.com/.

De retour dans mon application, il suffit d’une ligne de code pour demander à l’utilisateur de se connecter :

var user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Twitter);

La méthode LoginAsync prend en paramètre le provider que l’on veut utiliser. Dans ce cas-ci, c’est Twitter. Une interface familière va s’afficher pour demander à l’utilisateur d’entrer ses identifiants.

La méthode LoginAsync est effectivement asynchrone. C’est pour cela que l’on utilise le mot clé await. Lorsque l’utilisateur a entré ses informations et autorisé l’application, la tâche est effectivement terminée et retourne un objet décrivant l’utilisateur.

A partir de ce moment, l’utilisateur peut communiquer avec l’API. Il n’y a rien d’autre à faire… Ce n’est donc pas à vous de devoir maintenir du code, et si demain Twitter ou Facebook décidaient de changer radicalement la manière dont fonctionnent leurs APIs, Microsoft mettrait à jour son SDK et votre application serait toujours fonctionnelle.

Toutefois, cette façon de faire est assez limitée. Les utilisateurs ne restent pas connectés d’une session à l’autre, et doivent entrer leurs identifiants à chaque fois, ce qui semble un peu curieux. Mais d’après un post d’un employé de Microsoft sur MSDN, une mise à jour du SDK devrait sortir prochainement pour apporter une solution ! 🙂

As Xinyang notes, we’ll soon be making improvements to our Login API to provide support for WebAuthenticationBroker’s SSO feature.

Also, in just a few weeks we’ll be releasing an update that enables you to get and, most importantly, set the authenticationToken and userId meaning that you can cache the full Mobile Services credentials however you see fit. We’ll provide plenty of samples that show how this works.

Dans un prochain article, on parlera plus en détails de l’identification, et de comment on peut dès maintenant permettre à l’utilisateur de ne pas devoir s’identifier à chaque session.