Month: November 2011

Metro Slide Deck

James Ashley

Thanks to everyone who came out to the Windows Phone Garage / Mobile Hackathon for Social Good at the WebVisions conference in Atlanta and showing your solidarity with the Occupy Wall Street movement.  And thanks to Macquarium for hosting the Thursday sessions.

I’ve uploaded the slide deck for my talk on the Metro Aesthetic. 

I also wanted to mention, for those who missed it, that I was interviewed last month by Steven Cherry about the Windows 8 Tablet Story in a podcast  for IEEE Spectrum (which he titled “Microsoft’s Polygamous Windows 8”): http://spectrum.ieee.org/podcast/geek-life/tools-toys/microsofts-polygamous-windows-8  It was a lot of fun to do and I was impressed with how adroitly Steven was able to edit out my long pauses and “ums” and “uhs” when I didn’t know what to say. 

No Phone App Left Behind on Win8: A Proposal

James Ashley1 Comment

winrt

As the Windows 8 tablet comes closer to reality, its success will depend on the amount of content it can provide out of the gate.  The Windows Phone Marketplace has tens of thousands of apps that should be leveraged to provide this content.  The main barrier to this is that the development stacks for Windows Phone and Windows 8 are significantly different.  A simple solution to bridge this gap is to enable Metro Tiles for Silverlight apps running in “classic” mode – something not currently easy to do on the Windows 8 platform.  Here is the background.

There has recently been a revival of chatter about the death of Silverlight revolving around the notion that Silverlight 5 will be the last version of the platform we are likely to see: http://www.zdnet.com/blog/microsoft/will-there-be-a-silverlight-6-and-does-it-matter/11180?tag=search-results-rivers;item2

At the same time, Hal Berenson has lain out an argument for moving the WinNT kernel (MinWin?) into Windows Phone 8, a suggestion backed up by Mary Jo Foley’s reporting that there is a Project Apollo to do something like this. 

The main argument against the claims that Silverlight is dead concern the fact that it is currently still at the heart of Windows Phone development.  If MinWin from the Windows 8 OS for tablets replaces the WinCE kernel on Windows Phones, however, what will be the fate of Silverlight then?

The 40,000 App Bulwark

The most important piece in this complex chess game Microsoft is playing with its various technology platforms — old, new and newer (remember when Silverlight was still bleeding edge just a few months ago?) – is neither at the kernel level nor at the API level nor even at the framework level.  The most important piece is the the app marketplace Microsoft successfully built around the Windows Phone.  In a game in which almost any move seems possible, those apps must be protected at all cost.  30,000 apps, most of them built using Silverlight, cannot be thrown away.

At the same time, Windows Phone is a side-game for Microsoft.  In order to succeed in the smart phone market, Microsoft merely has to place.  The number three spot allows Microsoft to keep playing.

The main event, of course, is the tablet market.  Windows Phone can even be considered just a practice run for the arena where Microsoft really sees its future at stake.  The tablet market is make or break for Microsoft and its flagship product – its cash cow – Windows.

Fragmenting the app market into Silverlight on Windows Phone and WinRT’s three development platforms on Windows 8 seems nothing short of disastrous.  Microsoft needs those 40,000 apps as they launch their new tablet platform.  Without apps, all the innovations that are going into Windows 8 are practically meaningless.

My colleague at Razorfish, Wells Caughey, has recently written about his efforts to create live tiles for “classic” apps on the Windows 8 Developer Preview: http://emergingexperiences.com/2011/11/leveraging-the-windows-8-start-screen/ .  It’s hacky but works and allows several dozen of our apps written in WPF, Silverlight and even Flash to run inside the Metro environment on Win8.

What we learned from the exercise is that Microsoft has the ability to allow live tiles for classic apps if it wants to.  It currently does this for the classic windows desktop which runs as an app from the Metro desktop. 

Were Microsoft to do this, they could easily gain 40,000 apps at the Windows 8 launch.  Silverlight for Phone apps are relatively easy to turn into regular Silverlight apps.  It could be made even easier. 

