Julien Corioland

[Build 2012] - Windows Phone 8 Native C/C++ Game Development

Ce poste est co-écrit avec Simon Ferquel.

Le jeu représente un marché non négligeable pour les plateformes mobiles. Une des grandes nouveautés de la plateforme Windows Phone 8 est la possibilité de développer ces jeux en code natif C/C++, en plus de la compatibilité des jeux XNA développés pour Windows 7.x.

La session est présentée par Sam George, Principal Group Program Manager Windows Phone.

Avant les démonstrations du moteur Havok par Ross O’Dwyer (Head of developer support, Havok), Sam nous donne les principaux buts qui ont été fixés pour le développement de jeux sur Windows Phone 8 :

Premier point, la réduction des coûts de développement : il faut pouvoir réutiliser du code C++ existant pour d’autres plateformes, mais aussi utiliser des librairies Open Source C++, ou autres librairies comme Cocos2D / SharpDX. Second point, Windows Phone 8 doit supporter des moteurs / frameworks existants comme Havok, Unity, FMOD, ScaleForm, Wwise, Marmalade… Enfin dernier point, dans la stratégie d’unification des devs avec Windows 8, il doit être simple de faire des jeux multi-plateformes utilisant les mêmes APIs Direct3D / XAudio / MediaFoundation. Rappels également des nouveautés concernant l’in-app purchase sous Windows Phone 8, avec notamment la possibilité d’avoir deux types d’items (comme sous Windows 8) : consommables et durables.

Ensuite, nous avons assisté à un retour d’expérience d’Havok : que du bonheur. Au niveau des performances ça envoie du paté. Le compilateur est notamment capable d’exploiter des instructions SIMD et le runtime C++ permet de faire tout ce que les gros développeurs de jeux ont l’habitude de faire ! Les démos étaient impressionantes, aussi bien en terme de rendu graphique que de fluidité des animations.

App Model

Pour le développement, on a deux variantes : soit C#/XAML qui exploite des composants C++, soit uniquement C++ !

C# + XAML et C++

Un peu comme avec Windows 8, on a deux possibilités d’intérop entre XAML et DirectX. La première c’est le nouveau contrôle DrawingSurface qui permet d’effectuer un rendu Direct3D et de le copier dans une surface XAML. L’avantage c’est que le rendu Direct3D rentre dans l’arbre de composition XAML et donc que l’on peut lui appliquer des transformations, de l’opacité (etc…) comme n’importe quel autre contrôle XAML. On a aussi accès à un modèle d’événements pour les inputs (chose qu’on a pas sous Windows 8).

La deuxième possibilité d’intérop est d’utiliser un composant DrawingSurfaceBackgroundGrid qui permet d’utiliser le rendu DirectX directement comme background de la page et d’éviter la recopie du contenu DirectX dans l’arbre de composition XAML (plus performant).

Petit truc sympa, on peut également créer des composants WinRT C++ appelables en C#.

Uniquement C++

Comme sous Windows 8, on implémente l’interface IFrameworkView qui nous permet d’obtenir une CoreWindow sur laquelle sont disponibles les différents événements d’input, du cycle de vie de l’app (suspended, resumed, launched…) mais aussi qui va nous permettre de créer la swap chain Direct 3D. C’est le mode le plus performant mais l’inconvénient est qu’on a accès à aucun composant .NET (donc pas de Live Tiles, pas de background agent etc…). Au passage, on a accès à une machine à état qui permet de détecter les gestures classiques (swipe, pinch, zoom…).

Les APIs supportées

Pas de Direct2D/DirectWrite/WIC (pour le moment, mais clairement c’est dans les objectifs pour la prochaine version). Par contre côté Direct3D, support des shaders models 4.0_9.3 (d’ailleurs, la aussi la démo a envoyé du gros paté atomique). Pour l’audio, XAudio 2 est supporté et pour tout ce qui est musique et vidéo, on retrouve Media Foundation.

Côté réseau, on retrouve comme sous Windows 8 des APIs de peer en NFC/Wifi Direct (comme ce qu’on a utilisé pour Fingarock8 ) et Bluetooth ainsi que les classiques TCP (ssl aussi), UDP, HTTP. Les APIs ont l’air d’être les mêmes que sous Windows 8.

Au niveau du système de fichiers on retrouve la même chose que sous Windows 8 (CreateFile2 et tout ce qui va avec!) ainsi que le FS WinRT.

