My first Windows 8 application

Justin James replaces the sample data sources in his Windows 8 Metro/WinRT application with connections to the Microsoft Research OData source. He says writing the code to use the data is a horrid experience.

Last week, I took you on a tour of Visual Studio 11, installed Team Foundation Server 11, and started a basic Windows 8 Metro/WinRT application from a template. Today, I will replace the sample data sources in the application with connections to the Microsoft Research OData source.

One omission from last week was that I did not show a full-screen view of Visual Studio 2011. Figure A has that view. As you can see, some of the concerns expressed in the comments about the UI being "flat" and difficult to differentiate things are well founded. This is a common complaint from a number of prominent sites and writers, and hopefully Microsoft will decide to put form over function here, especially since Visual Studio 11 isn't a Metro application and does not need to share the Metro look. Figure A

Visual Studio 11 looks like a picture of the Moon... all grey with crater-like icons. (Click the image to enlarge.)

After I use the template to create the basic guts of the application, it is time to get it pulling data from Microsoft Research. I tried to follow Samidip Basu's tutorial for this purpose, but it is not accurate, since it creates classes that depend upon System.Data, which is not accessible from within WinRT. Visual Studio 11's Service Reference wizard won't create proxy classes for OData either.

Let's get this straight: Microsoft puts a ton of work into the Azure Data Market (using OData), gets folks using OData out of LightSwitch and Entity Framework, etc., pushes all sorts of other OData-related technologies, and then does not deliver competent OData support in Visual Studio 11 for Metro/WinRT applications? Come on Microsoft, how do you expect us to take OData seriously when you don't? Speaking of "unsupported," WinRT currently does not have a built-in HtmlDecode function.

So, it is time to try the backdoor route, doing it by hand. I take the SampleDataSource.cs file, and rename it and the classes within to more appropriate names (I replace "Sample" with "MicrosoftResearch"). Next, I take the MicrosoftResearchDataItem class and add a Uri property to store the URI to the actual item. All of my classes are now prepared at a basic level.

The MicrosoftResearchDataSource (nee SampleDataSource) class has hard-coded data. It uses a single data item that it adds a few times to each group. It is easy enough to pull the group information dynamically. The endpoint for the OData service is, and when you pull that up, you get a list of each available group. I use a WebClient call to download the data. Remember, with WinRT (much like Windows Phone 7), any potentially long-running operation must be done asynchronously. I've already written this code in my Airport Status Checker WP7 application, but there are enough differences between WP7's classes and WinRT's that a direct translation isn't happening. For example, WP7 has the "WebClient" object, which asynchronously makes a request and returns either byte array or a string and fires an event handler when it is done. WinRT has "HttpClient," which uses the new "async" system to make the request, so you use "await" to listen for results. This also necessitates a change in structure a little bit, due to the requirements of async/await.

Writing the code to use the data is a horrid experience. From top to bottom, this is the kind of thing that computers were invented to handle automatically. Instead, the lack of a proper proxy class creator means that I have to write and debug everything by hand, finding out what fields are optional and mandatory, common and not, and coding to that. Honestly, doing this work by hand is absolutely brutal, miserable, and pointless, and it took me an hour or two to go from realizing I needed to write it by hand to having data on the screen. Here is the code I wrote:

public sealed class MicrosoftResearchDataSource


private ObservableCollection<MicrosoftResearchDataGroup> _itemGroups = new ObservableCollection<MicrosoftResearchDataGroup>();

public ObservableCollection<MicrosoftResearchDataGroup> ItemGroups


get { return this._itemGroups; }

private async void GetGroups()



var downloader = new HttpClient();

downloader.MaxResponseContentBufferSize = int.MaxValue;

var groupXml = await downloader.GetStringAsync("");

var groupData = XDocument.Parse(groupXml);

var workspaceName = XName.Get("workspace", "");

var titleName = XName.Get("title", "");

var collectionName = XName.Get("collection", "");

var entryName = XName.Get("entry", "");

var contentName = XName.Get("content", "");

