24

We can’t just leave our customers that are not able to upgrade to windows 8 for a long time in the larch. However there is demand for a “tablet”/”touch” version of our app.

So how can we support both touch with Metro on Windows 8 and our current customers from a single code base?

When WPF come out, after a lot of “Pushing” Microsoft saw since and make it work on Windows XP – has anything like this been talked about for WinRT.

(I am not expecting any solution to work on XP, as XP support is being wound down.)

See Also: Can the ARM version of Windows 8 only run Metro (WinRt) style apps?

Community
  • 1
  • 1
Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
  • 3
    Regardless of any solutions, it's pretty hard to come up with a single UI that is convenient to use with both mouse/keyboard and touch. Generally speaking, even if you could use the same UI framework, you'd still need to significantly change UI for the two interaction models to be convenient for the users. E.g. with touch, swipe is a very natural and convenient gesture to change views, while with mouse/keyboard you want some kind of tab switcher. – Pavel Minaev Sep 15 '11 at 09:04

5 Answers5

17

The best answer is that you do not want the same application to run on Windows 7 and Windows 8 Metro style. The UI that works best for mouse and keyboards (windows 7) will not work well for a touch-first presentation and visa versa. It is important to re-imagine the UI for the two different worlds.

That said, you have 2 options if you want to share a lot of the code: 1) Write it largely in JavaScript/HTML5. This will let you re-use many of the assets (especially the business logic parts). 2) Write it in (desktop) Silverlight. The Silverlight XAML is closest to Windows XAML. WPF is further away and will require more re-work later.

In either case, you should look at and follow the principles used when writing cross-platform code. Understand the platform dependencies and isolate them behind indirection boundaries. You want to localize all of the code that will have to change. For instance, you don't want calls to the .Net System.IO.File APIs which you know will have to change to Windows.System.Storage calls being scattered throughout your code. Instead, you want it localized in one function that can be modified later.

Steve Rowe
  • 19,411
  • 9
  • 51
  • 82
  • 3
    I would emphasize that separating as much logic as possible into a cross-platform library is important. This way you can add support for different front-ends (Metro, traditional Win32 UI, etc.) in the future while sharing most of the code. – James Johnston Sep 26 '11 at 19:18
  • If only someone would tell Microsoft this. They seem to be pushing the same Start Screen interface on both types of users. :-) – Leo Davidson Nov 24 '11 at 10:08
  • 1
    Steve does a good job spelling out some UI technology options. If you are choosing .NET, then portable libraries is also an option for your business logic, and buys you a little more assurance about the same codebase for both platforms because it compiles to the same platform agnostic binary: http://technet.microsoft.com/en-us/library/gg597391(v=vs.110).aspx – Theo Yaung Apr 17 '12 at 08:35
4

The only way I can think of is to implement your application in HTML5/CSS3/JS, and avoid using WinRT APIs inasmuch as possible - this may be feasible depending on what, exactly, your app needs to do (e.g. portable 2D graphics is easy with HTML5 canvas).

Then, for Win8, you'll package this as Metro web app. For Win7 and below, you write a simple app that embeds your browser of choice (not IE9, since it doesn't work on XP - so Firefox or Chrome) with all chrome hidden, and loads your HTML5 app inside that embedded browser.

Pavel Minaev
  • 99,783
  • 25
  • 219
  • 289
4

As others have noted, you would not want to have exactly the same application working in Win8 Metro and Win7 / Vista Desktop. If you structure your application properly, using a suitabel design pattern, it is possible to share quite a bit of code between the various version that you would require. For the Win8 version, you will be using WinRT, for Win7 / Vista you have a choice of Silverlight or WPF.

I have published a couple of articles that demonsrate how this can be done, they include quite a bit of code as well:

ColinE
  • 68,894
  • 15
  • 164
  • 232
2

It is unlikely that we'll see Microsoft push the Metro-style application framework back to past releases due to the level of re-architecting that went into Windows 8.

I agree with Zac on this point. It appears Microsoft is definitely pushing both the technology and usability forward with the introduction of Windows 8 (and Windows Runtime).

The Metro UI is a different UI paradigm. If your using the current Win32 controls (which includes WPF controls), your application will look really dated in Metro. The only way to fix that is to re-implement the UI (your View classes in an MVVM design) using Metro controls. However, C# and majority of the .NET APIs are first class citizens in this new environment. The rest of your application should be fine.

As you already have what I assume a rather large application your best solution would be separate your view from your model-viewmodel. Then you can continue to develop both Windows 8 Metro full-screen touch-friendly awesome interfaces and the "classic" window interface (what we have done for the last x number of years). With good separation, design, and an excellent source control solution (i.e. Perforce) you will able to share a lot of the code base.

In addition to the answers given to your recent question on Windows Runtime Bill Wagner (one of the many C# bloggers that I follow) has posted summary on WinRT and managed languages conference sessions; it is an good read and recommended if you have a few minutes. One of the things that his summary clarified (in the FAQ at the end) was that the future of .NET as the branding for the framework we use is going to be replaced with Windows Runtime.

Another piece from Bill's blog post:

Some of the .NET APIs are changing for WinRT. I don’t have an exhaustive list, and I’m not sure there is one yet. Other APIs are not exposed via WinRT. (They are still available as .net APIs, just not as Metro / WinRT APIs.)

Community
  • 1
  • 1
Dennis
  • 20,275
  • 4
  • 64
  • 80
1

It is unlikely that we'll see Microsoft push the Metro-style application framework back to past releases due to the level of re-architecting that went into Windows 8.

Like Pavel said, if you kept your application from using as much of the WinRT libraries as possible, it is possible but then again, you're now building a regular web app.

Zac Brown MSFT
  • 405
  • 2
  • 7