Developing Windows 8 Applications

Win8 Icon

Solidsoft published its first windows 8 application to the store earlier this year, Rest Azured which is an application to help Azure Administrators monitor their cloud services. I was involved in that project from conception to completion and found it to be an interesting but somewhat time consuming experience to switch from my day job as a Web developer to being a Store App developer.


It’s a big change. With Store Apps, the user is all powerful and your application is sandboxed, resource-limited and liable to be terminated by the user or possibly by the operating system at any time.


If you're going to get on with windows 8, you've got to know how it ticks.

Windows RT, Windows Runtime, WinRT – what’s in a name?

Microsoft’s Windows 8 terminology doesn’t help matters when learning the platform. What is WinRT? How does it differ from Windows RT? How does that differ from Windows 8? Is Windows runtime the same as WinRT or Windows RT?


Maybe there’s a nice diagram to make all this clearer?


Well don’t look at the Windows 8 architecture diagram if you’re after clarity. Microsoft imply in their architecture diagram that WinRT sits on top of the kernel – actually WinRT is just a COM object layer on top of another COM object layer (Win32). Here is a more accurate diagram.


There are lots of hard rules when developing with the Windows Runtime, e.g.

  • what you can access on the device
  • using contracts to share data with other apps
  • when you can do something in a background job


And several other “best practices” which can be easily confused as rules, e.g.

  • when and how to use the app bar
  • implementing the search charm code
  • make it look metro modern


When you want to publish your masterpiece to the store, you may find there’s a trade-off between making your app stand out from the rest and making sure your app generally conforms to Microsoft’s guidelines/rules on user experience.


Bear in mind that the accreditation process isn’t draconian, you can bend some of the design rules, if overall it gives the user a better experience.

Windows 8 Apps backed by Azure.

The more I work with Windows 8 business applications the more I realise that it’s quite a common scenario to have the application backed with a corresponding cloud service API.


The app then doesn’t need to do much heavy lifting, and it can work with the global data it often needs. You can farm things out to a web service and use that to orchestrate the hard work and callback with the results when finished.


I say callback because you don’t want to block the UI thread – more on that in a minute, but basically if there’s something time consuming to do, like call a web-service or read data from disk, then the UI shouldn’t have to wait; its job is to look pretty and respond to the user quickly thus freeing up the UI – “Fast and Fluid “ just as Mr Sinofsky would have liked.


Once you establish a cloud service for your application you can also use it to send updates to each device using WNS – the Windows Push Notification Service. This makes updating live tiles or sending toast notifications simple and is simple to setup and a big win for a windows 8 application.


This is one of the features of windows 8 where you can really leverage the platform and do something you couldn’t do on the web.


Windows Azure mobile services (WAMS) is very convenient for connecting a Windows 8 application to simple, CRUD-based logic. This is assuming you’re happy with a bit of server-side JavaScript.


You can also now use the Windows Azure Push Notification Service in WAMS – see here. If you’ve played with Node then Mobile services is very simple to pick up. Microsoft have taken away so much of the work required in persisting and accessing data that it’s scary how little code you actually need to write.


Moving on to the most recent project I’ve worked on.


Solidsoft was commissioned to produce a working prototype of a Windows 8 business application for a government client. This application will eventually replace a paper and pen process for field operators. The process is pretty much a questionnaire with a few bits of business logic to determine the flow.


Again I got to work on this from day one to completion. This application varied greatly from others, not least because it was very UI-centric. Previous projects had been more about APIs, background tasks and notifications.


This prototype was all about the user experience. Two of us worked on this mini-project, one developer (me) and a UX designer. This is how it went:

Git for TFS.

First thing we did was setup our project control and version control. We used Git for source control and hosted it in the cloud with TFS. This worked really well and allowed us to commit changes locally on a regular basis.


Visual Studio and TFS did a great job of orchestrating merges from pull operations and encapsulated all the main Git functionality within its UI really well. We were able to do everything Git-related within visual studio once we’d installed the VS2012 plug in.


It only took minutes to setup the cloud-hosted TFS repository for our project and it worked so well that we were able to concentrate on the project and not really worry about source control.


We decided quite quickly that XAML and C# were the tools for the job. I find XAML slightly scarier than HTML, but when it comes to business code, C# seems so much easier to me than JavaScript. There is something reassuring about business code and the declarative nature of strongly-typed objects.


Another consideration is simply that we have more .NET resource than we do JavaScript resource within the company – someone else may have to work on this code one day.


There just didn’t seem to be much benefit in us going the HTML route. Maybe if we were to write something cross platform or canvas based, like a game where we could PhoneGap it across to various other devices.


