Lee Whitney's Blog

Five things to know before you start developing Windows 8 Metro apps

 

The only way to build a mobile tablet app for all versions of Windows 8 will be to use the new Metro application framework, and it’s much different than previous Microsoft platforms.  Developing Metro apps for Windows 8 is a combination of leveraging your existing skill sets and learning concepts that are new to the platform.

Following are five things that make developing Metro apps new and different.  Food for thought as you dive into new waters and create the next great app that will earn you fame and fortune.

 

 

 

1.  Programming language now determines your presentation layer

Previously Windows developers could choose a programming language like C# or VB, and separately choose a presentation layer like WinForms or DirectX.

When developing Metro apps, if you choose C#, VB, or C++ you automatically buy in to XAML as the presentation layer.  If you choose Javascript, your destiny is tied to HTML5 and CSS3.   There is no mixing of C# and HTML5, and no mixing of Javascript and XAML. 

This coupling of language and presentation increases the importance of making the right language decision for your project.  Deciding which is better largely depends on what the priority is for your project. 

Javascript and HTML5 are a great investment when you want to build skills that can be reused on widely diverse projects.  For example Javascript can be used to build Metro apps, HTML pages, native apps for all mobile devices, and even server side systems like NodeJS.

C# and XAML have the advantage of a large number of developers already being experienced with the technology.  My sense is that with respect to a Microsoft platform like Metro, more developers know how to animate with XAML than with CSS3.  Not having to relearn the basics on a project with a tight schedule can be a lifesaver.

Choose your language strategically based on existing skill sets and what future projects you want to be ready for.

 

2.  NoSQL has a new meaning

Metro apps are unique in that they do not have easy access to a SQL based relational data store.  Most existing Microsoft platforms can directly use some flavor of SQL Server such as Express, Compact, or CE, but this is currently not the case in           the Metro sandbox.

Even if you downloaded and integrated an open source database like SQLite, there may be problems getting your app approved because of security requirements.  Most databases have not yet been designed to run within sandboxed environments.

So how do you manage data in a Metro app?  Of course data can be written to the file system and manually managed, and there is also an interface to an ISAM data store (ESE,  Jet Blue).   However probably the most common approach will be to use one of the semi-structured data storage mechanisms.

Metro apps have access to IE10 local storage technologies such as IndexedDB, which is an emerging standard.  It is also very simple to use a cookie style local storage mechanism for key-value pairs.  Finally, it’s still possible to call web services that make use of SQL on a separate server, but that doesn’t help with local data storage.

So all is not lost, but this is definitely a different world for developers, plan your data management accordingly.

 

3.  Background tasks work differently

Running code in the background has always had rules.  One rule that has always been intuitive to most developers is that once you start a background process it will continue to run until you stop it.  This is no longer true.

With Metro, apps that are in the background do not automatically continue to run.  Instead they are suspended until the user brings them to the foreground.  By default only the foreground Metro app will be running and taking CPU resources at any given time.  This is not a limitation; it’s by design and is a new model for app behavior on Windows.  The idea is to maximize responsiveness for the user, and to conserve resources for mobile devices.

If this all sounds familiar it’s very similar to the way iOS works.  When Apple added multitasking to the iPhone, it only allowed for background tasks to run in very specific scenarios, and so it is with Metro apps on Windows 8.  Metro apps can request to run in the background for audio playback, data transfer, and notifications.

This new model is primarily motivated by mobile scenarios, however it is also the model for Metro apps on the desktop.

 

4.  Don’t expect to have all of .NET’s functionality

We’ve come to rely on the greatness of .NET, but in Windows 7 the .NET framework was built using the entire Win32 API.  With Metro, everything is built (including .NET libraries) on the new WinRT API.  The bottom line is that .NET functionality for Metro will be a subset of all that is available with the full framework.

For example, is WCF supported for Metro apps?  Yes and no.  The core client scenarios all work, but the WS* specifications like WS-Security are not supported.  The MTOM binary attachment encoding is not supported. 

The good news is Microsoft has chosen the subsets carefully to maximize what is possible.  It’s just a good idea to double check what’s supported if you have specific needs.

 

5.  The new UX is not just new controls

