Julien Corioland

[Build 2012] Maps, géolocalisation et exécution en arrière plan.

Première session Windows Phone 8 de cette 3ème journée de //build/ 2012 (pas de keynote aujourd’hui!), on s’intéresse aux nouveautés concernant les maps, la géolocalisation et l’exécution en arrière plan !

Location Services APIs

Les APIs de géolocalisation ont été complètement repensées sous Windows Phone 8. On conserve l’ancienne API .NET avec le GeoCoordinateWatcher pour la compatibilité ascendante, mais une nouvelle API WinRT est disponible et beaucoup plus complète !

Côté WinRT, on retrouve une nouvelle classe, Geolocator pour localiser un utilisateur. Il y a plus de contrôle sur la précision souhaitée (en mètres) et il est notamment possible de récupérer la position de l’utilisateur sans la tracker en continue (Single Location Request), ce qui permet d’économiser la batterie de l’utilisateur. Comme beaucoup d’API WinRT, celle-ci est totalement asynchrone (async/await). On retrouve aussi la possibilité de contrôler la mise en cache et les timeout.

En terme de bonnes pratiques, il faut utiliser au maximum le Single Location Request, quand c’est possible, car celà permet vraiment de réduire la consommation de la batterie !

En bonus, un bout de code sur l’utilisation de l’API Geolocator :

###

Map Control et service de géolocalisation

Autre grosse nouveauté de la plateforme Windows Phone 8 côté cartes, l’utilisation des maps Nokia et des services de géolocalisation Nokia. On utilise un nouveau contrôle Maps qui permet notamment à l’utilisateur d’avoir ses cartes en mode offline pour ne plus consommer sa connexion de données et augmenter la fluidité ! Au passage, un nouveau launcher permet de proposer à l’utilisateur de télécharger une carte : MapsDownloader.

Le contrôle maps est capable d’afficher des cartes en 2D/3D, en vectoriel, ainsi que des itinéraires.

Avec cette carte, de nouveaux services arrivent pour effectuer directement des opérations de geocoding, géocoding inversé et de calcul d’itinéraire (il ne s’agit plus des services Bing, mais Nokia !)

Le BingMaps contrôle existe toujours pour la compatibilité des applications 7.x, mais il est déprécié !

L’utilisation du contrôle Maps et des services Nokia est gratuite, il faut juste associer son compte de développeur pour pouvoir récupérer un token.

