Windows Store Development–Retrospectives (Part II)

Back to Part I

imageWhat If My Requirements Don’t Fit Into The Windows Store Application Constraints?

There are cases where specific application requirements don’t fit into the Windows Store policies. For example, an application could need to run in desktop mode, require custom Windows Services running in background and have no touch interface support. That’s a very strong indicator that such application is not supposed to be Windows Store style app at all. Attempting to “force” an application with so specific requirements into the Windows Store model will likely generate an application that isn’t really Modern, doesn’t feel like it, is not consistent with the experience of other Modern applications and might even not be able to provide the desired level of functionality.

Of course this application can still take some of the good insights from the Modern style application world (i.e. better UI design, touch input friendly). In some cases an application can even be split into parts where a small subset can perfectly be a Windows Store application. Although, if your requirements go beyond what is allowed by the policies and constraints of a Modern style application the message is clear: You likely should be building either a Web application (which can also inherit good UI practices from Modern style apps) or a traditional Windows desktop application. And this is fine! Not every application that exists in the desktop computer world is supposed to be transformed into a touch friendly, Modern style app. Yes, some applications can easily go across both worlds but this may not be the case for all of them. An advanced 3D/CAD design and animation application for example is one where there may even be space for a simplified Modern style version of it but typically it will still require the full featured application which will have several toolbars, menus, information boxes and windows on the same screen. A standalone tablet with a small touch screen wouldn’t be able to provide the same level of functionality without a docking station plugged into a mouse, keyboard and additional monitors, although it could well provide a Modern style application with a subset of them, as it happens with Microsoft Word for Windows Phone which has far less functionality than the desktop version but fits the form-factor-induced experience perfectly.

Many tablets currently available in the market are showing that the functionality a tablet can provide today is nearing a desktop computer can do. Windows 8 reachs far more areas than what today’s tablets are able to do but still there is space for traditional Windows 8 desktop applications. SQL Server Express, Visual Studio, AutoCad, PhotoShop and others are still likely going to exist for a long time as desktop applications since they work well that way and would likely have to take functionality away in order to be converted to Modern style apps. And here’s the great advantage of this platform: It supports not only both options, but also goes beyond (i.e. Xbox, Windows Phone and other devices).

Windows Store Apps : Decisions, Decisions

The first question that developers ask in any design discussion is which approach to use: XAML/C# or HTML 5/JavaScript.

Before attempting to answer whether XAML or HTML5 is the preferred option for specific Modern style application development projects, it is important to clarify that these options aren’t mutually exclusive. There are significant overlapping, important differences and space for coexistence as well as interoperability between both. Both can provide rich UI capabilities, can call .Net class libraries and support touch interface. Both can be packaged as Windows Store apps and make use of some Windows APIs. The following topics will describe in more details the points to keep in mind when considering each.

    Combining XAML and HTML

    Windows Store applications can be architected in different ways. The diagram below shows how different layers fit into the XAML and the HTML5 options. It is important to observe how WinMD[1], .Net class libraries and several external resources (Web Services, Win32 APIs, COM+, etc.) can be reused independently of the UI technology chosen making the XAML versus HTML 5 decision far less important.



    [1] WinMD is a way of compiling .Net libraries with a more strict set of restrictions, allowing JavaScript, general Modern and background tasks to call the same code libraries.

As the diagram above demonstrates, the same .Net code can be used across XAML and HTML applications by calling WinMD libraries. Also, XAML applications can host HTML by using a web control. This bases the decision of using XAML or HTML more on the skills available on a development team.

It is important to highlight that the diagram above only describes the Windows 8 native (locally deployed) applications and not the web/http scenarios where only the browser is required at the client. For those, little has changed and the challenge remains on how to deal with the browser capabilities of different devices and versions of the OS. The added complexity is how to design web pages that are “touch friendly” and can be navigated easily by using either a mouse or a touch screen.

What About Skill and Code Reuse?

In order to help clarifying some myths and truths around code reuse from different technologies into Windows Store applications, I will layout some of the aspects of porting code to/from some of these platforms. But that’s for Part II Smile. We will also touch on choosing between HTML and XAML.

Update: Part II


free/trial tools for developers


  • Think blue sky with Azure free trial




Skip to main content