Share via

Windows Store Development–Retrospectives (Part I)

  • Article

imageBased on work from Mat Velloso, Sr. Software Development Engineer

Introduction

With Windows 8 the primary user interaction model gradually begins to move from mouse and keyboard to a touch-first experience. Windows 8 also delivers a new application execution environment, changing the experience of many of today’s applications:

  • Coexistence of large desktop applications along with many immersive task-based UI’s
  • Move from configure/personalize on every device to configure/personalize once with roaming enabled through the Cloud
  • Users configure and control their own experience

Windows 8 and Windows Phone 8 represent a fundamental change of vision where the consumer market (and therefore consumer-based usage scenarios) has more influence over the application design and experience. Consumer designs are changing the corporate IT world to reflect more and more on the Consumer World. This is known as the Consumerization of IT and has some of the following principles:

  • Simplicity and task-based over a complex range of functionality
  • Intuitive discovery experience over training requirements
  • Mobile devices over high-end desktops

Windows 8 also delivers Internet Explorer 10 which adds touch based functionality together with HTML 5 support. Those new features enable very new and rich UI experiences, therefore understanding such changes introduced by Windows 8, IE10 and modern UI is crucial in order to prepare for this new way of creating and thinking about application design.

Constrains and Trade-Offs

In Ruby on Rails, the term “Rails” relates to “convention over configuration”. Some freedom is traded for better productivity and consistency. How does that concept apply to Windows Phone 8 and Windows Store applications?

Compared to Windows Mobile 6.5, Windows Phone 8 imposes more constraints on the application development. How much memory can be used, how tiles are designed, what behavior the back button must have within the application, what background tasks are allowed to do, data/network usage and user privacy are just some of the areas with clear, specific policies with which the developer has to comply if the application is going to be submitted to the Windows Phone 8 Store.

The trade-off is clear: Stricter policies in exchange of a greater user experience (consistent experience across different applications, longer battery life, better performance, no “surprises” with data usage bills, etc.). It improves the overall experience and the quality of the applications built for that environment.

Windows 8 introduced similar requirements for Windows Store applications. Some of them come simply from the application model (i.e. the security model and what resources the application is allowed to access) where others come as part of the certification policies for the Store. This can generate some pondering at first, but developers need to keep in mind the reasons behind those policies.

For instance, an application in the lock screen is only allowed to use 2 seconds of the CPU every 15 minutes. Compared to a traditional Windows service where pretty much anything can be done, no matter whether reasonable or not (i.e. a badly developed Windows service can take over the whole CPU and memory available) this policy is far more restrictive. The developer must keep in mind the Windows Store app might be running on a tablet which could have far less CPU power and more dependency on battery life, so it must coexist in harmony with the application ecosystem and the hardware characteristics. These limitations are not new. Someone developing an application for a Windows tablet or a netbook would have to already consider those. The main difference is that those restrictions are now clearly documented and owned by the developer rather than experienced by the user.

From the developer point of view, there is another important benefit of such constraints: They often work as “rails”, taking away some plumbing and design concerns, allowing quicker build and release of applications.

For example, let’s look at the Windows installer. In a traditional application model, there are several different ways of packaging and deploying an application. Often developers don’t even create a Windows installer package but instead end up writing several custom scripts. One could be using ClickOnce where others could be using several different packaging/deployment tools for their applications. Many don’t even observe the use of Program Files folder and deploy their applications under the root folder. Others violate some rules and update DLLs under Windows or System32 folders. Developers not only spend a significant amount of time creating those installation packages but also risk causing consistency issues and might even damage other applications or even the entire OS when doing so. A single and simple manifest based application packaging process is clearly beneficial here, but again this approach might not be an option to some of the application development requirements out there. SQL Server would be a good example of that, where just installing a Windows Store app wouldn’t cover the services, file storage structure and other lower level OS access APIs required by such a database server.

What if my requirements don’t fit into the Windows Store application constraints?

There are cases where specific application requirements don’t fit into these 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. […] But that’s for Part II Smile. We will also touch on lessons, skills reuse and code migration.

Update: Jump to Part II

THE TOOLS DEPARTMENT
free/trial tools for developers

image

  • Think blue sky with Azure free trial

image

image

image