Le maps toolkit extensions (http://phone.codeplex.com) permet d’avoir des fonctionnalités supplémentaires pour le contrôle Maps (pushpin etc..)

Géolocalisation en arrière plan

Sous Windows Phone 8, une application peut s’exécuter en arrière plan ET récupérer la position de l’utilisateur en continue (une seule application peut le faire). C’est uniquement possible pour les applications XAML (XAML, XAML+Direct3D, mais pas pur Direct3D).

En mode background, l’application n’a accès qu’à des ressources limitées et qu’à un sous ensemble des APIs :

Comme pour les background agent sous Windows Phone 7.5, l’utilisateur peux désactiver l’application dans les paramètres du téléphone.

L’application peut être notifiée (event) et notifier l’utilisateur lorsque la géolocalisation est désactivée au niveau du téléphone.

Au niveau du cycle de vie de l’application, on a un nouvel événement : RunningBackground (en plus de Launching, Deactivated, Activated et Close) qui permet de savoir que l’application s’exécute en arrière plan ! Ce nouvel event remplace le deactivated pour les applications de géolocalisation en arrière plan :

Fast Resume

Le fast resume est la capacité des applications Windows Phone 8 à reprendre là où elles étaient, même si l’utilisateur les relance depuis son écran d’accueil ou la liste des applications (contrairement à Windows Phone 7 ou l’application était totalement relancée!). Pour permettre à une application de faire du fast resume, il faut éditer le fichier manifest, au niveau de la définition de la DefaultTask (par défaut, le comportement est le même que sous Phone 7, Replace) :

Lorsque l’application est résumée, le mode de navigation dans la méthode OnNavigatedTo est à **Reset**, ce qui permet par exemple de vider la stack de navigation tout en conservant une ancienne instance de l’application (optimisation de la mémoire du téléphone et de la rapidité du chargement de l’application). Toutes les explications ici : http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj735579(v=vs.105).aspx

Conclusion

Beaucoup de nouveautés autour de la géolocalisation, avec le nouveau contrôle Maps de Noka, les APIs de Nokia pour le géocoding et surtout la possibilité d’avoir une application qui track la position de l’utilisateur en continue et en background !

Stay tuned

Julien

[Build 2012] Quoi de neuf dans l’update ASPNET Fall 2012

Le keynote de la deuxième journée était principalement consacrée à Windows Azure (vous pourrez le voir ou revoir ici, lorsqu’il sera dispo) mais quelques annonces assez sympa ont été faites autour d’asp.net / asp.net mvc et asp.net web api.

Toutes les nouveautés annoncées sont regroupées sous la forme d’une mise à jour ASP.NET Fall 2012 Update qu’il est possible d’installer depuis cette page.

Tooling

On retrouve quelques nouveautés en terme de publication (même expérience pour les web applications que pour les websites, selective publish qui permet de choisir les fichiers à publier…) et de nouveaux templates de projets : Facebook, Single Page Application et FixedDisplayModes package.

ASP.NET Web API OData

Il s’agit d’une extension à Web API qui permet de construire des services OData compliant (i.e. avec la possibilité d’appliquer des filtres directement dans l’URL). Cette fonctionnalité était déjà disponible via nuget en preview. Concrètement, c’est super simple à mettre en place, puisqu’il suffit d’exposer des IQueryable dans les ApiController et de précéder les actions qui doivent supporter OData par un attribut Queryable :

[Queryable]
public IQueryable<Post> Get()
{
return _context.Posts;
}

ASP.NET Web API Tracing

Il s’agit tout simplement de la mise en place par défaut de traces .NET pour les services ASP.NET Web API. On peut exploiter ces données de trace dans l’IntelliTrace.

###

ASP.NET Web API Help Page

Fonctionnalité assez sympatique, puisqu’elle permet très simplement de générer des pages d’aide à l’utilisation des services ASP.NET Web API.

Windows Azure Authentication

Il s’agit de la continuité d’une des annonces faites sur Azure lors du keynote : la possibilité de supporter dans une application ASP.NET de l’authentification via Windows Azure Active Directory ou Office 365.

SignalR

SignalR est un framework permettant de développer des interfaces temps réel en javascript, notamment. Il permet d’optimiser les communications avec le serveur pour connaître (par exemple) l’avancement de certaines tâche en faisant du long polling plutôt que de lancer n requêtes http par secondes. Il est désormais supporté de base depuis cette mise à jour.

###

Voilà pour ce que l’on pouvait dire concernant les nouveautés de cette update ASP.NET. Plein de nouvelles choses sympa en perspective ! Au passage, les démos ont été faites avec une preview d’Entity Framework 6 qui supporte désormais le développement asynchrone basé sur les Task et les mots-clés async/await !! Cette preview est disponible sur nuget : http://nuget.org/packages/EntityFramework/6.0.0-alpha1

Stay tuned

Julien

[Build 2012] Développement d’applications connectées sous Windows Phone 8

Windows Phone 8 apporte un certain nombre d’APIs permettant de développer des applications connectées : Socket, NFC, Bluetooth…

Dans cette session, Tim Laverty, PM Windows Phone nous présente toutes ces nouveautés !

Les objectifs de la session

• Avoir une bonne vue d’ensemble de toute la stack networking de Windows Phone 8
• Voir quel sont les éléments qui diffèrent entre Phone 7, Phone 8 et Win 8 (et donc ceux qui se rapprochent, pour pouvoir réutiliser un max de code)
• Découvrir les APIs et leur prise en main

Les APIs de networking

• APIs .NET pour la manipulation des sockets  dans System.Net.Sockets
• APIs WinRT pour la manipulation des sockets dans Windows.Networking.Sockets
• APIs WinRT pour le networking de proximité (NFC / Bluetooth) dans Windows.Networking.Proximity
• APIs native pour la manipuation de socket (Winsock api family)

Communication via Bluetooth

• Couvre des scénarii de communication App to App et App to Device
• Permet d’ouvrir un socket WinRT (StreamSocket)
• Fonctionne dans un rayon de 0 à 100m

Communication NFC

• Couvre également des scénarii de communication App to App et App to Device, mais pour des volumes de données réduits (bande passant ~424 kbit/s)
• Fonctionne dans un rayon de 2 à 4 cm
• Il est possible d’associer le contenu NFC à une application du téléphone : je scan un tag NFC, ça ouvre mon application (on utilise une extension de protocole dans le manifeste de l’application)
• Il est également possible d’envoyer de la données dans un tag NFC (pour l’associer avec votre app, en lui précisant le protocole à utiliser)

Sockets

Concernant les sockets, on peut donc utiliser plusieurs API : .NET, WinRT ou native. Dans tous les cas, il est possible de faire aussi bien du TCP que de l’UDP.

Concrètement, à partir du moment ou il faut mettre en place des stratégies de code sharing avec les applications Windows Store, il faut partir sur des sockets WinRT, les APIs .NET et native n’étant pas compatibles avec les Windows Store Apps. Les API .NET sont là pour du code portable sous Windows 8 (pas WinRT) et les API natives si vous possédez du code existant utilisant Winsock.

Stay tuned

Julien

[Build 2012] - Windows Phone 8 In App Purchase

Dernière session de la journée, on s’intéresse à l’in-app purchase sous Windows Phone 8 !

L’in-app purchase est possible depuis la première version de Windows Phone, mais avec Windows Phone 8, Microsoft apporte un support complet sur la mise en place de celui ci !

L’in-app purchase est une des sources de revenus les plus importantes sur les plateformes mobiles, c’est pourquoi Microsoft fait le choix de fournir des outils pour le mettre en place simplement et proposer aux utilisateurs un service qui soit unifié et pratique, avec notamment la possibilité de payer directement via la facture opérateur! (au passage, l’in app purchase est disponible dans les 191 pays où il est possible de publier des apps, donc le marché est vraiment important !)

Concrètement, il est possible de vendre un peu ce que l’on veut dans son application, mais on distingue deux types d’éléments:

• Consommables : il s’agit d’éléments qui seront utilisables une seule fois par l’utilisateur, par exemple un mode d’invincibilité dans un jeu, la possibilité de sauter un niveau…
• Durables : il s’agit d’éléments que l’utilisateur possèdent et pourra utiliser tant qu’il possède l’application (extension de jeu, ebook, service digital…)

En terme d’expérience utilisateur, le scénario est le suivant :

- L’utilisateur visualise la liste des éléments qu’il peut acheter au sein de l’application - L’utilisateur choisi d’acheter un élément, il est redirigé sur le Wallet Windows Phone, rentre son code pin, choisi son mode de paiement (opérateur, carte bleu, paypal…) et valide - L’utilisateur retourne dans l’application, l’item qu’il a acheté est disponible.

Du point de vue du développeur de l’application, voilà comment les choses se passent :

Design

Tout d’abord, il faut réfléchir aux items qui vont être mis en vente. Un produit est représenté par :

• Un ID unique sur le store (son code barre)
• Un type : consommable ou durable
• Un mot clé pour le catégoriser
• Des métadonnées : titre, description, icône…

Les éléments sont ensuite saisis via le Windows Phone developer center (au niveau du dashboard de l’application)

Développement

Côté développement, une API permet de travailler avec les produits disponibles en in app purchase. Tous les outils nécessaires sont dans l’espace de noms Windows.ApplicationModel.Store. Concrètement, il est possible de :

• Récupérer la liste des produits (par id, par mot clé…) afin d’afficher la liste des éléments disponibles dans l’application (l’affichage reste de la responsabilité du développeur, ce qui permet de vraiment intégrer l’expérience d’achat à l’application)
• De lancer l’action d’achat d’un produit pour rediriger l’utilisateur vers le wallet / le store
• De récupérer la liste des produits que possède l’utilisateur

Tests

Pour tester l’in app purchase, Microsoft propose deux solutions : via l’émulateur, à l’aide d’un mock ou alors via le programme de publication d’application en beta (un store de produit beta est disponible)

Publication

Une fois le design, le développement et les tests terminés, l’application et le catalogue de produits qui l’accompagnent peuvent être publiés sur le store.

Les speakers ont une démo de mise en place de l’in app purchase dans une application existante, c’est vraiment ultra simple. Les APIs sont là et elles sont facile à prendre en main. Comme on dit, y’a plus qu’à !

Stay tuned

Julien

[Build 2012] Partage de code entre Windows Phone 8 et Windows 8

Un post rapide pour vous parler de cette session sur le partage de code entre Windows Phone 8 et Windows 8. Je prendrai le temps de revenir dessus dans un article plus complet une fois que j’aurai un peu plus de recule et fait quelques exemples !

Globalement, ce qu’il faut retenir, c’est que les deux plateformes sont en train de converger, avec l’apparition de WinPRT (Windows Phone Runtime) sous Windows Phone 8 qui est un sous ensemble des APIs WinRT (Windows Runtime) de Windows 8. Concrètement, on retrouve 3 sets d’API distincts sous Windows Phone 8 :

• Framework .NET
• Windows Phone Runtime
• Native API : Direct3D, XAudio2, Media Foundation

Voilà un schéma résumant ces APIs :

En terme de stratégie, pour favoriser le partage de code entre les deux plateformes, il faut bien évidemment séparer au maximum la logique de l’application de l’UI. Pour ça, MVVM reste le pattern à utiliser en XAML. Pour partager du code .NET entre Windows Phone et Windows, on utilisera les Portable Class Libraries. Il est également possible d’utiliser des fichiers liés (add as link) ou un composants WinRT compilé (pas possible de référencer directement le projet dans Windows Phone 8, il faut aller chercher le .winmd!)

Concernant le code qui est platform specific, pas de recette miracle ni grosse nouveauté, on utilise la portable class library pour créer nos interfaces et derrière on fait de l’injection de dépendances dans chaque application.

Voilà ce qu’il faut retenir de cette session à ce stade. Plus d’info sur MSDN, sur cette page.

Stay tuned

Julien