Hello World!

I installed Windows 8 Consumer Preview on the weekend, and really loving the experience. I feel Windows 8 have some hope in putting microsoft back into the map. However it can only do so if they have good apps on the Store. Regardless, I thought I'll join in the game as early as I can. If there's indeed gold : I want to be ahead before the rush.

So here I am, brewing something on the Windows 8 : playing around with WinRT/C#. (Sorry Ronan, promise I'll get back to our iPhone app during the weeknights!)

Loving It

Here are 5 reasons why I'm liking the development experience so far:

1. WinRT API design

The API design seems to be very clean. Those of who's living in .Net world will come to grip very very fast, especially for those who are familiar with WPF will feel at home straight away. I'm not talking about the XAML part but also the rest of the AP. From StackPanel, Canvas, Brush, Path and more you'd recognize what these classes do straight away.

Even for those who are not familiar with WPF could probably ramp themselves up. The way the UI elements are structured are a lot simpler than : say Cocoa Touch. Unlike Cocoa Touch which forces us to come to grip with Apple's implementation of MVC : I don't have to have a controller just to create a UI element in WinRT. That means no  IBOutlets, IBActions and UI protocols to implement & all that stuff. 

Instead, I can drag and drop UI elements (or create them in code), hook up to some of the event delegates & manipulate them to do what I want.

I know I'm over simplifying here. MVC has its place especially when you know the app will have a long lifespan & a big team to maintain it. I'm a big proponent of SOLID. But in this fast paced-disposable app-type of marketplace, it's a huge advantage to be able to pick up the tools and hack away as fast as possible to see if an idea has bearing.

2. Visual Studio 2011 Beta

Visual Studio 2010 is an unbelievably robust IDE. Hands down. Despite how good XCode 4 has become since the earlier version, it's still havent quite come close to the awesomeness that Visual Studio 2010 is.

Now with VS just got better with VS2011 Beta; gone are the days of swapping between VS and Blend to design the UI. Interestingly Microsoft takes a lot of pointers from Apple in this new direction their taking. VS2011 incorporates some of the Blend 4 functionality just like Xcode swallowed Interface Builder.

The new color scheme also looks quite refreshingly Retro. It almost look like one of those KDE hacker desktop theme that someone uploaded online.

My only wish is for Resharper to make their coding-time compiler to work with WinRT. Because as of 6.1 nightly build, it doesn't.

3. Super Awesome documentation

Microsoft yet take another page of Apple's book. The Developer Center website is filled with sample projects for quick hacks. The screenshot of my app above I did by combining 3-4 example projects into one. Not verbatim (since some of the projects are only available in C++ or Javascript), but still it showed me which WinRT classes I should be using etc.

I'm liking the metro styling of the website too.

4. there's a language for everyone

WinRT uses this technique called projections. I'm not going to pretend that I know what it means, but what it gives us is the ability to code in C++, C# and Javascript. So I'm sure there's a language that people would be familiar with.

The most interesting thing about this is, it seems the dev experience is quite optimal in any of these languages. Looking at some sample code to draw bezier curves in Javascript shows that we'd be using the HTML5 Canvas API. Whereas if I were to do it in C# (which I did), I would use a XAML Canvas instead. Both HTML5 and XAML canvas has a lot in common but very different in the semantic of the API. But it seems both are ‘mapped’, ‘translated’ or :I guess- ‘PROJECTED’ to the same WinRT's UI element.

5. C#5 async/await keywords

Last but not least, developing on WinRT means that I could use C#5 which introduces the new async/await keywords. This syntactic sugar allows us to write async calls just like as if it was a synchronous linear call.

async void CaptureButton_Click(object sender, RoutedEventArgs e)
{
    mediaCaptureMgr = new MyMediaCapture();

    await mediaCaptureMgr.InitializeAsync();

    //1: do stuff
    previewCanvas1.Visibility = Visibility.Visible;
    previewElement1.Source = mediaCaptureMgr;

    await mediaCaptureMgr.StartPreviewAsync();

    //2: do more
}

If I were to do it without the async/await keywords I would've daisy chained the async delegates by hand, probably similar to this:

void CaptureButton_Click(object sender, RoutedEventArgs e)
{
    mediaCaptureMgr = new MyMediaCapture();

    mediaCaptureMgr.InitializeCompleted += InitializeCompleted;

    mediaCaptureMgr.StartPreviewCompleted += StartedPreviewCompleted;

    mediaCaptureMgr.InitializeAsync();
}
void InitializeCompleted(object sender, InitializeCompletedEventArgs e)
{
    //1: do stuff
    previewCanvas.Visibility = Visibility.Visible;
    previewElement1.Source = mediaCaptureMgr;

    mediaCaptureMgr.StartPreviewAsync();

}
void StartedPreviewCompleted(object sender, StartedPreviewEventArgs e)
{
    //2: do more
}