On the tiles

by Tim Anderson

Microsoft has released a new version of Windows, but what does this mean for developers? Tim Anderson finds out.

HardCopy Issue: 57 | Published: September 1, 2012

Windows 8 is here: the release is already in the hands of developers and enterprise subscribers, and it will be arriving pre-installed on PCs, laptops and tablets from 26 October 2012.

The first thing to note, if you haven’t already, is that this new version has a dual personality. The classic Windows desktop remains, although the Start menu has been replaced with a full-screen tiled affair that looks like a giant version of Windows Phone 7. That same Start page is the access point for the other side of Windows 8, a new platform called the Windows Runtime (WinRT) which is optimised for touch control, security, and easy app installation from the Windows Store.

It is WinRT that is drawing much of the attention because it is clearly targeted at tablet devices, such as Microsoft’s own Surface, which will compete with Apple’s popular iPad. But before we look at WinRT, let’s find out what’s new on the desktop.


Developing for the desktop

You might assume from its appearance that developing for Windows 8 will be much like targeting Windows 7. In general that is the case, but there are significant differences.

For a start, Windows 8 boots into the new Start screen, not the desktop. One consequence is that desktop apps that run automatically on log-in no longer do so in Windows 8. Rather, they will run when the user first opens the desktop. The current Windows 8 Desktop App certification requirements, which are the equivalent to the Windows Logo requirements for Windows 7, state clearly that “Your app must avoid starting automatically on startup.”

Microsoft is also taking a firmer stance on security issues, requiring that all executable files are secured with Access Control Lists (ACLs) and be compiled with switches for safe exception handling, no data execution and randomised address space layout.

WinRT notification API

You can use the WinRT notification API from desktop apps, and create new-style notifications that work across both Windows 8 environments.

Conforming to the certification requirements is not necessary for your application to run. Most applications that worked under Windows 7 still work on Windows 8. However certification is necessary if you want your desktop app listed in the Windows Store.

Another key difference in Windows 8 concerns notifications. If the user is in the WinRT environment, notifications shown in the desktop notification area are not visible. There is a new notification API which works across desktop and WinRT, but you must code for it specifically.

The notification API is part of WinRT, but parts of it can also be called from desktop apps. That may sound surprising, but Microsoft does intend that some WinRT APIs are used from the desktop and they are documented accordingly.

Windows 8 ‘toast’ notifications, as they are called, show in a temporary window that appears at the top right of the main screen. In order to use these you need to retrieve a built-in template from the ToastNotificationManager, populate it with a simple XML string and an image, and optionally attach event handlers to respond if the user clicks or taps the toast (‘Activated’) or it is dismissed (‘Dismissed’). Then you can show the notification with the CreateToastNotifier method. Notifications must supply a valid AppUserModeId, which is a unique ID string set as a property of a Start menu tile. Windows 8 notifications do work nicely, improving on what was in Windows 7, so it is worth adding support to appropriate desktop applications.


Developing for WinRT

However the heart of Windows 8 is the new WinRT environment. Apps written for WinRT will only run on Windows 8, but have several advantages: they are easy to install, remove and update thanks to the Windows Store; they are sandboxed and checked by Microsoft before submission to the store, improving security; they run on both Intel and ARM versions of Windows 8 and are optimised for touch control. WinRT apps can also use Contracts, a safe way for apps to interact with other and with the operating system.

If you are coding private apps for your business then you can deploy them without going through the Store using PowerShell or pre-installed on a Windows image. Users of Windows 8 RT devices, which are based on the ARM processor, aren’t able to join a Windows domain. Instead they can install apps from a custom internal store called a self-service portal.

Several pieces need to be in place before you can develop for WinRT. First, you need Windows 8 itself and a version of Visual Studio 2012. Next you need a free developer licence, which lets you test and debug apps on your machine.

If you want to deploy apps to the Windows Store, you also need a Store licence which currently costs $49 for individuals or $99 for companies. In addition, Microsoft takes 30 per cent of revenue from paid-for apps, falling to 20 per cent if revenue exceeds $25,000 over the lifetime of the app.

With those pieces in place, you can get started with development. Your app gets a page or canvas on which to draw its user interface. Normally this runs full-screen, though it can also be ‘snapped’ to fill only a narrow part of the screen, or can run alongside another snapped app that fills the larger part of the screen.

