Home - About me - Browse by categories

[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.

image

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 Winking smile

Julien

read more

[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…

image

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)

image

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 Winking smile

Julien

read more

[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 ! Smile

image

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 Winking smile

Julien

read more

[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 !

image

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 :

image

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 Winking smile

Julien

read more

[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.

image

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 ! Smile 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 Smile) 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 Winking smile

Simon & Julien

read more