Previously new versions of Windows added new controls (widgets), but the core idioms stayed the same.  Windows 1.0 (released in 1985) and Windows 7 both have menu bars, captions, and resizable app windows.  Windows 8 Metro apps have none of these.  Even the Metro-ish UX on Windows Phone 7 is different, it has things like the panorama control while Windows 8 does not.  Our cheese has been moved. 

 

Because of this our job description now includes learning about the new UX idioms in Metro so that we can know when they make sense for our apps.  Some of these include the AppBar, Semantic Zoom, Partial Page Docking, and Charms.  There is a dedicated MSDN area that covers all of these here: http://msdn.microsoft.com/en-us/library/windows/apps/hh779072.aspx.

You probably don’t need all of these new features in your first Metro app.  However if you don’t take advantage of the ones that are appropriate it could make for a less than perfect fit with Windows 8.

 

Onward and upward

Windows 8 is not just about technology changes for change sake.  All of the items above are part of a bigger picture to enable better apps and faster development.  Visual Studio 11 is the primary tooling for Metro development, and fortunately it retains the title as the best development platform on the planet.  Overall Metro is calling us to create the next killer Mobile apps.

 

Quantum Mechanics, Negative Entropy, and Super-fast Computers

The overlap of computer science and theoretical quantum physics grew a little today when the journal Nature published a very cool new paper from scientists in Zurich.

What entropy means to software people is usually much different than what it means thermo-dynamics people.  Turns out the concepts can be unified via a deeper understanding of quantum mechanics.

If you are a normal person you probably fell asleep reading the last two sentences.  If you're an abnornal person and are interested in things like the ultimate limits of super-fast computers, it's worth a read.

Here's an article on the paper from Science Daily. 

 

Live from New York

A Surface application I’ve been working on has just gone live to the public in Manhattan, NY.  You can check it out at Bloomingdale’s in the Clinique area.

 
All the real products you see in the photo can be used interactively.  For example you can place a tube of moisturizer on the table and have it sent to your Facebook wall or e-mail.

 

 

Everything “feels” great to use – the gestures, discoverability, and design I all like personally.  Although the last statement may sound self-serving it’s really to the credit of the designers and Clinique product team.  By the end the process they really “got it” and have enabled a special experience.

 

 

 

Performance of Water Simulation with Hardware Acceleration using Microsoft Frameworks

I’ve found that creating water effects that respond interactively and smoothly is not really something easy to do in WPF or Silverlight.  However because a project required it I trudged forward managed to get it working pretty nicely – buttery smooth and low CPU utilization.

The results can be seen in the video, but the reasons it wasn’t easy may be interesting to WPF/Silverlight developers so I’ll mention why below.  Can you guess what the technical obstacles are?

                              (user interaction 17 seconds in)

                              (user interaction 17 seconds in)

Graphics architecture

The first hurdle is that WPF and Silverlight primarily use a “display list” or “retained mode” graphics architecture.  This is usually not a bad thing, and allowed developers to break away from the WM_PAINT model which is used in WinForms and Win32 before that.  Those older systems encourage an “immediate mode” architecture while WPF and Silverlight encourage a retained mode, but will tolerate immediate mode in certain cases.

WPF and Silverlight

You might have nightmares about WinForms and Win32 and wish all manner of death upon them.  Death to immediate mode as well – long live WPF/Silverlight and retained mode graphics! 

Just one small problem – immediate mode graphics are well suited to certain things like games and simulations, and no one wants give those up.  In fact Direct3d itself is an immediate mode architecture which underlies most graphics in Windows 7 including WPF itself.  I’m speaking in general here and there are always exceptions.  For example I’ve written simple games and simulations in WPF, but many times it is not an ideal approach.

Animation vs. Simulation

To get more specific on why WPF/Silverlight are not great at simulating water, it’s basically about loops.  Many simulations for water and other phenomena run a programming loop over and over again throughout the simulation.  The reason is that future states of the simulation depend on the output of previous states of the simulation.  The problem is that animations are different than simulations.

In WPF you can easily animate a ball along a flat line.  WPF determines the position of the ball using a function with time as the input:

