views:

166

answers:

3

I'm working on a WPF application, and I'm curious about what it would take to rewrite this application to a Surface application if we want to control it through multitouch some day.

Is it likely that we can reuse big parts of our WPF application and transfer it smoothly to Surface, or is Surface completely different, and we probably have to write a completely new GUI for Surface? Or can I actually use WPF applications on Surface? As you maybe can tell I don't really have a clue at all regarding Surface - so please tell me anything obvious too!

We do what we can to model the application with good separation between the View and the business logic - using the MVVM pattern etc. But do we need to build a completely new GUI for surface?

+1  A: 

WPF is the primary platform for Surface development, right now.

The Microsoft Surface Blog has a great article on WPF resources related to Surface development.

Reed Copsey
+1  A: 

If the app has used only basic WPF controls then ideally the change you might need to port ot Surface is very minimal. Just need to replace all typical WPF controls to corresponding Surfacecontrols and add appropriate Contact events if you already did some Mousevents in the code.

Ofcourse based on the special MultiTouch experience you may need at Surface the XAML Styles and LayOut can be quite different, But when you follow proper MVVM you dont need to change any C# code as well as the over all UserControl structure of the project. So make sure to make the projects as View and ViewModel so that you can have a SurfaceView and WPFView projects referring the same MVVM dll.

Jobi Joy
+2  A: 

If your goal is simply to add multi-touch to a normal desktop application you should really be looking at .NET 4.0 in Windows 7. Doing that you can start with your existing application and just add on any multi-touch features you find useful.

If you do go to Surface, the primary changes you'd see in your code if doing a direct port would be changing all of the built-in input controls to the Surface versions (i.e. Button to s:SurfaceButton). This needs to be done to support Surface's Contact inputs, which don't activate things like Button.Click on the standard controls.

There are a few more important concerns with Surface applications that you can't really get a feel for just using the emulator on your desktop. First is the multi-user experience, including not only the huge number of simultaneous touches it supports, but also the multi-directional orientation of the UI. Since the Surface is a horizontal screen users can come at the application from any side and the application itself can also be flipped vertically depending on which direction the user starts the application from. This can require a lot of thought around how the features of a desktop app need to be reworked. Surface also has a fixed resolution of 1024x768 which can also make for awkward transitions from dynamically sized desktop apps made for large screens.

John Bowen