Did Microsoft Preview Windows Phone 8 in June?

Well, no they didn’t.

However while playing with the Developer Preview on my BUILD tablet it struck me as odd that a snapped app takes a very narrow view rather than a 50/50 split.
The app is notified when the mode is changed so it can switch its appearance to a different XAML (or HTML) view, optimized for the smaller space.

That’s a lot of effort just to get two apps side-by-side…

Metro Snap - 1/6th of the screen on a 16:10 display

Think about it!

The snapped UI is a phone UI!

Windows Phone 8 mock-up

I’m sure they’d have loved to announced Windows Phone 8 and show how you can elegantly run phone and tablet apps on the same device (from the same binary in fact) – significantly better than the 2x mode on the iPad.

Unfortunately doing so would have reduced Windows Phone 7′s traction to zero so they just called it “Metro Snap” and everybody nodded and clapped anyway!

I’m betting sometime next year they’ll announce that Windows Phone 8 is basically Windows 8 (ARM) with some customizations.
Developers won’t need to do anything to make their Win8 apps run on the phone as they’ll already have done the work without even knowing!

Windows Runtime XAML for the Desktop

The message at BUILD was very clear that for building classic desktop applications nothing has changed (use MFC, WinForms, WPF or Silverlight). If you want to use the new toys you have to make a Metro style app.

That was a bit of a disappointment as whilst I like Metro style I don’t want to see Desktop applications relegated to legacy status.

The first thing I wondered when I saw the new Task Manager (C:\Windows\System32\TM.exe) was if it had been written using WPF or WinRT using some undocumented APIs.

Windows 8 Task Manager

Well I was wrong as it’s neither. Just opening it in notepad reveals reams of plain text UI mark-up that show it’s written using the internal-only UI framework “DirectUI” (also used for Windows Media Center and Windows Live Messenger).

.....
<element resid="GenericCommandBar" id="atom(GenericCommandBar)" class="TmCommandBar" layoutpos="bottom" sheet="TmCommandBarStyle" layout="borderlayout()" accrole="pane" accessible="true" active="mouse">
<button id="atom(CBExpandoButtonText)" layoutpos="left" active="mouse" accname="resstr(37209)" padding="rect(5rp,0rp,0rp,0rp)" contentalign="middlecenter" visible="true"/>
</element>
<element id="atom(dashboardBar)" layout="flowlayout(0,2,0,2)" layoutpos="none" padding="rect(8rp,0rp,0rp,0rp)" borderthickness="rect(0rp,0rp,0rp,0rp)" visible="false" accessible="false">
<AccessibleButton id="atom(resmonLaunch)" sheet="TaskManagerCommon" class="link" accessible="true" active="mouse|keyboard" layoutpos="left" padding="rect(5rp,0rp,0rp,7rp)" accrole="link" accname="resstr(34283)" contentalign="middleleft" content="resstr(34283)"/>
</element>
<element resid="CBTaskButtons" id="atom(CBTaskButtons)" sheet="TmCommandBarStyle" layout="flowlayout(1,2,1,2)" layoutpos="client" padding="rect(0rp,0rp,8rp,8rp)">
<element resid="TmTaskButton" id="atom(TmTaskButton)" sheet="TmCommandBarStyle" layout="BorderLayout()" layoutpos="right" accessible="false"> <AccessibleButton id="atom(CBRestartButton)" class="TmTaskButton" enabled="false" visible="false" margin="rect(4rp,0rp,0rp,0rp)" active="mouse|keyboard" layoutpos="none" contentalign="middlecenter" content="resstr(38002)" shortcut="auto" accessible="true" accrole="pushbutton" accname="resstr(38002)" accdesc="resstr(38002)"> </AccessibleButton> </element>
</element>
</duixml>

Interesting, but it didn’t get me any closer to disproving that WinRT is only for Metro.

Next I broke out Reflector and had a browse through some of the more interesting Metadata files from the standard WinRT components (C:\Windows\System32\WinMetadata) until I stumbled upon this:

Windows.UI.Xaml.Window

What’s a Window class doing in System.UI.Xaml? Hmm…

I created an empty C# project and after playing with the System.UI.Xaml.Application and System.UI.Xaml.Window classes for a while, managed to get a very basic XAML application to show.

WinRT Desktop Window Sample - See below for download link