• Time elapsed 1 second  -   Move ball to 25% along the line
• Time elapsed 2 second  -   Move ball to 50% along the line
• Time elapsed 3 second  -   Move ball to 75% along the line

You could also choose any random time and the ball would be placed properly because the new position does not depend on the previous position.  It’s always just a function taking any time as an input, and spitting out a position as output.

Most animation systems work in a similar way, which is why regardless of what applications artists and animators choose it usually has a big timeline along the bottom.

So if that's how animation works, how is simulation different? 

In simulation of water our function to calculate the new position takes not only time as an input but also the previous position of the water.  This feedback loop is the key difference.

Since WPF does not encourage loops that let you feedback the output into the next input, we are kind of stuck.

What about CompositionTarget?

One ray of hope is the CompositionTarget.  This is a WPF component specifically designed to enable controlling your own rendering loop.  I consider CompositionTarget going a bit off the reservation because it’s not really a mainstream technique used by most apps, however it’s fairly clean and that’s ok if it can get us past the loop barrier.  While this lets us have precise control over the rendering loop, it still does not allow any way for output of the shaders to feed back into the loop.  

We could just not use shaders and write the code procedurally, but then the question becomes how much performance do shaders afford our simulation?

How fast are shaders in WPF?

VERY fast.  In fact to get nice performance and realistic water, custom shaders are essentially required.  It's an order(s) of magnitude difference.  Using shaders should be no problem because WPF supports shader model 3.0.  In fact in a previous blog post I showed a single drop water effect using WPF shaders and the code is simple XAML with no problems.  But again, that was an animation not a simulation.  The drops could not affect each other and you could not drag your finger through the water and create a wave as in the video above. 

To get some real coolness we need a simulation, which means using the output from the shader as the input for the next time the shader is run.  The problem is when you capture the output of shaders as data in WPF (rather than just display the output), you lose hardware acceleration and performance goes to heck in a handbasket.  One item on my wishlist for WPF 5.0 would definitely be enabling a form of shader trees where the output can be modified and looped back as input.

To keep pixel shaders running in hardware in this fashion within a WPF app requires Direct3d, which in turn requires D3DImage.  D3DImage is the class that can allow separate Direct3d C++ code to output into an image brush within a WPF app.  It also allows (requires really) the Direct3d code to have it’s own rendering loop, which allows us to feed shader output back to the input for the simulation.

With Silverlight its worse because of the lack of GPU acceleration and because the Direct3d integration is not an option.  I’ve seen a few liquid/particle simulations in Silverlight but they are quite slow, and tend to peg CPU utilization. 

So the bottom line is to create interactive effects like this in WPF really requires CompositionTarget, custom shaders, and a separate Direct3d helper DLL.  The first two techniques alone will do the same thing at about a quarter of the speed.

Every year I hope to never code in C++ again, but it looks like that time is not here quite yet.

 

Anti-Feature Requests - A different way to contribute to Open Source Projects

 A lot of contributions to OSS are either writing code to add new features, or users requesting new features.

Both of these roles are critical but I've noticed there are few OSS participants formally identified as part of a "triage" team, yet it's quite common in the commercial software world.

Triage is essentially helping to decide what work should not be done, so that precious resources get applied to the best possible features and fixes (or least what work should have lower priority).

The term comes from the medical emergency rooms where doctors triage the patients into groups of different priority.  If you've broken your arm, you'll being waiting behind the person who needs immediate surgery, even if you arrived an hour earlier.

Certainly triage happens in OSS, a lot of times by development leads.  Tough decisions happen all the time.  However scouring a huge bug list for items that should be shifted up or down in priority, or questioning obscure items that might really not be as important, doesn't seem to always happen as much as it could.  How could it with only extremely busy developers held responsible?

Once example of this not being emphasized in OSS is that many projects have an option to "Vote for this issue as important", while not having an option to "Vote for this issue as not important" (allowing votes to be cast as 0 to 5 stars would help this).

So for projects where I contribute or at least follow the progress, I'm trying to make sure I keep an eye out for helping with triage where it seems productive.

Some project leaders may not want anti-requests or triage help, and that's of course their choice.  However I just think we should remember that an anti-request could be the catalyst to get your actual feature request enough resources to be completed sooner.

Lee