Julien Corioland

Azure Service Bus, BrokeredMessage et opérations longues

Le service de messaging d’Azure Service Bus n’est à l’origine pas prévu pour exécuter des long-running process. Cependant le SDK 1.8 sorti en Octobre dernier apporte une petite nouveauté sur ce point. En effet, la classe BrokeredMessage offre désormais une méthode RenewLock qui permet de demander le renouvèlement d’un verrou sur le brokered message afin qu’il ne soit pas remis à disposition dans la file d’attente.

Du coup, en se basant sur la propriété LockedUntilUtc, on peut réussir à exécuter une opération longue sans avoir de problème de perte de verrou sur le message :

//création d'un CTS pour lancer un task en charge de renouveller le verrou du message
var brokeredMessageRenewCancellationTokenSource = new CancellationTokenSource();

try
{
//reception du message
var brokeredMessage = _client.Receive();

var brokeredMessageRenew = Task.Factory.StartNew(() =>
{
while (!brokeredMessageRenewCancellationTokenSource.Token.IsCancellationRequested)
{
//on se base sur la propriété LockedUntilUtc pour savoir si le verrou expire bientôt
if (DateTime.UtcNow > brokeredMessage.LockedUntilUtc.AddSeconds(-10))
{
//si oui, on renouvelle le message
brokeredMessage.RenewLock();
}

Thread.Sleep(500);
}
}, brokeredMessageRenewCancellationTokenSource.Token);

//exécution d'une opération longue
RunLongRunningOperation();

//on marque le message comme terminé
brokeredMessage.Complete();
}
catch(MessageLockLostException)
{
//le verrou a expiré
}
catch(Exception)//autre exception
{
//autre erreur : on abandonne le message
brokeredMessage.Abandon();
}
finally
{
//on arrête la task de renouvellement du verrou
brokeredMessageRenewCancellationTokenSource.Cancel();
}

Et voilà !

Julien

Introduction à Windows Azure Media Services

Windows Azure Media Services

Il s’agit d’une nouvelle brique de Windows Azure qui permet de gérer l’hébergement, l’encodage, la mise à disposition de médias, sur Internet. Il est notamment possible de gérer des workflows de publication de vidéo. Par exemple, vous allez pouvoir choisir d’envoyer un fichier vidéo au format HD dans un espace de stockage Windows Azure (blob), et faire en sorte que ce fichier soit automatiquement encodé dans différents formats (basse résolution etc…) et publié sur Internet. Pour se faire, Microsoft propose un ensemble d’API dans le SDK Windows Azure Media Services. ### Création d’un service de média

Connectez-vous sur le site de management Windows Azure et cliquez sur la section « Services de média » Cliquez ensuite sur le lien « Créer un service de média ». Vous devrez alors fournir trois informations : - Le nom du service que vous souhaitez créer (chiffres et lettre, tout en minuscules) - La localisation géographique - Le stockage Windows Azure qui doit être utilisé pour stocker les fichiers

Patientez ensuite jusqu’à ce que le service soit créé. Une fois ceci fait, il est possible de récupérer la clé de management qui permettra d’utiliser le SDK pour envoyer des fichiers vidéos sur Azure et les traiter, au sein d’une application .NET. Pour cela, rendez-vous sur le dashboard du service de média que vous venez de créer et cliquez sur le lien « Gérer les clés » : Copiez alors la clé d’accès primaire que vous allez réutiliser par la suite. ### Utilisation de l’API .NET

Afin de pouvoir utiliser les APIs Windows Azure Media Service, il est nécessaire d’inclure ce package Nuget dans votre projet. Le premier objet à instancier est un CloudMediaContext. C’est lui qui représente le point d’entrée de l’API Windows Azure Media Services. Il est nécessaire de passer le nom du service ainsi que la clé d’accès primaire au constructeur :```csharp var context = new CloudMediaContext(“nom de votre service Azure Media Services”, “votre clé”);

Via ce context, vous allez pouvoir créer un nouvel asset. Un asset représente une vidéo, dans les différents formats sous lesquels elle sera publié. Pour créer un asset, il faut exécuter le code suivant :

```csharp
string videoFilePath = @"E:\VIDEOS\Test.mp4";
string fileName = Path.GetFileName(videoFilePath);
string assetName = string.Format("{0} - {1}", Path.GetFileNameWithoutExtension(videoFilePath), DateTime.Now);

//création de l'asset sur le CloudMediaContext
IAsset asset = context.Assets.Create(assetName, AssetCreationOptions.StorageEncrypted);

L’asset est a présent crée, il est alors possible d’envoyer le fichier vidéo qui est associé :