It’s a bit glitchy (responds poorly to Window resize events + never redraws the gradient) and all the default templates are unsurprisingly Metro-style but generally everything works (Data Binding etc.)

I tried accessing some of the Windows Runtime features like the webcam but had no luck. That’s not surprising because this project type doesn’t have the Package.appxmanifest file required to describe what to ask the user for permission.

This all might be removed by the final release but I think it’s much more likely that it’ll either be finished or officially supported post-SP1.
For now they’ll continue to push Metro apps as the way forward. Officially supporting WinRT desktop applications would dilute that message plus give them more work.

One further nod towards desktop WinRT support is that I’ve seen the permission dialog appear on the desktop (e.g. “Do you want this application to access the webcam?”).
It did it after a blue screen (“Do you want to send this report to Microsoft?”) and also does when running a blocked file from explorer.

Windows Runtime style permission dialog in the Desktop

Download C# WinRT Desktop Sample (WinRTDesktop.zip)
Sample requires Windows Developer Preview and Visual Studio 11 Developer Preview

BUILD – Windows 8 Developer Preview

Here are some thoughts from the first day of BUILD.

Hardware

The Samsung tablet is a really impressive piece of hardware. I’ve been playing with it for a few hours now but I’m still not sure exactly what to think. Realistically nobody will buy anything like this as it’s heavy & expensive, however the performance seems nothing less than incredible. I noticed during the keynote when they played with an ARM tablet that the scrolling speed was noticeably choppy – something this definitely doesn’t exhibit. Hopefully I’ll get to see that in more detail later.

UI

It’ll take a while to get used to the Start key loading the new Metro style home screen. All of this is such a massive change I’m actually shocked they’ve gone this far.
It’s very much like Windows Phone 7 but I suppose that shouldn’t come as too much of a surprise.
One interesting change in Desktop mode is that the taskbar finally spans multiple monitors! (Goodbye Ultramon)

Software

Random thoughts:

• Yes, you can access the entire file system from Metro apps (not only My Documents etc.)
• No, you can’t pin more than 1 metro app to the side of the screen for side-by-side mode.
• Metro mode only ever uses 1 monitor.
• The HTML/CSS Metro apps have all the same UI controls out of the box as the native WinRT UI apps made using XAML but it seems like they just follow a similar API and have been completely re-implemented, sharing nothing.
• Visual Studio’s XAML editor now uses the Expression Blend XAML editor.
• Expression Blend is now also an HTML/CSS editor.
• Expression Blend has an “Interactive Mode” option which lets you run the app through to the screen you want to edit and then switch into editing mode. I’d imagine that only works for HTML apps but I haven’t had time to check yet.
• They couldn’t stop stressing that performance was a major goal for WinRT so it’ll be fascinating to compare with WPF (which interestingly has yet to be uttered).

The problem with Windows Phone Chassis Specifications

If you look at the sales figures for Windows Phone 7 it’s already close to being a failure. All Microsoft have officially revealed is they’ve sold 1.5 million to retailers though that means nothing as the majority of them are still on shelves.
Over 160,000 Android devices and over 65,000 iPhones are sold each day so the 40,000 WP7 launch-day sales (mainly to developers, I’d guess) was very weak.

With CES less than two weeks ago, Microsoft are in for yet another problem. There will be numerous Android handsets powered by NVIDIA Tegra 2 (Dual-core Cortex-A9 1.0+ GHz). Microsoft won’t be able to respond with a new “Chassis” specification for months. They’re already using the first generation Qualcomm Snapdragon QSD8250 (Q4 2008) for the current ‘Chassis 1′ WP7 devices. That alone is borderline acceptable considering how many Android devices already use the second gen and will probably use the third gen (dual-core) Snapdragon at CES too.

So what do we know about the future of Windows Phone hardware? Is ‘Chassis 2′ going to be the ultimate smartphone? No. Chassis 2 is low-end with a 480×320 display. The whole point of Chassis specs was to set an absolute minimum so this is really yet another fail. Now developers will have to test their apps for two screen resolutions when they were initially told it’d be one.

2011 is going to be the year of the dual-core smart phone, and from early too. You can be assured the summer iPhone (4S?) will be dual-core, yet Microsoft with the newest platform of all the competitors will have the worst hardware.