Following our first foray into Windows 8, we were already aware of the .NET libraries unavailable in the windows runtime. Actually the lack of certain libraries, or the namespace differences, didn’t cause us too many concerns. The biggest challenge for me came from adopting the best software patterns to code a store app: store apps are asynchronous apps.

Fast and Fluid. Think Async.

The latest version of C# allows you to write asynchronous code in a synchronous manner thanks to the async and await keywords and the extension of System.Theading.Task to work with the awaitable model. Although your code may be much less verbose and appear sequential don’t forget the amount of work the compiler and runtime is doing on your behalf, and make sure you are thinking asynchronously.


As soon as you have a requirement to hit the file system, or anything else which could block the UI thread, get ready to beawaiting all the way back up the call stack, but make sure you can deal with exceptions properly and don’t return void from a method declared asasync unless it’s an event handler, or unless you really know what you’re doing.


Getting asynchrony right in your application is of paramount importance. It’s actually not so much that you *can* use an asynchronous approach to your code, it’s more than you *have* to use it with WinRT.

Visual Studio and Blend.

Before we started the project, we considered the way we wanted to design and develop. More specifically we wanted to separate the development from the design and introduce a bridge between the two in the form of view models.


One easy way to split design from development is to use different tools. Design in Blend and develop in Visual Studio. This is what we chose to do, reinforcing our choice in XAML / C#.


The UX designer (no, not a web developer who’s handy with CSS, but a *real* designer) created the XAML pages, controls and visual state transitions. He worked independently in Blend without being forced to open a developers’ IDE like Visual Studio. Microsoft Blend being a feature-rich, designer-friendly tool which has the bonus of a shallow learning curve for anyone who is used to applications such as Flash, Photoshop or Dreamweaver.


That left me, as the C# developer, to deal with the less glamorous side of things: data bindings; I/O operations; event handling; conditional logic; page navigation and other aspects of the application’s functioning.


This worked really well as developers like cutting code. It’s much better than scolding XAML for not being like CSS / HTML, and dragging UI controls around on a page oblivious to design best practices. We were able to work independently, quickly and effectively, stopping every now and then to agree on view models.

The MVVM Paradigm.

So view models were to be our common currency, the glue between design and development. So how to use them?


Microsoft, through Visual Studio templates, have pushed developers towards using view models via theirBindableBase class and theDefaultViewModel dictionary in theLayoutAwarePage class. This works fine, in fact it works very well for small projects, but it’s not MVVM. I think a lot of people, especially those from a Silverlight or WPF background, assumed there would be an out-of-the-box MVVM solution for Windows 8 given the popularity for that paradigm.


There are MVVM extensions out there and we chose to use MVVM Light from Galasoft. This allowed us to largely avoid using code-behind and to create neat, separated code; but it did present a few of its own problems. Data binding a command was not simple when it was within a collection binding. This was one case where I resorted to using a code-behind event rather than a command.


Other problems were encountered trying to bind ink strokes on a canvas within a user control. Again, code-behind came to the rescue but not before hours of time had drained away. Simply, when it became difficult to use the pattern, I didn’t use it. I prefer the code smell from a little bit of code-behind usage to the stench of dogmatic adherence to a pattern.


In truth, MVVM may have been a great fit if we weren’t doing a small prototype on a tight deadline, and also if it was a little more mature on the windows 8 platform. It’s a paradigm which promotes various useful patterns. Patterns which our fifteen day prototype didn’t really warrant. I didn’t get to useSimpleIoC or the Messaging capabilities offered by MVVM Light, but it’s easy to imagine these things featuring in a large project.

Is Windows 8, great?

I’ve been fortunate enough to get a few Windows 8 projects under my belt and feel much more comfortable with its ways. The problem is I still haven’t found that killer reason to write or even use a windows 8 app over a web app. I really like the notification system but that alone doesn’t carry the platform for me. I think it will get better, Microsoft are good listeners and they seem to be in this for the long haul.


As a user, I don’t mind scrolling downwards instead of sideways, and I like lots of data on the screen. I do find that as soon as things become functionally complex, Windows 8 apps struggle. Try using its default mail app when you need to write an email while reading from another email at the same time. You can’t. I can multifunction, and I need my computer to do the same. I need Windows to have, well, windows. I’m being a bit unfair as Windows 8 applications aren’t meant to compete with the desktop and its applications, but where is the line drawn?


As a developer I like the freedom, portability and ease of creating HTML5 / JavaScript-fronted applications rather than having to write code on a restricted, proprietary platform. That being said, I’ve enjoyed every windows 8 project I’ve worked on so far and I can’t say that for all the web projects I’ve worked on.

Written by Ian Dayman at 00:00

Categories :



Comments closed