IAssetFile file = asset.AssetFiles.Create(fileName);
file.Upload(videoFilePath);

Vous pouvez vous arrêter à ce code si vous ne souhaitez pas ré encoder le fichier derrière pour le publier dans différents formats. D’ailleurs, si vous vous connectez à l’interface de gestion de Windows Azure Media Services, vous devriez voir apparaitre le contenu vidéo qui a été envoyé.

Dans le cas présent, nous allons pousser un peu plus loin puisque nous allons lancer un job d’encodage. Pour se faire, il est nécessaire de récupérer un media processor, c’est à dire un outils qui va permettre d’effectuer l’encodage vidéo. Windows Azure Media Services en propose plusieurs :

• Windows Azure Media Encoder
• Windows Azure Media Packager
• Windows Azure Media Encryptor
• Storage Decryption

Pour plus d’info sur les media processors, consultez cette page de la MSDN.

Ici, c’est le premier de la liste qui va être utilisé. Pour le récupérer, il suffit de faire une simple requête LINQ sur la collection MediaProcessors du contexte :

var mediaProcessor = context.MediaProcessors.Where(f => f.Name == "Windows Azure Media Encoder").AsEnumerable().FirstOrDefault();

Afin de lancer une tâche d’encodage, il est également nécessaire de préciser une configuration à utiliser. Il est possible de récupérer les différentes configuration sur cette page, en fonction du media processor utilisé ! Dans le cas présent, c’est le preset H.264 256k DSL CBR qui va être utilisé :

string encodingConfiguration = "H.264 256k DSL CBR";

Il est désormais possible de créer la tâche d’encodage :

//création du job
IJob job = context.Jobs.Create(string.Format("job d'encodage de {0}", asset.Name));

//ajout de la tâche d'encodage
ITask task = job.Tasks.AddNew(string.Format("tâche d'encodage de {0}", asset.Name), mediaProcessor, encodingConfiguration, TaskOptions.None);

//ajout de l'asset en input
task.InputAssets.Add(asset);

//création de l'asset d'output
var outputAsset = task.OutputAssets.AddNew(string.Format("{0} (output)", asset.Name), true, AssetCreationOptions.None);

//soumission du job
job.Submit();

Pour attendre la fin du job, il faut récupérer une task sur l’objet job à l’aide de la méthode GetExecutionProgressionTask. Il est alors possible de tester son état pour savoir s’il a réussi ou échoué :

//attente de la fin du job
Task jobProgressionTask = job.GetExecutionProgressTask(CancellationToken.None);
jobProgressionTask.Wait();

//test de l'état du job
if (job.State == JobState.Finished)
{
Console.WriteLine("Le job est terminé");
}
else if (job.State == JobState.Error)
{
Console.WriteLine("Une erreur est survenue pendant l'exécution du job.");
}

Il est également possible de s’abonner à l’événement StateChanged sur le job afin de récupérer les différentes transitions au fur à mesur de son exécution :

static void job_StateChanged(object sender, JobStateChangedEventArgs e)
{
Console.WriteLine("L'état du job vient de passer de {0} à {1}", e.PreviousState, e.CurrentState);
}

Et voilà, le tour est joué, vous avez pu envoyer un fichier vidéo directement dans le stockage Azure et lancer différents workflow pour réencoder la vidéo à la volée avant de la publier :

Et si vous allez sur l’interface Windows Azure vous pouvez constater que l’output est bien présent et publiable :

Un fois publié, il est possible de lire lire et de récupérer son adresse dans le blob storage Azure :

Enjoy

Julien

[Windows Phone 8] Ecrire un tag NFC et lancement d’une application via NFC

Dans mon article précédent, je vous montrais comment utiliser l’API de proximity device pour échanger une information entre deux téléphones lors d’un tap NFC. Dans ce nouvel article, je vais vous montrer comment écrire du contenu dans un tag NFC afin de le réexploiter pour qu’il puisse fournir une URL ou encore qu’il permette de lancer une application !

Ecriture d’un tag

L’écriture d’un tag se fait très simplement. Tout d’abord, Il faut récupérer une instance de ProximityDevice grace à la méthode statique GetDefault de cette même classe :

public partial class MainPage : PhoneApplicationPage
{
private readonly ProximityDevice _proximityDevice;
// Constructor
public MainPage()
{
InitializeComponent();
_proximityDevice = ProximityDevice.GetDefault();
}
}

Une fois récupéré, le ProximityDevice permet d’écouter les messages NFC apportés par un tag sur lequel il est possible d’écrire. Pour celà, il suffit de souscrire aux messages de type <em>Writeable</em> :

