Developing a simple Metro-style application for Windows 8Kean Walmsley – Autodesk

CP1921 This class will cover the basic concepts around the WinRT sub-system of Windows 8, showing how to develop a simple, touch-enabled application that acts as a companion to AutoCAD® software. We will look at the various contracts available to WinRT developers and describe the limitations inherent in working inside the WinRT sandbox, including the need for asynchronous calls into many WinRT APIs. The sample covered—while not working directly inside AutoCAD—will extract MRU information related to AutoCAD drawings in a format that can be used by our Metro-style browser application.

Learning ObjectivesAt the end of this class, you will be able to:

Extract MRU information from the Windows Registry, storing it in XML

Understand the limitations imposed on applications by WinRT, including the use of asynchronous calls

Create a simple, Metro-style MRU browser application

Implement contracts to enable search, sharing, settings and snapping

About the SpeakerKean has been with Autodesk since 1995, working for most of that time in a variety of roles – and in a number of different countries – for the Autodesk Developer Network organization. Kean’s current role is Software Architect for the AutoCAD family of products, and he continues to write regular posts for his popular development-oriented blog, “Through the Interface” (http://blogs.autodesk.com/through-the-interface). Kean currently lives and works in Switzerland.

kean.walmsley@autodesk.com

Developing a simple Metro-style application for Windows 8

Introduction

Windows 8 has recently been released to a great deal of interest around the globe. It has been branded – and this is in some ways backed up by the alleged $1 billion marketing spend around the launch – as the most ambitious release of Windows ever. It certainly presents a very different UI paradigm to its users – something for which Microsoft has been both praised and criticized, inevitably – while also maintaining a strong focus on running legacy (now termed “desktop”) applications.

Let’s start by taking a look at the Windows 8 Start screen:

The screen contains colourful – and actually very informative – tiles that are clearly targeted at touch-centric, mobile devices.

Devices that specifically target the Windows RT sub-system will run on both traditional Windows 8 machines (with Intel processors, which means they can run WinRT apps as well as traditional desktop apps such as AutoCAD) and on the new ARM-based devices such as the Microsoft Surface tablet and Windows Phone 8 handsets.

In this class, we’re going to spend some time looking at Windows 8 – and specifically WinRT – as well as the development challenges and opportunities it presents.

2

Developing a simple Metro-style application for Windows 8

Windows Runtime – The New Sandbox on the Block

Windows Runtime – commonly abbreviated to WinRT – is Microsoft’s answer to Android and iOS: two application sandboxes that have had explosive growth over the last few years. Windows has its own, highly popular application execution environment – the .NET Framework – but it seems the belief within at least some divisions at Redmond was that this was not the appropriate model for working with next-generation mobile devices. Attempts have been made in the past to use a subset of the .NET Framework in this way (such as the .NET Compact Framework and to some extent Microsoft Silverlight), but for better or worse WinRT is Microsoft’s latest attempt at addressing this particular market need.

WinRT is a complete layer on top of the core services belonging to the Windows OS. While with .NET it has often been needed to use the Platform Invoke capability to call through to the underlying Win32 API, with WinRT this is no longer needed or even allowed (at least not if you want to make your application available via the Windows Store).

So what does it mean, this idea of a sandbox? It’s basically a controlled execution environment for software: one that only provides a restricted subset of OS capabilities to applications. By not providing “risky” capabilities, sandboxes allow untrusted code to be executed in a controlled way: the ability to access certain resources – such as a user’s documents – must be specifically requested by the app, which get transferred to privileges that must be granted specifically by the user.

Aside from providing a much more secure and trustworthy environment for applications to execute, WinRT also provides the ability for code to be written in a variety of languages. We’ll look at that in more detail shortly.

WinRT – How it looks different

The first thing that strikes you when you see Windows 8 is that it looks very different. As mentioned earlier, the Start screen presents some highly colourful tiles to the user, some of which are “live” and present information deemed important by the apps to whom they belong.

The original name for the design language used for Windows 8 – as well as Zune, Xbox and Windows Phone – was Metro. In fact that’s the reason this class is named as it is. A few months ago, however, Microsoft stated the name had actually been a codename and went through a significant re-branding exercise (as despite being a cod-name, the Metro moniker had proved popular and was used fairly pervasively to describe the design language and the apps that make use of it). It’s believed this change of approach was driven by legal action from Metro AG, but that’s not really important for us to focus on.

3

Developing a simple Metro-style application for Windows 8

Microsoft adopted the term “modern UI style apps” before finally settling – fairly recently – on the term “Windows Store” apps. Whenever you see the title of this class – which has clearly now been set in fairly strong concrete – please translate it automatically to “Developing a simple Windows Store application for Windows 8”.

Windows Store apps are full-screen, chromeless and are clearly targeted at touch-centric devices (although it’s always possible to use them on devices that are not touch-capable).

There were various influences that drove the look of what was formerly known as “Metro”. While not a core part of this class, it’s interest to note them:

Bauhaus: http://en.wikipedia.org/wiki/Bauhaus

Swiss typography: http://en.wikipedia.org/wiki/International_Typographic_Style

4

Developing a simple Metro-style application for Windows 8

Motion design: http://en.wikipedia.org/wiki/Motion_graphic_design

In addition to these inspirations, the “Metro” design language is founded on some core principles:

Pride in craftmanship Fast and fluid Authentically digital Do more with less Win as one

One point that’s worth calling out specifically is “authentically digital”: while iOS has (at least until now) taken a firm position in favour of skeuomorphism (http://en.wikipedia.org/wiki/Skeuomorphism - in this context the act of imitating the real world in the digital one), Microsoft has chosen another path, avoiding the temptation of making digital imitations of real-world objects such as bookshelves. The message here is: don’t be afraid of digital versions being different, as those differences are also what make them valuable.

For more detailed information on these topics, I recommend these presentations (the second of which was the source of the included images):

http://www.slideshare.net/shanemo/metro-design-language

http://download.microsoft.com/download/4/2/1/4213D2B3-FB36-4969-BFEF-19C926C4BBDE/SHAPE12_9.pptx

5

Developing a simple Metro-style application for Windows 8

WinRT – How it is different

The programming model and the tools you need to use to make use of it are – on the one hand – familiar to .NET developers, but there are significant differences. There’s a lot to learn with WinRT.

Here are four main areas of difference, that we’ll cover in some detail:

Different object model for OS capabilities Asynchronous operation enforced for anything but “instant” responses Strict control over disk access Application interop only via contracts or file associations

The WinRT Object Model

When you first start working with WinRT from C#, there’s a great deal that’s familiar (especially if you’ve been working either with WPF or with Silverlight). There is a relationship with .NET, but it’s not actually the central mechanism that’s used to connect with the core OS layer. This happens to be COM – somewhat curiously for those of us that have been trying to distance ourselves from using this technology over the .NET years – but that’s really an implementation detail: you’re unlikely to have to get down and dirty with IUnknown (unless you really want to, of course).

WinRT and the CLR have distinct type systems that are effectively merged by the WinRT metadata adapter. At times it will seem a little strange to be working with the different types in the same application: for instance, some events are exposed via the CLR while others come from WinRT. You may notice the difference from the names (and types) of the arguments that are assigned automatically, but mostly these differences don’t get in the way at all.

When using C# or VB – and, inevitably, XAML for the UI – you’ll be targeting a particular .NET Framework profile (the .NETCore implementation). This provides access to the approved subset of the CLR for use with WinRT. At runtime, the full CLR is actually loaded and theoretically available to applications but the reality is that an application won’t be able to make use of it: while it’s possible for developers to hack their way beyond this approved subset of the Windows API, the Windows Store vetting process will exclude any apps submitted for posting that use techniques such as Platform Invoke or network loopback to play outside of the sandbox.

6

Developing a simple Metro-style application for Windows 8

Asynchronous operations are now the norm

.NET developers have been playing with the async capabilities released in .NET 4.5 for some time, but with WinRT this mechanism takes on a whole new significance: any operations that could in theory take more than 50ms to complete are only made available via asynchronous API calls.

The intention is clearly to stop long-running API calls from blocking the UI thread and resulting in apps “whiting out”. Asynchronous calls help keep the Windows 8 UI responsive and fluid.

And the good news is that the async and await keywords make this really easy to deal with from your code, for instance:

var file = await KnownFolders.DocumentsLibrary.GetFileAsync(“file.txt”);

In this situation, the await keyword tells the compiler to create an event that gets fired to continue execution of the application’s code once the results of the GetFileAsync() call are returned. The pain previously associated with performing operations asynchronously is now thankfully abstracted away by the compiler.

Restricted access to the file system

Applications making use of the WinRT object model no longer have arbitrary access to the file system. This is clearly intended to make applications more easily trusted by their users.

There are a relatively small number of locations that applications can request access to – they need to do so by modifying the Package.appmanifest to add “Capabilities”. Applications can – for instance – use this mechanism to request read/write access to the current user’s Documents, Pictures, Videos and to Removable Storage devices.

In addition to asking for access to files in this very restricted set of locations, applications also need to register themselves as associated with the types of the files they wish to access.

All these permissions get presented to the user when installing the app – and via the application’s Settings information – to make it very clear the type of information the app intends to access.

When an app asks the user to select a particular file from the system more freedom is granted to the app: it is effectively implied by the selection that the app is being granted permission to work with a particular file.

7

Developing a simple Metro-style application for Windows 8

Application interop

Applications have very limited abilities to interoperate in the WinRT world: even if the system’s underpinnings are COM – a mechanism that was intended to facilitate the passing of information between software components – WinRT has been deliberately limited in this very important respect. This imposes good behavior on app developers, but many will find it restrictive: there will certainly be times when apps want to pass information between each other without it being a user-initiated operation. But for the good of the user experience, this is the choice that has been made by the implementers of WinRT.

As mentioned previously, access to the file system has been deliberately limited, but it is still possible to use it to share data at a user level. The Registry, on the other hand, is not accessible from WinRT apps, and so can no longer be used to pass information between applications.

There was a brief reference to “network loopback” in a previous section: this is the act of hosting a lightweight internet server on the local host (127.0.0.1) and using that from another WinRT app to exchange information. This is a fairly common interop technique, but this capability has been at least partially blocked for apps. And those that do manage to implement this technique will not make it through the Windows Store vetting process.

So what options do apps have for sharing information?

There’s one very specific “contract” (which is basically a protocol that needs to be implemented and registered with the framework) that apps can implement in order to share information at the request of the user (the user can choose to pass data from one application to another via the Share charm). It’s in this way that apps can have user-initiated interop – such as a user choosing to share a photo with the Mail app.

It’s also possible for WinRT apps to launch a desktop app that has been associated with a particular file-type. We’ll see this later on, where we choose to launch AutoCAD from our companion app to load a particular DWG file.

8

Developing a simple Metro-style application for Windows 8

Some additional points about WinRT apps

The WinRT sub-system – while it runs on a traditional Windows 8 PC – is really intended for lightweight, touch-centric apps that will be run on a mobile device of some kind. WinRT apps are 32-bit only and are also not expected to consume significant quantities of memory: any that do will be jumped on by the WinRT runtime.

In fact the runtime is being left to manage application memory on a fairly general basis: apps don’t have explicit close or exit buttons (although you could, of course, choose to implement one) as the runtime is expected to terminate and resurrect apps as it needs to.

It’s generally not anticipated that software products such as AutoCAD will get ported to the WinRT sub-system: Microsoft doesn’t expect that heavyweight apps would get ported to WinRT. That’s not to say that it’ll never happen – or that AutoCAD components such as RealDWG will never be made available for WinRT – but there are significant architectural questions to resolve before it could happen. For instance, with restricted file system access, how would AutoCAD handle accessing and loading support files or external references?

So it’s clear that we’re not going to be talking about writing an AutoCAD-hosted WinRT app in this session – because without WinRT-based AutoCAD, there is no WinRT API for it. Let’s then take a look at what application possibilities there might be, especially considering that application interop is so limited between WinRT and desktop apps.

What can be done with AutoCAD?

Something that’s being promoted by Microsoft to developers of “heavyweight” desktop apps is the idea of a companion app. These are essentially Windows Store apps that complement desktop apps such as AutoCAD.

We’re going to see one such companion app in this session: an app called MetroCAD that is basically a browser for MRU (Most Recently Used) file information that gets created by AutoCAD on the current system.

This browser app will work as a companion to AutoCAD, showing file-level information – including drawing thumbnails – and even provide the capability to launch AutoCAD (or the application that has been most recently associated with the DWG file-type).

9

Developing a simple Metro-style application for Windows 8

Browsing AutoCAD’s MRU data in WinRT

AutoCAD stores is MRU-related information in the Registry – which those of you who have been paying attention will remember cannot be accessed directly from WinRT – so in order for this app to work we will need a desktop-resident component that extracts this information and makes it available to WinRT apps with appropriate permissions.

This extraction component could work from within AutoCAD or be completely standalone, and ideally would be automated.

In our case, we’re actually going to implement something in-between that makes use of a new feature in AutoCAD 2013, the Core Console.

Extracting AutoCAD MRU data from the Registry

We need a simple app that can query the Registry and populate some data on our file-system. We’ll store an overall manifest of the browsed DWGs in an XML file and supplement that with a set of thumbnail images we extract from the various DWG files.

We’ll also copy the source DWG into a specific folder, as launching a DWG from an arbitrary location is going to be problematic (this is one downside of the launching capability that we’ll see in more detail later on).

Here’s the C# code for our app. The project containing is a standard C# Class Library with project references to System.Drawing, AcDbMgd.dll and AcCoreMgd.dll.

using Autodesk.AutoCAD.ApplicationServices.Core;using Autodesk.AutoCAD.DatabaseServices;using Autodesk.AutoCAD.EditorInput;using Autodesk.AutoCAD.Runtime;using Microsoft.Win32;using System.Collections.Generic;using System.Drawing.Imaging;using System.Drawing;using System.IO;using System; namespace MruExtraction{  public class Commands  {    string basePath =      Environment.GetFolderPath(        Environment.SpecialFolder.MyDocuments

10

Developing a simple Metro-style application for Windows 8

      ) + "\\MetroCAD\\";     const char stringSep = '|';     private string[] GetMruFiles()    {      List<string> files = new List<string>();      RegistryKey ack =        Registry.CurrentUser.OpenSubKey(          HostApplicationServices.Current.UserRegistryProductRootKey,          true        );      using (ack)      {        RegistryKey mruk = ack.CreateSubKey("Recent File List");        using (mruk)        {          for (int i = 1; i <= 35; i++)          {            string file =              (string)mruk.GetValue("File" + i.ToString());            if (string.IsNullOrEmpty(file))              break;            else            {              if (Path.GetExtension(file) == ".dwg")              {                string fileTime =                  (string)mruk.GetValue("FileTime" + i.ToString());                 files.Add(file + stringSep + fileTime);              }            }          }        }      }      return files.ToArray();    }     public static DateTime UnixTimeStampToDateTime(long timeStamp)    {      // Unix timestamp is seconds past epoch        DateTime epoch = new DateTime(1970, 1, 1, 0, 0, 0, 0);      return epoch.AddSeconds(timeStamp).ToLocalTime();    }     [CommandMethod("EMI")]    public void ExtractMruInformation()    {      string[] files = GetMruFiles();       int created = 0; 

11

Developing a simple Metro-style application for Windows 8

      StreamWriter sw = File.CreateText(basePath + "mru.xml");      sw.WriteLine("<MruFiles>");      using (sw)      {        for (int i = 0; i < files.Length; i++)        {          int sepLoc = files[i].IndexOf(stringSep);          string file = files[i].Substring(0, sepLoc);          string fileTime = files[i].Substring(sepLoc + 1);           DateTime lastRead =            UnixTimeStampToDateTime(long.Parse(fileTime));           using (Database db = new Database(false, true))          {            db.ReadDwgFile(              file, FileOpenMode.OpenForReadAndReadShare, false, ""            );             Bitmap thumb = db.ThumbnailBitmap;            if (thumb != null)            {              // Generate a filename and save the image to it               string imageFile = "MruImage" + i.ToString() + ".png";              thumb.Save(basePath + imageFile, ImageFormat.Png);               // Get the time the drawing was last modified               DateTime lastMod = File.GetLastAccessTime(file);               // Get the base file name               string baseName =                Path.GetFileNameWithoutExtension(file);               // Write a line of XML for each file               sw.WriteLine(                "<MruFile Name=\"{0}\" " +                "LastAccess=\"{1}\" " +                "DayOfWeek=\"{2}\" " +                "LastEdit=\"{3}\" " +                "FilePath=\"{4}\" " +                "ImageFile=\"{5}\" />",                baseName,                lastRead.ToShortDateString(),                lastRead.DayOfWeek,                lastMod.ToShortDateString(),                file,                imageFile              );               // Make a local copy of the file

12

Developing a simple Metro-style application for Windows 8

               var outPath = basePath + baseName + ".dwg";              if (!file.StartsWith("\\\\") && !File.Exists(outPath))                File.Copy(file, outPath);               // Increment our count to report at the end               created++;            }          }        }        sw.WriteLine("</MruFiles>");        sw.Close();      }      Application.DocumentManager.MdiActiveDocument.Editor.        WriteMessage(          "\nExtracted thumbnails for {0} drawing{1}" +          " in the MRU list.",          created, created == 1 ? "" : "s"        );    }  }}

This app can be loaded and run in full AutoCAD or the Core Console. Let’s see that inside the Core Console. We’ll use the NETLOAD command to load the DWG and then the EMI command to extract the various MRU data and place it under our Documents folder.

We should now find the image files along with the XML “manifest” under My Documents\MetroCAD.

13

Developing a simple Metro-style application for Windows 8

Creating the Basic Browser

Now that we have the data we want to browse stored in a place that’s accessible to a WinRT, we can go ahead and create our basic browser.

Visual Studio 2012 provides some excellent foundational project templates for WinRT apps. The one that best fits our purposes is the Grid View template. We’re not going to go through the detailed process of adding all the functionality we need to this project, but we will be looking at areas of code that are implement various interesting capabilities.

If you really want to see all the differences in detail, you might create a basic Grid View app and then perform a “diff” with the files in the finished project.

The first “big ticket” item is to adjust the data-source for our items to reflect the data we want to store for each DWG. Then it’s clearly necessary to go ahead and adjust the XAML to bind to this data in various locations.

Now we’re going to take a look at various interesting features of Windows Store apps, to see how they can be implemented in our MRU browser app.

14

Developing a simple Metro-style application for Windows 8

Semantic Zoom

Semantic zoom is an interesting capability for any app that’s display lots of data. It lets the user “zoom out” on the data, showing it at a lower level of detail. For instance, rather than having the items listed with larger icons and their title (which is already a level of detail less than the full item view) we can implement a view that just shows smaller thumbnails for all the DWGs accessed on a particular day.

Pinch-zoom

A “zoomed in” view with the associated “zoomed out” view.

Some work is needed from the developer to support this view: they basically need to add a SemanticZoom element with ZoomedInView and ZoomedOutView sub-elements for the respective views.

The user can choose to display this view by simply pinch-zooming the display (or pressing the Ctrl key and using the mouse-wheel if relying on mouse and keyboard).

Contracts

For an application to hook into the core Windows 8 UI at a user-level – allowing the user to interact with the application via the standard Windows 8 Charms – it can implement various “contracts”. We’ll now take a look at code to implement contracts for Share, Search and Settings.

Implementing a contract typically means registering an event-handler for core WinRT events. These events get fired by WinRT and allow your application to provide the appropriate behavior for the specific scenario.

The application calls the static GetForCurrentView() method on the appropriate class and uses the returned object to register the event handler.

15

Developing a simple Metro-style application for Windows 8

Contracts – Share

For instance, the contract for sharing – in the case of acting as a source for the sharing operation – requires handling of the DataTransferManager.DataRequested event. The application’s code then populates a DataTarget object with the data it wants to share.

You can share various types of data with other applications, but be warned: the standard Mail app – which is the one most commonly used to test out your application’s ability to act as a sharing source – doesn’t handle the title and subject information if attachments have been provided.

To more effectively test your app’s sharing capabilities, there are both source and target sample applications on MSDN that will prove more helpful:

http://code.msdn.microsoft.com/Sharing-Content-Source-App-d9bffd84

http://code.msdn.microsoft.com/Sharing-Content-Target-App-e2689782

Contracts – Search

To implement the search contract, your app needs to implement a handler for the SearchPane.QuerySubmitted event. When the event is called, your code needs to generate a group of items that meet the search criteria.

Generating the group is straightforward with LINQ:

var query =  from item in Items  where item.Content.Contains(queryText)  select item; One thing to note about our implementation: we actually clone the items into the new group, as this makes it simpler to avoid issues related to items having links to their containing group.

Once we have the group we can simply navigate to it, causing it to be displayed in the UI.

16

Developing a simple Metro-style application for Windows 8

Contracts – Settings

For an application to have its settings displayed via the Settings charm, it needs to implement the settings contract. It does this by responding to SettingsPane.CommandsRequested, registering its commands here to be integrated with the charms UI.

When the specific command-handler executes, it updates the application’s settings. If stored via the Application.Current.RoamingSettings object the settings will follow the user from device to device via their Live ID. Once the settings has been either retrieved or stored, the application can then adjust the UI to reflect the user’s intention.

Live Tile Notifications

An application’s Start screen tile is not only the way the user launches an application, it’s the window a user has into any activity that’s related to the application. Static tiles are just that – they don’t display updated information – but “live” tiles are more interesting: they display dynamic information that’s relevant to the app.

For instance, the Mail app’s live tile displays recent email messages the user has received.

Application developers have different formats available to them. Here are examples of the wide format – the tile on the left is static and just displays the app’s logo, the one on the right is dynamic and shows information about one of the recently opened DWG files:

If the developer has chosen a wide format for their application’s tile, the user can still choose to shrink it to be square:

17

Developing a simple Metro-style application for Windows 8

The specific notifications that get presented to the user are managed via Windows.UI.Notification.TileUpdateManager. Up to 5 notifications can be displayed to the user in a rotating queue.

Snapping

One interesting capability of Windows Store apps is that they can dock: something that’s especially useful considering their otherwise full-screen nature. And for companion apps it can prove to be even more important, as they can dock to the side of the desktop.

A snapped app has up to 320 pixels wide of screen real estate available to it. Within this area it can show the view it feels appropriate, whether a single item or a group of them.

The implementation of snapping occurs in XAML (for a C#/VB/C++ app) or HTML (for a JavaScript app). There’s a particular VisualStyle with the “Snapped” name, and this controls the animation of the UI to the snapped state.

Launching

One feature that’s of great interest to companion apps is launching. Applications can launch the desktop application associated with a particular file-type via a file that the app can access. Which means it needs to be in a known folder the app can access and using a file-type that the app has an association with.

Here’s some code that will launch AutoCAD for a DWG file found in the current user’s Documents folder:

var file = await KnownFolders.DocumentsLibrary.GetFileAsync("A.dwg");await Launcher.LaunchFileAsync(file); For our browser app we will perform this when an item is double-clicked. The standalone MRU extractor copies the DWG files into a specific location inside the Documents folder, so when we launch we’re not actually editing the original document (something that could be considered a significant limitation). If all DWG files are stored beneath the Documents folder then this limitation could presumably be lifted with modest coding effort.

18

Developing a simple Metro-style application for Windows 8

Summary

WinRT is a brave departure – and a big risk – from Microsoft. They are maintaining the ability for legacy apps to be used on the new OS – at least when installed on a device powered by an Intel chip – but presenting a brand new application model that risks confusing users as well as bringing some pain to application developers.

The restrictions imposed by the WinRT programming model are for the best of reasons: to increase trust and improve the control users have over application functionality, but it remains to be seen whether these restrictions in some way limit the generation of usable Windows Store applications: it’s far from the case that existing apps of any complexity will be ported across to WinRT with ease (and it’s not Microsoft’s expectation that this will happen: presumably they would be happy if application developers in significant numbers invested in creating the next generation Windows experience using WinRT).

There does appear to be an interesting possibility for developers of heavyweight desktop apps to create companion apps that can be installed from the Windows Store and connect in some way to the desktop environment.

WinRT apps have some interesting UI capabilities that we saw in this session:

Semantic Zoom, allowing different levels of detail in summarizing items Contracts enabling apps to integrate with the Search, Share and Settings charms Live tile notifications, allowing apps to present information to users via the Start screen Snapping, allowing apps to dock with other apps Launching of desktop apps associated with a particular file-type

Blog References

Attended the Windows 8 TechConference

A simple MRU browser for AutoCAD data using WinRT

Implementing contracts in the AutoCAD MRU browser using WinRT

Adding snapping to the AutoCAD MRU browser using WinRT

19