var propertiesName = XName.Get("properties", "");

var idName = XName.Get("id", "");

var summaryName = XName.Get("summary", "");

var nameName = XName.Get("Name", "");

var descriptionName = XName.Get("Description", "");

var urlName = XName.Get("Url", "");

XElement summaryElement;

XElement nameElement;

XElement descriptionElement;

XElement urlElement;
foreach (var collection in groupData.Root.Element(workspaceName).Elements())




if (collection.Name == collectionName)


var groupName = collection.Element(titleName).Value;

var group = new MicrosoftResearchDataGroup(groupName, groupName, "", "", "");
var itemsXmlStream = await downloader.GetStreamAsync("" + collection.Attribute("href").Value);
var itemData = XDocument.Load(itemsXmlStream);
foreach (var item in itemData.Root.Elements())
if (item.Name == entryName)


var properties = item.Element(contentName).Element(propertiesName);



summaryElement = item.Element(summaryName) ?? new XElement("summary");

nameElement = properties.Element(nameName) ?? new XElement("name");

descriptionElement = properties.Element(descriptionName) ?? new XElement("decription");

urlElement = properties.Element(urlName) ?? new XElement("Url");

var dataItem = new MicrosoftResearchDataItem(item.Element(idName).Value, item.Element(titleName).Value, summaryElement.Value, "", nameElement.Value, descriptionElement.Value, urlElement.Value, group);



catch (Exception ex)






catch (XmlException ex)


Once I get it working, I tweak the XAML slightly, primarily to get rid of the image (since there are no images to use in the data) and to add the URLs for the items. I also discover that the XAML contained references to the original SampleDataSource class (even though "Rename" supposedly checks all files for it) for design-time data. I try to change it to my new data source class, but this was an absolutely wretched process because it was continuously attempting to instantiate my data source class; this data source needs to pull a ton of data off the network and parse it. As a result, I opt to make a "SampleMicrosoftResearchDataSource" that mocks up the MicrosoftResearchDataSource (and have it use some hard-coded content) and use it for the design time display. Incidentally, the call that instantiates/binds the data to the application at runtime is in App.xaml.cs; it creates the MicrosoftResearchDataSource object and passes it to the navigation method of the root frame. That is fairly ugly, it is not very intuitive, and it is difficult to discover where exactly data is coming from, which complicates a gripe I've had about XAML and binding for a long time.

The application works fine. Figure B, for instance, shows one of the item views (I need to strip the HTML out of the text). I like the controls on the right and left to allow paging, though for a touch device, having "Back" and "Next" on each side like the paging buttons on a Kindle would probably be better for usage (though less intuitive). I really feel like I got "something for nearly nothing" with the application template, which is rare; I typically feel that starting from scratch is the best way to make applications because the templates never seem useful. Figure B

Item view (Click the image to enlarge.)

The biggest problem with this application in its current state is performance. It is an absolute dog, and the reason is clear: the source data was many, many megabytes of XML that has been turned into a data structure in memory to be navigated, and at times, thrown onto a page all at once.

The solution is obvious: It needs to be able to load only a handful of items at a time, possibly even a few hundred or so. We see this on mobile devices all the time to save bandwidth at the expense of time. Doing a pre-fetch or an on-demand fetch of the next one 100 items could make sense, but on the surface, it is a pretty complicated technique. It is possible that I missed the boat on a useful option of the controls that enable this; I will do more digging and hopefully come up with a good option for this. Alternatively, maybe I just need to do something really simple, like hook onto the "yield" behavior of the collection classes for the data, and only load items if they aren't loaded, and then load them in batched from a cached copy of the file. I also suspect that removing the URL path entirely from the data objects and editing the UI templates to not try to show images will be a huge help (think of all of those instances of the blank, default images being loaded!). It is going to take some time for me to figure out how to address this performance question.

My next goal for this project is to implement search and use the Contracts to expose the application as a search provider to Windows 8. After that, I will work on tweaking the UI more, since it is not meeting the needs of the application right now.


Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.