private long subId = 0;
protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice == null)
{
Dispatcher.BeginInvoke(() =>
{
MessageBox.Show("Le NFC n'est pas supporté sur ce téléphone", "Pas de NFC", MessageBoxButton.OK);
});
}
else
{
subId = _proximityDevice.SubscribeForMessage("WriteableTag", OnWriteableTagArrived);
}

base.OnNavigatedTo(e);
}

Dans le handler OnWriteableTagArrived, on récupère le ProximityDevice qui lève l’événement, et on peut alors écrire une information à l’aide de la méthode PublishBinaryMessage :

private long pubId = 0;
private void OnWriteableTagArrived(ProximityDevice sender, ProximityMessage message)
{
var dataWriter = new DataWriter();
dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
dataWriter.WriteString("http://www.juliencorioland.net");
pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());
}

Comme vous pouvez le constater, j’utilise ici le protocole WindowsUri:WriteTag, qui me permet d’écrire une information de type URL dans le tag NFC (ici il s’agit d’une carte de dev offerte par Nokia à la //build/), en l’occurrence ici l’adresse de mon blog. Du coup, lorsque je passe mon téléphone devant le tag NFC, celui ci affiche me propose d’afficher mon blog :

Lorsque j’accepte, le navigateur s’ouvre sur mon blog !

Lancer son application à partir d’un tag NFC

Un des cas d’utilisation de NFC prévu par Microsoft sous Windows Phone 8 est la possibilité d’associer une application à un type de tag, permettant ainsi de lancer une application par contact NFC. Par exemple, vous pouvez imaginer une borne intéractive à l’entrée d’un magasin, sur laquelle vous poser votre téléphone qui lance alors l’application pour ce magasin en particulier, avec du contenu mis en avant !

Association de protocole

Dans un premier temps, il faut créer une association de protocole pour votre application. La première étape consiste à ajouter une extension dans la manifest de l’application :

<Extensions>
<Protocol Name="samplenfc" TaskID="_default" NavUriFragment="encodedLaunchUri=%s" />
</Extensions>

Ici, on associe le protocole samplenfc: à l’application (les deux autres paramètres sont les valeurs à renseigner obligatoirement, cf. http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx#BKMK_Protocolassociations).

Ensuite, il faut créer un UriMapper capable de traiter l’association de protocole. Pour cela on créé une classe qui dérive de UriMapperBase :

public class AssociationUriMapper : UriMapperBase
{
public override Uri MapUri(Uri uri)
{
string url = HttpUtility.UrlDecode(uri.ToString());

if (url.Contains("samplenfc:MainPage"))
{
int paramIndex = url.IndexOf("source=") + 7;
string paramValue = url.Substring(paramIndex);

return new Uri("/MainPage.xaml?source=" + paramValue, UriKind.Relative);
}

return uri;
}
}

Le code est assez simple ici : je récupère l’URL samplenfc:qqchose et je la converti en URL XAML.

Ecriture du tag NFC

Pour l’écriture du tag NFC, cela se passe à peu près comme dans la première partie de l’article, sauf que cette fois, le protocole n’est plus http, mais samplenfc :

private long pubId = 0;
private void OnWriteableTagArrived(ProximityDevice sender, ProximityMessage message)
{
var dataWriter = new DataWriter();
dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
//dataWriter.WriteString("http://www.juliencorioland.net");
//pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());

string appLauncher = string.Format(@"samplenfc:MainPage?source=NFCWakeUp");
dataWriter.WriteString(appLauncher);
pubId = sender.PublishBinaryMessage("WindowsUri:WriteTag", dataWriter.DetachBuffer());
}

Du coup, après avoir écrit mon tag sur la carte de développement, lorsque j’approche mon téléphone de celle-ci, j’obtiens bien le résultat attendu : le téléphone me propose de lancer mon application :

[Windows Phone 8] Utilisation du ProximityDevice NFC

Windows Phone 8 permet de mettre en place de la communication NFC entre devices, en mode tap. Pour commencer à découvrir les APIs, je vous propose un scénario ultra simple : une application Windows Phone 8 ayant deux pages. La première est capable de publier un message via NFC, la seconde est capable de recevoir un message via NFC. Lorsque l’on tape deux téléphones entre eux celui sur la page de publication envoi un message qui est reçu sur l’autre téléphone.

Publier un message via NFC

Pour commencer, il est nécessaire de récupérer une instance de la classe ProximityDevice, défini dans Windows.Networking.Proximity.

public partial class Publish : PhoneApplicationPage
{
ProximityDevice _proximityDevice;

public Publish()
{
InitializeComponent();
_proximityDevice = ProximityDevice.GetDefault();
}
}

A partir du moment ou vous récupérez une instance, c’est que le NFC est supporté sur le device !

Pour être en capacité de publier un message, on utilise la méthode PublishMessage, à laquelle on précise un type de message et le contenu du message :

private long _messageId = 0;

protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice != null)//NFC is supported
{
_messageId = _proximityDevice.PublishMessage("Windows.SampleNFC", "Hello dude, Windows Phone 8 Rocks !");
}

base.OnNavigatedTo(e);
}