On top of that, developers already know how to write Metro style apps using WPF, Silverlight and other tools.  Even since the introduction of true multitouch capability in WPF 4 and multitouch controls for Silverlight WP7 development, this is what we have all been working on.

For the moment, however, Microsoft is still apparently pushing for people to learn their new development tools in order to program for Windows 8 Metro and Windows Phone developers are being advised to learn WinJS and the currently somewhat anemic WinRT Xaml platform in order to port their apps.

This is all well and good but why does Microsoft want to leave its greatest asset in the tablet market – its 40K phone apps – on the sideline when enabling live tiles for these apps immediately puts them back in the game?

[note: Microsoft just broke the 40K milestone, so references to “the 30K app bulwark” have been edited to reflect this.]

 

Changes in Kinect SDK Beta 2

James Ashley

blamed_rachel

To celebrate the one year anniversary of the Kinect, Microsoft has launched a new Kinect website and released the Beta 2 version of the Kinect for Windows SDK: http://www.kinectforwindows.org/ .

This is not the commercial license we have been waiting for (it is reported to be coming in early 2012) but truly the next best thing.  The Beta 2 SDK introduces many performance improvements over the Beta 1 that was released in June. 

With the improvements also come some alterations to the basic syntax for instantiating the core objects of both the Nui and Audio namespaces, though these changes also have side-effects that will likely affect your code.  In particular, I want to cover one substantial change in the Nui namespace and one substantial change in the Audio namespace.

In the Beta 1, it was standard to instantiate a Nui.Runtime object in order to configure applications to read the depth, color and skeleton streams.  In a WPF application, the code looked like this:

        Microsoft.Research.Kinect.Nui.Runtime _nui;

        public MainWindow()
        {
            InitializeComponent();

            this.Unloaded += (s,e) => _nui.Uninitialize();
            _nui = new Runtime();

            _nui.Initialize(RuntimeOptions.UseColor 
                | RuntimeOptions.UseDepth);
            _nui.VideoFrameReady += _nui_VideoFrameReady;
            _nui.DepthFrameReady += _nui_DepthFrameReady;

            _nui.VideoStream.Open(ImageStreamType.Video, 2
                , ImageResolution.Resolution640x480
                , ImageType.Color);
            _nui.DepthStream.Open(ImageStreamType.Depth, 2
                , ImageResolution.Resolution320x240
                , ImageType.Depth);

        }

In the Beta 2, the Nui.Runtime has been obsoleted.  Instead, the Runtime type provides a static collection called Kinects that returns a Runtime object for each Kinect connected to the PC.    Additionally, in the new Beta, Runtime objects cannot be configured and used in the Initialize method as was possible with the Beta 1.  Instead, this must be done in the Loaded event handler.  This has ended up breaking a lot of my Beta 1 code.  Fortunately the refactor is fairly easy.  The following code assumes there is only one Kinect sensor plugged into the PC.  

        Microsoft.Research.Kinect.Nui.Runtime _nui;

        public MainWindow()
        {
            InitializeComponent();
            this.Loaded += (s, e) =>
                {
                _nui = Runtime.Kinects[0];
                _nui.Initialize(RuntimeOptions.UseColor);
                _nui.VideoFrameReady += _nui_VideoFrameReady;
                _nui.VideoStream.Open(ImageStreamType.Video
                , 2
                , ImageResolution.Resolution1280x1024
                , ImageType.Color);
                };
        }

A central difficulty in working with the audio namespace is that the DMO named the KinectAudioSource, which is as fundamental to audio processing for the Kinect as the Nui.Runtime is for video and skeletal processing, must be instantiated on a thread running in a multithreaded apartment model.  WPF applications, unfortunately, run in an STA thread.  This required a bit of additional wiring up in the Beta 1 to create the KinectAudioSource object on a separate thread.

With the Kinect for Windows SDK Beta 2, this is implicitly taken care of for us.  If you have already been working with the Beta 1 audio namespace, you will finally be able to take out the workarounds you created to program against the audio stream along with all the additional care required for dealing with a multithreaded application.

[Thanks to Clint Rutkas of Coding4Fun for correcting me on the difference between obsolescence and breaking changes. The new Runtime instantiation process is not technically a breaking change.]