We've already learned quite a bit about code reuse and strategies to keep costs in check in the previous articles in this series: we've created a Silverlight web & OOB client, we split up our code in modules to enable them to be loaded on demand & reused by other clients, and we've created a Windows Phone client, in which we focussed on reuse of skill rather than reuse of XAML & code - but we could still share some common code through the use of a Portable Class Library, and of course: our service layer through its REST endpoints.
As you might have noticed, an important distinction we try to make in this article series is the difference between what can be reused and what should be reused. That will become even more obvious in this article: we're going to add yet another type of client: a Windows 8 Store Application.
Why would we want a Windows 8 Store Application?
Windows Store Applications are vastly different from what we've built up until now. There's a new set of design guidelines to confirm to, there's a new CLR these apps are built against, there's quite a few new coding principles to adhere to, … All in all: a lot of work if you're new to this. So why would we consider a Windows Store Application?
One way to answer this question is by looking at the added value of these apps and the market opportunity we get as developers - a good blog post that sums up these can be found at MSDN.
What should we offer in this client?
This is one of the first questions we should ask ourselves, as quite a bit of the development cost will depend on the features we want to offer, or rather: on what we can use to build these features with.
Let's have a look back at our full-blown Silverlight client: we use this one for quite a bit of data input - and validation on that data, client-side (next to server-side, of course). Thing is, at this point in time, Silverlight is a mature framework, which includes building blocks to make it easier for us to achieve solutions to some common concerns. WinRT, or what’s offered by WinRT, isn’t yet.
For example, thanks to WCF RIA Services, we've got a framework that tackles a very important concern for data input apps: validation. Write validation rules on the server, and they're generated on the client. Next to that, the Silverlight controls have built-in functionality to listen & react to this type of validation, through the INotifyDataErrorInfo interface. This combination results in almost out-of-the-box validation.
For Windows 8 Store Applications, this isn't the case: at the moment, there isn't anything resembling WCF RIA Services available for these types of apps (and we don't know yet if something like that will be available in the foreseeable future). Furthermore: the INotifyDataErrorInfo interface is completely absent for Store Applications - in fact: any kind of validator is absent.
And there's more: a lot of other components we could use - like third-party components for graphs - aren't available either, or are in an initial state. Of course, this is quite normal: after all, at the time of writing, Windows 8 isn't available to the general public yet. All this will get better, but it will take some time.
We should keep in mind that the framework for building Windows 8 Store Applications is very much a "v1.0"-framework - a bit like what Silverlight was when Silverlight 2 was made available. Out of that follows that if we would want to support features that aren't built-in, or for which there aren't any mature helper frameworks available, it will take a lot of time, and thus cost a lot of money.
If we want to keep costs in check, the above should be one of the first things to take into account. When developing software, it's not using the framework as it was intended to build the app that heightens the cost, it's often (mis-)using the framework or trying to add features that it isn't ready for that causes that.
Should we reuse the UI? After all, it's built in XAML, right?
Windows 8 Store Applications come with their own set of UI guidelines, which result in a UI that's quite different from what we've done in our initial Silverlight application. When you're building a Windows 8 application, you're building an application that should easily be controllable using touch - typically, you'd have larger buttons, more whitespace, less reliance on tooltips, … But that's not all. Navigation should typically be achieved hierarchically, or through a navigation bar - different from what we're used to. A lot of commands (the non-essential ones) should be moved to the command bar instead of being on-canvas (as they are now). And then there's charms: to ensure a consistent experience across applications, a few common features of apps should be implemented through the charms bar instead of in the application itself. Searching through the data of our application should be done via the Search charm. If we want to share data to other apps, we should use the Share charm. And our application settings should be accessible through the Settings charm.
Another thing to keep into account is the fact that we're now looking at an application which can be snapped to the left or the right of the screen, which means we have to provide a snapped view for the pages in our application. Optionally, we could also provide a portrait mode next to the default landscape mode.
These are just a few traits that make for a good Windows 8 Store Application, and if you think about this, that's quite a lot of change from what we're used to. But it makes sense: ensuring your app confirms to these guidelines ensures a consistent experience for the end-user, no matter which app (s)he is using.
If you're new to this, you might want to check out the guidelines on this, or have a look at a few case studies at MSDN.
Obviously, it's clear that we shouldn't reuse our current UI. But can we?
Unless you've been building a very simple application: no. The XAML used for Windows 8 Store Applications contains quite a few differences from the XAML used in Silverlight, WPF or Windows Phone: from controls that aren't available or have been replaced by better-suited controls (eg: a ListView instead of ListBox), to some more fundamental concepts like binding changes, supported interfaces, …
There's a great overview available on porting Silverlight or WPF XAML to Windows Store XAML at MSDN.
What about our ViewModels?
Technically, we could think we could reuse most of our ViewModel code from our Windows Phone application. That application uses the REST endpoints of our service layer, which is exactly what we'll be using for this client. However, Windows 8 Store Applications rely heavily on async & await, or, in fact, the Parallel Tasks framework (more on this in the next article) - you won't find the typical completed handlers we've got in Windows Phone to execute code when our async service call returns; instead, we should use the async/await keywords.
Next to that, due to the fact that a View is implicitly connected to a ViewModel, and the fact that we've concluded that reusing the UI isn't a feasible option (if only for the very different design guidelines), we cannot technically reuse our ViewModels, and we should not either, as the use cases will be implemented differently.
Wait a minute. Is there anything left we can reuse?
Well, of course there is. We've used WCF RIA Services for our back-end services, and these services can be consumed through their REST endpoints, much like we did for our Windows Phone client. Next to that, the Portable Class Library project template supports Windows 8 Store Applications, so that's something we can reuse as well. And of course, there's knowledge & skill reuse.
Luckily, it's fairly easy to build Windows 8 Store Applications. The framework might not support everything we're used to (yet), but the concepts it does support are is thought-out quite well. In the next article in this series, we'll effectively start building our Windows 8 client, keeping into account the questions we've raised and answered in this article.
About the author
Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET applications, mainly XAML-based, and the solution owner for Windows Store Apps. His main focus lies on all things XAML, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a XAML enthusiast, he's a regular speaker on various national and international events, like Microsoft Techdays in Belgium, Portugal & Finland, NDC, Community Day, VISUG, ... Next to that, he also authored two Silverlight books at Packt Publishing, of which the most recent one is the Silverlight 5 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on XAML, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.