Posts Tagged ‘WinRT’

Async/await is arguably one of the most important language improvement to ever come to C#. But there are a few notable gaps that can leave developers scratching their heads. Chiefly among these is the inability to support async events and properties. Fortunately, there are some patterns that developers can employ to solve these problems. In this article I will demonstrate one such way to support async events.

The following pattern is actually based on Microsoft’s own WinRT deferrable APIs so if you’ve ever built a Windows Phone or Windows Store app, chances are you are already familiar with the consumer side of the pattern.

How it works at a high level

Event handlers merely need to request a deferral from the event argument, run async code, then tell the deferral when they are done (either by calling a .Complete() on the deferral or disposing it). Easy breezy.

Event raisers need to instantiate a DeferrableEventArgs object, raise the event passing along this object to the event handler and then wait until all deferrals requested by the event handlers complete.

How to build and consume

Let’s take a look how to accomplish this in our own custom events.

Event handlers: We will start by examining what the event handler will look like. As mentioned, this should already be familiar to Windows developers if you’ve ever handled a deferrable event such as the Windows.UI.Xaml.Application.Suspending event.

MyClass myClass = new MyClass();
myClass.DoingSomething += MyClass_DoingSomething;
async void MyClass_DoingSomething(object sender, DeferrableEventArgs e)
    using (var deferral = e.GetDeferral())
        await Task.Delay(200); // run an async operation

Note: we could also call deferral.Complete() instead of .Dispose (by way of the using statement). Both have the same effect of signaling when the deferral has completed.

Event raisers: Next, let’s look at the code responsible for raising the event and awaiting all event handlers to complete work.

class MyClass
 public event EventHandler<DeferrableEventArgs> DoingSomething;

 public async Task DoSomethingAsync()
 if (DoingSomething != null)
 var args = new DeferrableEventArgs();
 DoingSomething(this, args);
 await args.DeferAsync(); // completes once all deferrals are completed.

The real magic: The real work happens in the DeferrableEventArgs object (which we need to create). I had hoped to find an existing .NET or WinRT base class already available but sadly, one does not exist. That said, Windows.Foundation.Deferral is available to reuse as the actual deferral object.

public sealed class DeferrableEventArgs
 readonly List<TaskCompletionSource<object>> taskCompletionSources;

 public DeferrableEventArgs()
 taskCompletionSources = new List<TaskCompletionSource<object>>();

 public Deferral GetDeferral()
 var tcs = new TaskCompletionSource<object>();
 var deferral = new Deferral(() => tcs.SetResult(null));
 return deferral;

 public IAsyncAction DeferAsync()
 return Task.WhenAll(taskCompletionSources.Select(tcs => tcs.Task)).AsAsyncAction();

Let’s dissect… Here we create and maintains a collection of TaskCompletionSource objects. Each time an event handler requests a deferral (by calling .GetDeferral), we create one TaskCompletionSource and mark it as complete (by calling .SetResult) when its associated deferral is signaled as completed by the event handler. The code responsible for raising the event calls DeferAsync to get a task that it can await. Here we use the Task.WhenAll method to combine all TaskCompletionSource tasks (ultimately converted to IAsyncAction to make WinRT compatible before returning it).

Hopefully this pattern will help you fully take advantage of the async await features in your app without compromising the architecture. There are other improvements that could be made here such as allowing event handlers to signal failures and cancellation, supporting deadlines, and sheltering event handlers from the DeferAsync method but hopefully this is ample to get you started with a nice reusable and robust pattern for supporting async events.


Read Full Post »

In case you missed the news, Microsoft just hit a major milestone on its road to shipping Windows 8 with the public launch of the Release Preview version. With this new version comes new features and as expected: a number of trivial, yet importing changes that will affect app developers and their apps.

Meanwhile, here at Vertigo we’ve been toiling day (and sometimes night) to help developers and clients prepare for this update so they can hit the ground running and create some of the first apps to ship on the new platform.

One such effort that we were proud to release alongside the launch of Windows 8 Release Preview is the update to the Microsoft Media Platform Player Framework (an open source video player component for Windows 8 metro style apps).


While Windows 8 includes some essential and great components to help building top notch media apps (namely the MediaElement for Xaml developers and the Video tag for JavaScript/HTML developers), the purpose of these components is primarily aimed at providing the fundamentals and low level support for playing audio and video. We here at Vertigo Software know video and we know that there is still a mountain to climb before you can ship a great media app. In a joint effort with Microsoft, we’ve worked hard to fill this gap by building a media player framework to make it simple and straightforward to accomplish the vast majority of your media app needs in Windows 8.

The Microsoft Media Platform Player Framework ships with a JavaScript and Xaml version of the framework that offers out of the box features to build great video apps without the fuss and months of development required to build your own media player. Besides support for the Windows 8 Release Preview, our latest update also includes support for major features such as player DVR controls (scrubbing, FF, RW, play/pause, …etc), player styling and branding, closed captioning, and just released today: video advertising!

