Developing for Surface, part I

Surface is cool. There’s no doubt about that. People who walk up to the machine and start using it are usually impressed by it. That also goes for developers: they are sometimes even overwhelmed by it and start to wonder how hard it is to develop software for this platform.

The good news is, is that it is actually fairly easy to build software for the Surface platform. Well, easy… if you know how to develop in WPF that is. In this post I will outline the most common steps to take to develop your own Surface application.

Surface SDK

First of all, you need access to the Surface SDK. When you buy a Surface unit you get access to the Surface Community site where you can download this. On a developer unit it is preinstalled, but I wouldn’t recommend doing all your development on the unit itself. It’s likely there are more people than just one working on a project and the team cannot use the unit at the same time (the multi-user experience doesn’t extend to developing software on Surface). When you install the SDK you get the API’s, the tools, Visual Studio templates and the simulator. This last piece of software is a tool that mimics the Surface Shell so you can develop your software on your workstation. Of course, testing should be done on the Surface unit itself!


There are two possible ways to write software for the Surface. When you install the SDK you will find that there are two new templates installed in Visual Studio

New Project Dialog

As you can see you can choose between a WPF application and a XNA application. The reason you have this choice is not quite clear, but it is likely that it has to do with the origins of XNA.

When the XBox came out, Microsoft decided they needed a development environment for this platform. This became XNA. Later, when the Zune was launched, they added Zune capabilities to the XNA environment. Apparently, they thought that XNA was going to be the platform for development for devices. Surface is such a device so it was pretty obvious that XNA would be the way to go. Until they discovered that the development experience for Surface looks a lot like developing in WPF (which was still in the works back then). So they added a set of libraries to standard WPF and tried that.

I wouldn’t be surprised to see that the XNA version will disappear in the future. For me, as a WPF developer, the WPF template is the way to go. And that goes for about 90% of the Surface developers I meet.

WPF Development

When you create a new WPF Surface application, you get a project consisting of a couple of files:


At first, this looks like a normal WPF project.You have your App.xaml and a SurfaceWindow1.xaml which is your startup windows. Next to this the template has additional references: Microsoft.Surface, Microsoft.Surface.Presentation and Microsoft.Surface.Presentation.Generic. Finally you’ll see the MyFirstSurfaceApp.xml, which is a file we need when we deploy our application. Last, there are some default resources, with the icon (this will show up in the Launcher), the iconPreview (also for the Launcher but this is the one that gets shown when  your app is selected) and the default WindowBackground (the background image for your main window). You can (and should) change these. For now, let’s leave them like they are.

You should now start up the simulator, then build this project and run it. You will see this:

Default application

Not very exciting, but this is your first Surface application! You can move the mouse and see a finger moving across the screen! Again, not very exciting but this is only the first step….

In Visual Studio you can now stop the application and you will return to the editor.

Surface Controls

In the toolbox you’ll find the controls needed for developing Surface applications. These fall apart in three categories:

Tool box

The first category are the ‘default’ WPF controls that have been altered for Surface. You will recognize these controls as they are ‘normal’ WPF controls but they additional capabilities. They are usually larger than the normal controls to allow fingers to use them (a finger is less precise than a mouse). Also they support multi-touch (imagine two fingers pressing the same button: what happens when the first one lets go?)

These controls are:

  • SurfaceScrollbar
  • SurfaceButton
  • SurfaceCheckBox
  • SurfaceContextMenu
  • SurfaceInkCanvas
  • SurfaceTextBox
  • SurfaceMenu
  • SurfaceMenuItem
  • SurfaceSlider
  • SurfaceListBox
  • SurfaceListBoxItem
  • SurfaceRadioButton
  • SurfaceScrollViewer
  • SurfacePasswordBox

As you can see, the names are the normal names of the controls but prefixed with ‘Surface’.

The next category are the controls that are specifically designed for Surface. These are:

  • ElementMenu
  • ElementMenuItem
  • LibraryBar
  • LibraryBarItem
  • LibraryStack
  • LibraryStackItem
  • LibraryContainer
  • ScatterView
  • ScatterViewItem

I will go deeper into these controls in my next post

The last category, consisting of just one control, is the category with the non-visual controls. For now, there’s only one of them: the TagVisualizer. This non-visual control can recognize the tags placed on the screen and take action on this tags.


The development of your application follows the same patterns as with any WPF application. You create a window and place the controls on them. Of course, with Surface you have to take into account the special nature of the platform (360 degrees user interface, no notion of a single user, etc). Next to that, you cannot change the size of the main window: this should remain 1024 x 768. You also shouldn’t use popups or move to different screens, the application should live in one window only. But technically speaking there is little difference in developing for Surface compared to normal WPF development.

In the next post I will go deeper into the various controls.

Tags van Technorati:

Print | posted @ Thursday, September 17, 2009 10:36 AM

Comments on this entry:

Gravatar # re: Developing for Surface, part I
by Ciara at 10/12/2010 1:14 PM

Basically, WPF isn't strictly a game-related technology..Whereas, XNA is a game technology.I would say that XNA is probably your best choice, regardless of what kind of game you are planning on building.
Post A Comment