Planning de la rentrée 2013-2014

Trainings gratuits au Microsoft Innovation Center de Mons

Plein de nouvelles formations planifiées au MIC pour la rentrée, avec des sessions sur Windows Phone et Windows 8 en C#/XAML et en JavaScript/HTML5! Toutes ces formations sont évidemment gratuites, en français, et ouvertes à tous!

Create your Windows 8 app in HTML5

How different is Windows 8? What is the rush to build apps for the Windows 8 platform and why are developer communities reacting differently to Windows 8?  This Windows Store App course introduces HTML5, CSS3, and JavaScript and helps you learn HTML5/CSS3/JavaScript programming skills. This course is an entry point into both the Web application and Windows Store apps.

 18 septembre, 5 novembre, 10 janvier

 

The Ins & Outs of Windows Phone 8 apps

The ins & outs of Windows Phone 8 is a hands on introduction to building apps for Windows Phone. We’ll guide you through the unique aspects of the Windows Phone platform and you’ll have the chance to build on your knowledge immediately! Your app at the end of the day!

 30 septembre, 12 novembre, 20 janvier

 

Making your first Windows 8 app

This workshop is a free and fun training from developers, for developers. Expertise is offered in a fun, low key, interactive way and you’ll have the chance to test and experiment with your new knowledge!

 16 octobre, 9 décembre, 12 février

 

Make your app run into the Cloud 

Et pour étendre les capacités de vos apps et lier tout ça avec le cloud, sachez qu'une session Cloud & Windows Azure est également prévue et sera donnée par Nick Trogh, Developer and Platform Evangelist chez Microsoft BELUX.

In this workshop, we’ll teach you how to add a cloud backend to your app. Free, fun, no-fluff, you will learn how to add a cloud-based backend service to a Windows Store app using Windows Azure Mobile Services. And you’ll have the chance to test and experiment with your new knowledge!

 11 décembre

 

Encore plus de sessions

Je donnerai également des formations au MIC Brussels (voir leur agenda) sur les mêmes sujets, mais probablement en anglais cette fois (cela dépendra de l'audience :)).

Windows Azure Mobile Services : Intro

3. December 2012 15:12 by Renaud in Windows Azure  //  Tags: , ,   //   Comments (0)
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 provides. 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 tables : 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.

TextBox

About the author

I'm a developer, blog writer, and author, mainly focused on Microsoft technologies (but not only Smile). I'm Microsoft MVP Client Development since July 2013.

Microsoft Certified Professional

I'm currently working as an IT Evangelist with an awesome team at the Microsoft Innovation Center Belgique, where I spend time and energy helping people to develop their projects. I also give training to enthusiastic developers and organize afterworks with the help of the Belgian community.

MIC Belgique

Take a look at my first book (french only): Développez en HTML 5 pour Windows 8

Développez en HTML5 pour Windows 8

Membre de l'association Fier d'être développeur

TextBox

Month List