Video advertising is very different from traditional banner advertising – which is already included with the Microsoft Advertising SDK. Video advertising allows you to seamlessly connect to video ad servers and stitch together commercials, overlays, and companion ads with your own content.

Advertising is an extremely important monetization strategy for many media companies and an equally significant undertaking to build from scratch. With the latest version of the player framework, you can simply add the new advertising plugin, schedule when ads should play and point your app at a VAST standards compliant ad server to play ads with your content. Ad scheduling, downloading, playback, and tracking is all handled for you by the player framework using IAB recommended standards such as VAST and VPAID.

Download everything you need today to start (or finish) your media app for Windows 8:

Microsoft Media Platform Player Framework

Windows 8 Release Preview

Visual Studio 2012 RC

Smooth Streaming SDK

PlayReady DRM SDK



Read Full Post »

Need to build an app that plays video? This week we released a new version of the MMP: Player Framework (formerly the Silverlight Media Framework) made for Windows 8 Metro style applications.

With guidance the Windows 8 and IIS teams, we (Microsoft Media Platform team & Vertigo Software) created an open source media player framework that you can use for both HTML-based and XAML-based Metro style applications.


Support for HTML and XAML

The player framework supports both HTML/JavaScript and XAML/C#/VB based Metro style applications. Technically, there are two different components (one for HTML and one for XAML based apps), but they share very similar APIs, feature sets, and in some cases even share the same source code. Under the hood, the XAML version is built on top of the MediaElement that ships with .NET and similarly, the HTML version is built on top of the HTML5 <video> tag.

Our primary goal was to ensure both flavors felt natural and familiar to both HTML and XAML developers. If you are an HTML/JavaScript developer, using the JavaScript version will be very similar to using the other JavaScript controls that ship with Windows 8 as well as those already familiar with the HTML5 <video> tag. If you are a XAML/managed code developer, you can expect the XAML version to adhere to the practices and patterns of .NET & Silverlight controls.


The framework: We refer to the player framework as a framework as opposed to a control or component because it is intended to be a mini-platform in it’s own right. While these details will be hidden to the majority of developers using it as is out of the box media player, the player framework is built on a plugin style architecture that enables the feature set to be expanded and evolve after the fact without touching the core code base. In fact, many of the features currently in the framework are implemented as plugins. For example: the main control bar that the user interacts with is technically a plugin that could be swapped in our out for a radically different implementation.

Styling: One of the most common requirements in building a media player is to be able to skin the UI to match your brand. By default, the player framework ships with a Metro style skin, but you can easily modify the look and feel of the player from CSS or XAML without having to build a custom player.

Open source: the player frameworks ships with full source code under the liberal Ms-Pl license. Crack it open and see how it ticks or make changes to suite your needs.

How similar is it to the existing HTML5 or Silverlight versions of the player framework?

You may already be familiar with the existing HTML5 for the web or Silverlight for the web/desktop and phone versions of the player framework. The Windows 8 version of the framework should feel familiar and is in fact based on much of the same code. However, you should not expect full compatibility. We wanted to make sure the player framework felt like it was made for Windows 8 Metro style apps and it’s respective development model (HTML vs. XAML). We also wanted to meld the two versions and their APIs when it made sense. Lastly, we used this opportunities to make architectural improvements that would better position the framework for a long and bright future.


You’ll find that the player framework has an extensive API chocked full of many useful hooks and features. From 30,000 feet, here is a sampling of features you will find in v1 of the player framework.

  • VOD
  • Progressive video
  • Smooth streaming
  • Rich DVR (Play, pause, stop, fast forward, rewind, skip next & back, seek-able timeline, volume, slow motion, instant replay)
  • Full screen
  • Closed captions (plain text for Xaml and WebVTT for js)
  • Styling support
  • Buffering and error/retry visual states.
  • Poster image
  • Click-to-play UI to let the user choose to start watching.
  • All features already included with the MediaElement and <Video/>
  • Playlist
  • Chapters
  • Timeline markers
  • Support for localization
  • Compact UI for snapped view
  • Support for DRM (e.g. PlayReady)

What’s next?

The fun doesn’t stop here. We’re already hard at work on more features. Here are some prominent ones in the cards.

  • Adaptive streaming APIs
  • Advertising
  • Audio player
  • TTML closed captions
  • Audio track selection (multi-language audio)
  • Live video

Got feedback?

We’d love to hear your feedback and make sure the player framework offers the features and functionality you need in your apps. We encourage developers to check out the player framework on CodePlex and post feedback on the CodePlex forum.

Hope you enjoy!

Read Full Post »

In my earlier post I created a high level breakdown of the APIs shared by both Silverlight and WinRT…


Here I’m providing a complete reference of all 6,585 public types and 15,248 members included in Silverlight 5 and/or WinRT and where they overlap.

My hope is that this will serve as a reference to Silverlight developers trying to get up to speed with WinRT.

Click here to see the WinRT Genome Project results.



Note: Please let me know if you see an errors or have requests. I’ve only begun to comb over these results myself and will be looking for ways to improve it going forward. Enjoy!

Read Full Post »