Enfin support de quelques Launcher & Chooser qui ont portés en WinRT pour l’occasion, car jugés nécessaires pour les jeux (market place, email, etc…).

Conclusion

Nous avons pu voir dans cette session que Microsoft propose désormais un SDK très riche et complet pour le développement de jeux vidéos sur Windows Phone 8 ! Franchement, ça poutre grave !

Prochaine session, le partage de code entre Windows Phone 8 et Windows 8.

Stay tuned

Simon & Julien

[Build 2012] - Windows Phone 8 Application Model

Première session de la journée après le keynote qui fut assez riche en démos autour de Windows 8 / Windows Phone 8 et en surprises…

Pour cette première session Windows Phone 8 de la semaine, on s’intéresse aux nouveautés concernant le développement d’applications sur la plateforme. Elle est présentée par Andrew Clinick, Group Program Manager Windows Phone.

##

Modèle d’exécution

Il faut garder en tête que tout ce qui fonctionnait sous Windows Phone 7.x continue à tourner sous Phone 8 : pas besoin de recompiler les applications.

Premier point abordé pendant la session : les performances des applications. Celles-ci doivent démarrer vite et être fast & fluide sinon, les utilisateurs risquent de ne pas vouloir les utiliser. Pour cela, Windows Phone 8 introduit une nouveauté : Compile in the cloud. Lorsque vous soumettez votre XAP dans le centre de développement, celui-ci est automatiquement recompilé en utilisant NGEN (Native Image Generator) et le XAP est mis à jour (au passage, c’est fait pour toutes les apps 7.x du store). L’utilisataion de NGEN est possible puisque désormais les applications s’exécutent dans la CoreCLR (comme sous Windows 8).

Le support des dual core sous Phone 8 est aussi pour beaucoup

###

Fast App Resume

Cette fonctionnalité est une évolution du fast app swtiching de Phone 7.5. Le constat a été fait que trop peu d’utilisateurs utilisent le task switcher (pression longue sur le bouton back). Du coup maintenant l’application est résumée depuis n’importe où : Live Tile, app list, toast, deep link…

Multitasking

Il est désormais possible d’avoir une application qui utilise le service de localisation en continue. Au lieu d’être endormie, l’application peut continuer à s’exécuter en background pendant que l’utilisateur utilise une autre application.

Maps

Le contrôle Bing Maps est toujours supporté mais déprécié. Il faut désormais utiliser les nouveaux contrôles Nokia Maps !!

Intégration avec le téléphone

VOIP

Microsoft propose aux apps de s’intégrer avec la partie téléphone, pour les applications de type VOIP : récupérer des notification pour les appels entrants, activation d’appels vidéos, nouveaux background agent pour les appels voix, amélioration du support des pushs notifications.

Une application peut donc être en attente d’appels (c’est le cas pour Skype par exemple) et être réveillée dès que l’appel se produit (ouverture d’une popup similaire à celle d’un appel entrant GSM).

Une application peut également venir alimenter le hub contact en données (sans passer par les tâches contacts, comme sous 7.x). L’accès aux contacts créés par l’application se fait en lecture/écriture, mais en lecture seule pour les autres contacts (comme sous Mango)

Deep Linking & Partage