Visual Studio 2012 screenshot

Choices for a WinRT app in Visual Studio 2012

A user interface in WinRT is designed using XAML, which is the same layout language used in Windows Phone, Silverlight and Windows Presentation Foundation. There is a basic XAML designer in Visual Studio, or you can use Blend for more sophisticated designs. Fast graphics are available through DirectX although this is only directly available to C++ code. XNA, the .NET wrapper for DirectX, is not available in WinRT.

WinRT supports essential user interface elements such as menus and dialogs, but they are adapted to be touch-friendly. The main menu is an app bar, which appears when a user right-clicks or swipes a finger from top or bottom of the screen. You can also use context menus, summoned by right-click or tap-and-hold. You can use message dialogs which fill the entire width of the screen, and fly-out dialogs for confirming or cancelling actions.

Some standard features are accessed from the ‘Charms’ bar at the right hand side of the screen. This includes settings, search, and sharing. You can add code to your app to handle what happens when a user activates one of these charms.

Contracts are a mechanism by which apps can safely interact with each other and with the operating system. For example, the Picking contract lets you ask the system for a file such as a photo or document. Apps that handle photos can declare that they support the file picker in their XML manifest. When you activate the file picker, all apps which support the contract are available to the user. Alongside Picking, Contracts exist for Play To, Search, Settings and Share.

Extensions are similar to contracts in that they provide a standard way to extend a feature of Windows. For example, the AutoPlay extension lets you register your app to handle auto play of specified types of content.


Your coding options

There are three different paths to WinRT coding: JavaScript and HTML, .NET with C# and Visual Basic, or C/C++. Microsoft has given each language what it calls a ‘Projection’ into the WinRT API. From a coding perspective, this means that the API looks like JavaScript to a JavaScript developer; like a .NET assembly to a .NET developer; and like C/C++ to a native code developer (though this last is more direct, since it actually is C++ code).

Another key point is that many of the WinRT APIs are asynchronous, so as to ensure a responsive user interface. In order to simplify the multi-threading issues, Microsoft has added Aysnc and Await keywords to both C# and Visual Basic.

The WinRT sandbox means you have to design your app carefully. The app must get data either from Web services, direct from the user, or through built-in contracts. Those used to developing in Silverlight or Adobe AIR have an advantage since those environments use a similar model. In other respects, the full power of your chosen language is available.

Test and debug for a WinRT app is a smooth experience. Visual Studio runs your app on the local machine and opens a remote desktop session in a window so you can easily debug it. This looks like an emulator but is not, so take care what you delete there!

Submitting an app to the Store involves several steps, each accessible from the Store menu in Visual Studio. Here, you can reserve the name for your app before development, and the name stays reserved for one year. You can also associate the app with the Store, capture screenshots, and create and upload your app deployment package.

Windows 8 store screenshot

The Windows 8 Store is the primary deployment channel for Windows 8 apps.

Of course it is not quite that simple, since approval for the Store is dependent on your app conforming to Microsoft guidelines. You can download Microsoft’s Windows App Certification Kit to test for any issues. Once submitted, the app will be then tested by Microsoft for technical and content compliance, with the whole process intended to take no more than a week or so.

Windows 8 is Microsoft’s most controversial release in years, and while the company has done a great job implementing its goal of a secure, touch and tablet friendly operating system, there is substantial resistance from developers who are not ready for this degree of change, or who dislike the interaction between the desktop and WinRT sides. Nevertheless, Windows 8 will be out there in quantity from Autumn 2012, and developers who get in early with strong apps will be well positioned to benefit.

The Portable Document Format (PDF), originally created by Adobe, was designed to be a platform independent file format which could hold text, graphics and images in a form that could accurately duplicate a paper layout. Created as long ago as 1993, by Adobe’s co-founder John Warnock, it was a proprietary standard until Adobe released it in 2008, when it was also adopted as an ISO standard.

Since then, Adobe and other software makers have worked hard to improve the way PDFs can be created and to expand the uses to which they can be put. The ability to save a document in PDF format has been added to many applications, for example, including Microsoft Office from version 2007 SP2 on. Other forms of the PDF standard, such as PDF/A and PDF/X, have also grown up to address specialist needs.