Judging from the lethargic pace they’ve put out software updates for WP7 (none so far) I wouldn’t expect to see modern hardware until Q3 2011 and by then it probably won’t be modern anyway.
The problem with having chassis specifications is it’s difficult to keep pace with the rampant progress of mobile hardware. Android’s advantage in being open source allows the manufacturers to choose the hardware they wish to run on.

As things stand, if you’re a Microsoft supporter you really need to hope the rumours of an ARM port for Windows 8 are true, to reboot their mobile strategy in 2012.

I actually like the look of this render but I wouldn't buy something so low-resolution in 2011.

 

Windows Phone 7 Devices

I’ve recently been asked for my opinion on which Windows Phone 7 device to buy. As Microsoft set a respectable minimum hardware spec, the current range of handsets are all virtually identically except in the most important area: the screen! They all share the same WVGA (800×480) resolution but some have LCD panels while others have OLED.

When phones such as the Google Nexus One started appearing with OLED screens it became a very nice to have feature as the colours are more vibrant and there was promise of lower power consumption. Since then we’ve started to realise that OLED in its current form isn’t what we were sold and a quality IPS LCD panel such as in the iPhone 4 can easily outperform it.

This article created a lot of internet chatter a few months ago comparing the two technologies. Basically OLED typically isn’t better (actually worse) for power consumption and in the case of the Nexus One arguably isn’t even true WVGA because it uses a technology called PenTile to allow pixels to share sub-pixels.

PenTile on Nexus One OLED Panel

My thoughts? Don’t make OLED a requirement for your next Android device.

However, I’ve changed my opinion for WP7. The most brilliant idea in this OS is the Metro UI white-on-black theme. This prevalence of black takes full advantage of OLED as virtually no power is required to display black pixels. Additionally it looks stunning when UI elements on the black background appear almost to be floating in your hand when in a dimly lit room.

This whole experience is destroyed if you get a WP7 device with an LCD screen. In fact the HTC HD7 comes out of the box with the black-on-white theme enabled!
I’m not surprised that Microsoft didn’t add OLED to the WP7 chassis minimum requirements but I think they probably should have done. They’ve the only OS where it really makes a startling difference.

Conclusion? If you want a WP7 slate get the Samsung Omnia 7. If you want a qwerty keyboard get the Dell Venue Pro. They’ve both OLED (Super-AMOLED in the case of the Samsung) and are really high quality phones.

Samsung Omnia 7

Dell Venue Pro

Windows Phone 7 – Silverlight on .NET Compact Framework?

I’ve noticed that the majority of people haven’t noticed or questioned why Silverlight on Windows Phone 7 doesn’t run on the CoreCLR but instead is running on the .NET Compact Framework.

One of the main objectives of the CoreCLR seems for it to be relatively portable. They’ve excluded everything they could get away with that calls out to native code and written an abstraction layer to ease the porting process.
You’d think porting to their second OS would have been even easier than to Mac OS X.

Silverlight CoreCLR Platform Adaption Layer - http://msdn.microsoft.com/en-us/magazine/cc721609.aspx

I’ve been unable to find an explanation for this but I’ve given it some thought and here’s my theory:

Now that we’ve got Windows Phone 7 devices in retail it’s very easy to forget that this is Microsoft’s Plan B. We were supposed to get Windows Mobile 7 before it was scrapped.

Windows Mobile 7 - Could have been awesome

It made sense for Windows Mobile / CE to have Silverlight separate from the runtime as their applications are developed using either managed or unmanaged code. It would have been great to simply reference the Silverlight assemblies from your existing C++ or .NET WinMo application and start replacing its ageing UI.
In fact on CE7 you can use Silverlight with native C++ code.

Given their clean-slate approach to Windows Phone 7 and disallowing previous WinMo apps, this choice now looks completely pointless. We’re left with a non-standard Silverlight that can’t use a considerably amount of existing code due to the Compact Framework’s deficiencies (e.g. IoC containers such as Unity or Autofac don’t work due to the lack of the Reflection.Emit namespace). We’ll also never see Silverlight running inside the phone’s browser which seems a little absurd given that we’re repeatedly told the OS uses “Silverlight”. Maybe so, but it’s not the Silverlight we know and love.

Oh well, it’s still better than Cocoa Touch.

Windows Phone 7 - Do not want?