Il est possible d’associer une application à un schéma d’url donnée (exemple zune://, fb://) et faire en sorte que l’application se lance lorsque l’utilisateur clique sur une URL de cette forme. Il est désormais possible d’associer une extension de fichier à une application (comme le faisait déjà Adobe Reader ou les apps de la suite office). Du coup, votre application peut être associée à son propre format de fichier.

Stockage de données

SQL Server et Linq 2 SQL sont toujours supportés sous Windows Phone 8, mais SQLite est maintenant disponible pour la plateforme !!

Windows Phone 8 supporte les cartes SD et des APIs sont disponibles pour lire et écrire sur celles-ci.

Live Apps

Les Live Apps sont les applications qui utilisent des vignettes dynamique (live tiles). Microsoft oriente vraiment son discours autour de la nouvelle home page de Windows Phone, qui supporte désormais 3 tailles de vignettes dynamiques : petite, moyenne et grande. Microsoft encourage tous les développeurs à mettre en place ces vignettes dans leurs apps et propose des modèles de vignettes dans le SDK :

• Flip : comme sous phone 7.x, se retourne aléatoirement
• Iconic : possibilité d’avoir une icône, un compteur mais mieux que sous Phone 7.x avec un style proche des apps système type boîte mail etc…
• Cycle : plusieurs contenus qui défilent de manière cyclique.

Egalement au menu, l’intégration dans l’écran de vérouillage avec la possibilité de changer l’image de fond et d’alimenter l’écran avec trois ligne d’information (comme Outlook pouvait le faire). Le fond d’écran de vérouillage peut être mis à jour depuis l’application en cours d’exécution ou depuis un background agent. Les informations affichées sur l’écran de vérouillage par l’application sont les mêmes que celles de la vignette dynamique (une seule et même API). L’utilisateur choisi quelle (unique) application peut changer le fond d’écran. L’application peut demander à l’utilisateur d’afficher cette fonctionnalité (via API).

Windows Phone 8 en entreprise

Windows Phone 7 a souvent été taclé sur ce point : sa mauvaise intégration en entreprise. Microsoft le sait, mais avec Windows Phone 8, ce temps est révolu !

Au niveau gestion de flotte mobile, il sera possible d’utiliser Windows Intune (application de police de sécurité, mise à jour d’apps automatique, gestion de parc…)

Au niveau du déploiement d’applications, il sera possible d’utiliser le web, l’email ou encore une application elle-même (un hub d’entreprise, par exemple). Vous devrez fournir votre propre certificat pour signer vos applications. Celles-ci ne seront alors disponibles que pour les collaborateurs de votre entreprise qui auront à enregistrer le certificat depuis leur téléphone (via web, mail…).

Conclusion

Cette session a proposé une vue d’ensemble de toutes les nouvelles fonctionnalités qui tournent autour de l’exécution des applications sous Windows Phone, mais également de l’intégration de celles-ci avec le téléphone / OS. Nous aurons l’occasion d’aller dans des considérations plus techniques au cours des autres sessions !

Stay tuned

Julien

Build 2012 c’est parti !

La conférence //Build/ 2012 démarre aujourd’hui même sur le Campus de Microsoft à Redmond et j’ai la chance d’y assister cette année (merci Microsoft France ) !

Vous l’aurez certainement deviné, le gros focus cette année va être le développement Windows 8 et Windows Phone 8 (après les annonces d’hier : http://www.microsoft.com/en-us/news/presskits/windowsphone/).

Je me suis concocté un parcours complet sur Windows Phone 8, avec au menu des sessions très génériques sur le développement d’apps en général et des sessions plus spécifiques sur les nouvelles features de la plateformes. J’aurai l’occasion d’y revenir sur mon blog au fur et à mesure ! D’ailleurs, le programme des sessions est disponible sur Channel 9 !

Stay tuned !

Julien

[ASPNET Web API] Forcer le content type pour une action donnée

Avec ASP.NET Web API, la content négociation se fait à l’aide du header Accept de la requête HTTP. Lorsque le type demandé n’est pas pris en charge, la requête est alors traitée avec le formateur par défaut, en l’occurrence le formateur JSON.

Cependant, dans certains cas il est nécessaire de forcer  le format de retour de la requête. Par exemple pour retourner un flux RSS.

Considérons le code suivant :

public class RssController : ApiController
{
private readonly IBlogService _blogService;
public RssController()
{
var dbContext = new MetroBlogDbContext();
_blogService = new BlogService(dbContext);
}

public IEnumerable<Post> Get()
{
return _blogService.GetLatestPosts(true, 0, 20).ToList();
}
}

Il s’agit d’un simple contrôleur Web API qui retourne une liste d’objet Post (la définition n’a pas d’importance ici). Pour être capable de retourner un format de flux RSS, j’ai écrit un custom formatter pour RSS/Atom (cf. http://www.strathweb.com/2012/04/rss-atom-mediatypeformatter-for-asp-net-webapi/).

Une fois le formateur développé, il suffit de l’enregistrer au démarrage de l’application :

GlobalConfiguration.Configuration.Formatters.Add(new SyndicationFeedFormatter());

Cette solution permet de faire en sorte que lorsque le header Accept de la requête HTTP est à <em>application/rss+xml</em> ou <em>application/atom+xml</em>, le formateur SyndicationFeedFormatter soit utilisé et donc que le format en sortie soit un flux RSS. Ce n’est cependant pas suffisant pour que l’action Get renvoie toujours un flux RSS!

Pour le forcer, il est nécessaire de modifier le code de l’action Get et de créer nous même l’HttpResponseMessage qui sera renvoyé :

public HttpResponseMessage Get()
{
try
{
var posts = _blogService.GetLatestPosts(true, 0, 20).ToList();
var responseMessage = new HttpResponseMessage(HttpStatusCode.OK);
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new SyndicationFeedFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/rss+xml");
return responseMessage;
}
catch(Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}

A partir de là, quelque soit le header Accept qui est envoyé, le format retourné sera <em>application/rss+xml</em>.

Il est également possible de filtrer certains type en se basant sur le header Accept de la requête afin de forcer le format que dans certains cas :

public HttpResponseMessage Get()
{
try
{
var posts = _blogService.GetLatestPosts(true, 0, 20).ToList();
var responseMessage = new HttpResponseMessage(HttpStatusCode.OK);

if (Request.Headers.Accept.Any(a => a.MediaType == "application/json"))
{
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new JsonMediaTypeFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/json");
}
else
{
responseMessage.Content = new ObjectContent(typeof(IEnumerable<Post>), posts, new SyndicationFeedFormatter());
responseMessage.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/rss+xml");
}

return responseMessage;
}
catch(Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}

Dans le cas présent, si le header Accept de la requête contient le media type <em>application/json</em>, on renvoie un retour en JSON, sinon on renvoie le flux RSS formaté.

A bientôt !

[ASP.NET MVC 4] Mise en place de l’authentification OAuth Facebook

L’une des nouveautés d’ASP.NET MVC 4 est la possibilité de mettre en place très simplement de l’authentification au travers de fournisseurs d’identité tels que Facebook, Microsoft, Google (etc.) dans une application. Ce type d’authentification est d’ailleurs proposée de base dans les nouveaux modèles de projets d’application ASP.NET MVC 4 de Visual Studio. Cependant, afin de bien comprendre comment mettre en place les différentes briques qui permettront cette authentification, je vous propose de partir de zéro et de créer un projet à l’aide du modèle Basic :

##

Déroulement de l’authentification

Le processus d’authentification à l’aide d’un fournisseur d’identité externe se déroule en plusieurs étapes décrites sur le schéma ci-dessous :

Dans un premier temps, l’utilisateur choisi le fournisseur d’identité (parmi ceux proposés par l’application) avec lequel il souhaite s’authentifier. Il est alors redirigé vers la page d’authentification du fournisseur choisi. L’utilisateur s’authentifie et est renvoyé sur l’application à l’aide d’une URL de callback qui a été transmise au fournisseur d’identité lors de la venue de l’utilisateur. Dans la dernière étape, l’application valide l’utilisateur et récupère son identité (établie par le fournisseur).

Il est alors possible de récupérer 4 informations :

• L’état de l’authentification (échec ou succès)
• Le nom d’utilisateur (si succès, transmis par le fournisseur)
• L’id de l’utilisateur (si succès, transmis par le fournisseur)
• Le nom du fournisseur

Ajout des références nécessaires à la mise en place de l’authentification OAuth

La mise en place de l’authentification OAuth requière l’ajout de plusieurs références au projet. Il est possible d’en récupérer la plupart à l’aide du package nuget  DotNetOpenOAuth extensions for ASP.NET (WebPages). Une fois le package installé, il ne reste qu’à ajouter une référence vers la librairie Microsoft.Web.WebPages.OAuth.dll depuis la fenêtre d’ajout de référence de Visual Studio.

Voilà les références que vous devriez avoir à ce stade :

Configuration des fournisseurs d’identités

Afin que l’authentification puisse fonctionner, il est nécessaire de configurer les différents fournisseurs d’identités à utiliser dans l’application. Dans le cas présent, nous allons voir comment configurer Facebook.

Pour commencer, créez une nouvelle classe dans le dossier App_Start du projet. Nommez la OAuthConfig. Cette classe possède une méthode statique RegisterOAuthProviders qui sera en charge d’initialiser les différents fournisseurs d’identités au démarrage de l’application :

public class OAuthConfig
{
public static void RegisterOAuthProviders()
{
//enregistrement des fournisseurs d'identité
}
}

Appelez cette méthode dans le Global.asax :

public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();

WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);

//enregistrement des fournisseurs d'identités
OAuthConfig.RegisterOAuthProviders();
}
}

L’enregistrement des différents fournisseurs va se faire à l’aide de la classe OAuthWebSecurity définie dans l’espace de noms Microsoft.Web.WebPages.OAuth. Celle-ci possède un certain nombre de méthodes statiques pour enregistrer les différents fournisseurs supportés nativement (RegisterFacebookClient, RegisterMicrosoftClient…).

Configuration de l’authentification Facebook

Avant de procéder à l’enregistrement du fournisseur, il est nécessaire de se connecter sur https://developers.facebook.com/apps et de créer une nouvelle application. Pour se faire, cliquez sur le bouton <em>+ Create New App</em> en haut à droite. Donnez un nom à l’application et validez en cliquant sur <em>Continue</em>.

Entrez le code de sécurité pour terminer la création. Pour que l’authentification fonctionne, il est nécessaire de cocher Website with Facebook Login en bas de page et de renseigner l’URL du site web qui va utiliser l’application Facebook pour l’authentification. En l’occurrence ici votre URL de débogue dans Visual Studio :

Validez en cliquant sur Save Changes.

Il vous faut alors récupérer l’App ID et l’App Secret en haut de la page, afin d’enregistrer le fournisseur dans Visual Studio.

Pour enregistrer le fournisseur, il suffit d’appeler la méthode RegisterFacebookClient de la classe OAuthWebSecurity :

OAuthWebSecurity.RegisterFacebookClient(
appId:"[appId]",
appSecret:"[appSecret]",
displayName: "Facebook"
);

Création de la page de Login

Ajoutez un contrôleur <em>Account</em> et créez une action Login. Le modèle passé à la vue correspond à la liste des fournisseurs configurés (ici Facebook), représentée par la propriété RegisteredProviders sur la classe OAuthWebSecurity :

public class AccountController : Controller
{
public ActionResult Login()
{
return View(OAuthWebSecurity.RegisteredClientData);
}
}

La page affiche alors un bouton pour chaque fournisseur :

@model ICollection<AuthenticationClientData>

@{
ViewBag.Title = "Authentification";
}

## Choisissez un fournisseur d'identité pour vous identifier

@using (Html.BeginForm("Login", "Account", FormMethod.Post))
{
foreach (var provider in Model)
{
<input type="submit" name="provider" value="@provider.DisplayName" />

}
}

Le code appelé lors du POST du formulaire effectue la redirection vers le fournisseur sélectionné, en lui passant la callback URL (appelée après l’authentification par le fournisseur d’identité) :

[HttpPost]
public ActionResult Login(string provider)
{
string callbackUrl = Url.Action("ProviderCallback", "Account");
OAuthWebSecurity.RequestAuthentication(provider);
return new EmptyResult();
}

Lancez l’application, rendez-vous sur la page /Account/Login et vérifiez qu’un bouton Facebook apparait bien :

En cliquant sur le bouton, vous devriez être redirigé sur Facebook. Authentifiez-vous, acceptez d’utiliser l’application. Vous devriez alors être renvoyé sur votre site (sur l’action ProviderCallback). Pour le moment, vous devez obtenir une erreur 404.

Dans l’action de callback, il s’agit de vérifier que l’authentification a bien fonctionné. Pour cela, il faut utiliser la méthode VerifyAuthentication sur la classe OAuthWebSecurity. Si le résultat est valide, vous pouvez alors récupérer le nom et l’id de l’utilisateur et créer une session (à l’aide de la classe FormsAuthentication, par exemple) :

public ActionResult ProviderCallback()
{
var result = OAuthWebSecurity.VerifyAuthentication();
if (result.IsSuccessful)
{
string userName = result.UserName;
string userId = result.ProviderUserId;
FormsAuthentication.SetAuthCookie(userName, false);
return RedirectToAction("Index", "Home");
}
else
{
return RedirectToAction("Login", "Account");
}
}

Et voilà, le tour est joué, votre utilisateur est authentifié via Facebook.

Le mécanisme d’authentification est ultra générique ici, puisqu’il suffit de rajouter des fournisseurs (Microsoft, Google, Twitter, Yahoo…) dans la méthode RegisterOAuthProviders de la classe OAuthConfig créée au début de cet article !

Le code source de l’application d’exemple est disponible ici : https://juliencorioland.blob.core.windows.net/publicfiles/MVC4.ArticleOAuth.zip

A bientôt