A partir de là, l’application enverra le message à n’importe qu’elle autre application qui écoute ce type particulier de message, ici <em>Windows.SampleNFC</em>. Le type de message indique le protocole utilisé (avant le .) et le sous type de message. Lorsque l’on utilise la méthode PublishMessage, le protocole est obligatoirement <em>Windows</em>.

La méthode PublishMessage renvoie un id. Celui-ci est très important car votre application ne peut supprimer qu’un seul type de message à la fois. Aussi, avant de pouvoir publier un autre type de message, il faut stopper la publication, à l’aide de la méthode **StopPublishingMessage **:

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_proximityDevice.StopPublishingMessage(_messageId);
}
base.OnNavigatedFrom(e);
}

Voilà concernant la partie publication.

Souscrire à un message NFC

La souscription à un message NFC est assez similaire, puisqu’elle utilise également un ProximityDevice, que l’on récupère avec la méthode statique GetDefault, comme dans la partie précédente. Ensuite, on utilise la méthode SubscribeForMessage en précisant le type de message qu’on vont recevoir :

protected override void OnNavigatedTo(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_subscriptionId = _proximityDevice.SubscribeForMessage("Windows.SampleNFC", OnMessageReceived);
}
base.OnNavigatedTo(e);
}

Comme pour la publication, on obtient un id de souscription qu’il est nécessaire d’utiliser pour arrêter d’écouter ce type de message :

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (_proximityDevice != null)
{
_proximityDevice.StopSubscribingForMessage(_subscriptionId);
}
base.OnNavigatedFrom(e);
}

Et voilà le handler appelé lors de la réception d’un message :

private void OnMessageReceived(ProximityDevice sender, ProximityMessage message)
{
if (message != null)
{
Dispatcher.BeginInvoke(() =>
{
MessageBox.Show(message.DataAsString);
});
}
}

Le tour est joué. Voilà ce que ça donne avec deux téléphones :

[Build 2012] Windows Phone 8 – tiles et notifications

Allez, on attaque la troisième session de la journée pour voir ce qu’il y a de nouveau du côté te des tiles et des notifications.

Au niveau des notifications, l’architecture reste similaire à celle de Windows Phone 7.5 avec l’envoie de requêtes http au service de push notifications Microsoft (MPNS). Quelques nouveautés quand même, puisqu’il n’y a plus de limite concernant le nombre d’applications qui peuvent utiliser les notifications sur le device (30 sous WP7).

Il y a également un nouveau type de notification push qui permet de réveiller une application VOIP.

Du côté des vignettes dynamique il y a aussi pas mal de nouveautés, puisqu’il est maintenant possible de créer des tuiles de trois tailles différentes : petite, moyenne, large. A ces trois tailles de vignettes, il est possible d’appliquer un modèle, parmi les suivants :

Flip tile

Ce modèle est similaire à celui existant sous phone 7.x. On retrouve l’image avant et arrière, le count, le titre, le contenu…

Cycle tile

Il s’agit d’un modele permettant de faire defiler plusieurs images, un peu à la manière de la vignette du hub photos.

Iconic tile

Ce modèle permet de générer des vignettes qui possèdent un count et un logo, mais en animant le count, comme la tuile Outlook, par exemple.

Côté local tiles APIs, la ShellTileSchedule peut mettre à jour TOUTES les propriétés de la vignette. Il est désormais possible de passer un payload xml pour alimenter les tiles data, plutôt que d’affecter toutes les propriétés à la main !

Il est également possible de s’intégrer avec l’écran de verrouillage du téléphone afin d’y ajouter des informations (logo, nombre et texte) identiques aux informations de la vignette principale, mais celle-ci ne doit pas obligatoirement être épinglée.

Les APIs sont toutes plus simple à utiliser les unes que les autres et beaucoup d’incohérences que l’on pouvait avoir ont disparues. Bref, ça poutre bien comme il faut !

Stay tuned 😉

Julien