Now that the Windows 8 release preview is out, a lot of developers are beginning to experiment with what they can do with Windows 8.
Unsurprisingly the focus for many is on Metro-style apps that can run across everything from desktop to slate. There are a number of ways to develop these apps but C# is a good place to start if you have developed on the Windows Platform before and like working with managed languages. While Metro offers fantastic flexibility, it does require that we get our heads around some new concepts. So for this article I thought I’d cover some of the areas I talk about at events and point you towards some useful resources to get you started. If you want to get more hands on experience and guidance on developing Windows 8, come along to a UK Windows 8 Developer Camp.
I’ve selected 5 things that I think you should start exploring:
Layouts and Views
When you’re producing an operating system without a specific device in mind, you need to make sure it’s flexible. After all you don’t know whether the user will be viewing the app on a PC with a large 27inch screen or a tablet with a 11.6 inch screen and a high pixel density. This can be a challenge for developers as they need to consider how their application will look across multiple devices in various orientations and in specific states (like when your app is snapped alongside another application).
In the C# world we solve this problem using the Visual State Manager. The following article will help you understand how to make sure your app looks great whatever device it’s used on:
There’s lots of common functionality built into Windows 8 that you can take advantage of as a developer. You take advantage of this functionality by using Contracts. If you use the Search contract then a user will be able to search your app by swiping their finger over the right hand side of the screen and bringing up the search charm (the charms are a set of buttons that are always available to the user regardless of what app they have open that provide common functionality) As you’d expect, this allows users to search within your app. However, it doesn’t end there. Because of the way contracts glue everything together, it will also allow people to search within other apps too – or across the web for that matter.
Users can search from one single place, regardless of the app they are using or where they are in the system.
Traditionally, when you’re looking to add sharing functionality to an app, you need to choose up front which other services you want to use. So you might decide that you really need to let users share with Facebook and Twitter and then code that in. Of course things change over time – who knows what kinds of sharing will be popular in future?
The share contract is a pretty cool way round this issue. If your app in a Share Source then it will be able to share specific content types with any app on the system that supports accepting those content Types. Apps that accept specific content are called Share Targets.
So you could share an image from your app with any app that is capable of accepting image files. As a developer you don’t need to know what app you are sharing with, you just code to a contract and Windows 8 becomes the middle man that manages the sharing.
You can share specific content types; however it is also extensible so you can define your own content types too.
A lot of research has gone into Windows 8. Specifically, how people like to interact with an operating system on various devices. So the team has looked at desktops, laptops and tablets, and how people work with a mouse or pen or touch. In fact every which way someone might use any individual element.
All this learning has then been bundled up into the default set of controls that are included in the SDK. It means that developers don’t have to face the complexity of re-learning everything to make their apps more user-friendly. They simply get best practice elements right from the start.
Adding controls and content shows a whole bunch of resources around controls.
A lot of the APIs on Windows are asynchronous. The stated guideline is something like:
If the API is likely to take longer than around 50ms to execute, it is asynchronous
And so you will find that any API that accesses the network or the file system is asynchronous. This is designed to avoid producing apps that become unresponsive.
In some instances Synchronous methods have been replaced with asynchronous ones and these trip-up a number of developers, particularly those familiar with C#.
Two great articles which explain this well are:
So that’s the 5 top areas where I think you will need to spend some time, if you are developing Windows 8 apps for the first time. If all of this seems a little overwhelming why not come along to one of Microsoft’s Windows 8 camps. Windows 8 Developer Camps are free, fun, no-fluff events for developers, by developers. You learn from experts in a low-key, interactive way and then get hands-on time to apply what you’ve learned.