Above and beyond the Windows Runtime APIs that you primarily use for writing Windows Store apps, there is a host of functionality available in the Windows Live Services SDK, which connects your app to SkyDrive, Hotmail (email, contacts, and calendar), and Skype (messaging and calling). SDKs are available not only for Windows Store apps, but also for iOS, Android, and Windows Phone.

The Live Developer Center, http://dev.live.com, is the first place to start (and be sure to check out the Interactive SDK). The API docs are here.

For some background, there are a few posts on the Building Windows 8 blog that are relevant:


At //Build 2012 we had these sessions on Live Services:

And these at //Build 2011


If you don’t know anything about the Open Data Protocol—known as OData—it’s really quite simple. OData is a standard for providing a REST interface to a database. On the service side, OData is a layer that you create in top of a database (SQL Server, Azure, and MySQL) to provide those REST entry points using .NET, Java, PHP, and node.js. On the client side, you can then make HTTP requests to those endpoints directly, or use one of many OData client libraries.

Those libraries, along with more information about OData, can be found on http://www.odata.org. here’s the definition of the technology from that page:

The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The protocol emerged from experiences implementing AtomPub clients and servers in a variety of products over the past several years.  OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional web sites.

If you go to the OData Ecosystem page, you’ll see listings of consumers (apps and libraries for both clients and servers), serious applications, significant services that support OData (such as Netflix, eBay, and StackOverflow), and some other bits.

If you’re working in JavaScript, as I generally do, you can use the JavaScript client library (datajs) which can be installed via NuGet in Visual Studio. The documentation for it can be found on http://datajs.codeplex.com/documentation. There are also .NET libraries.

I’m planning to do a series of posts on this topic to go into the details, but that takes a little time to put together!

P.S. If you’re interested in how OData relates to other data-access technologies that Microsoft has put out over the years, check out Microsoft Data Development Technologies: Past, Present, and Future, an article that I wrote when I was working in the SQL Server organization and ran the MSDN data developer center.

I wrote about creating WinRT components in C#/VB in Chapter 16 of my book, and you can use such components from JavaScript. However, we’re seeing significant issues with the memory footprint of apps when you have both the JavaScript and the .NET runtime (CLR) loaded in the same process, so we’re recommending developers avoid that situation. Here’s a writeup from my teammate Kyle Marsh:

As Windows 8 has been gaining adoption Microsoft has been gathering more data from participants in our various feedback programs. One thing we observed in this data is pattern of memory usage spikes from Windows Store apps using JavaScript when the apps also use components built with C# or VB.

We know from the data we gather from Windows telemetry that users running multiple apps on less powerful hardware will occasionally encounter situations where the hardware cannot handle all the tasks. When this happens, system performance can degrade rapidly and  a spike in memory usage for apps that mix JavaScript and C# or VB is unavoidable.  Users who have more powerful hardware, or who run very few apps simultaneously, are less likely to be impacted but may still encounter reduced performance in certain situations.

Being conscious of the memory being used in the app can avoid exacerbating the problem, but it will not eliminate it.  Even well written apps will face a significant increase in memory footprint when mixing both JavaScript and C# or VB. We therefore recommend that developers avoid these memory spikes by not mixing JavaScript and C# or VB in their apps.

For developers who to provide components that can be used by JavaScript apps we recommended that you implement components with C++ instead of C# or VB.  C++ apps are compiled ahead of time and run directly on the OS, or in hardware, which every process already loads so there is no additional memory penalty for native code. Providing components in native code also avoids having two execution environments, thus it dramatically reduces the memory footprint and the likelihood of memory usage spikes.

In relation to my series of posts, Alive with Activity, on the Windows 8 Developer Blog (part 1 is there, part 2 will be posted today, and part 3 is in production), I’ve been working some with Windows Azure Mobile Services and am increasingly impressed with what’s being offered here. You owe it to yourself to learn something about them.

As you’ll see in parts 2 and 3 of that devblog post, Mobile Services, which I abbreviate as AMS and which is also referred to as ZUMO (aZUre MObile service), setting up push notifications is really a snap with this technology. That is, if you go through the list of things you have to do to support push notifications, there’s quite a bit on the service-end of things (as part 3 will describe), and these are many of the details that AMS takes care of for you.

The two primary tasks for push notifications are:

  • Sending channel URIs to the service: this step becomes far easier with AMS. Instead of sending HTTP requests that you have to build up yourself, you instead create a database table in the mobile service (through the Windows Azure portal) and simply insert a record into that table with the channel URI and any other key information you need to attach to it. The AMS client library takes care of the HTTP request behind the scenes, and even updates the client-side record with any changes made on the server. Furthermore, AMS can automatically handle authentication through the user’s Microsoft Account or through three other OAuth providers—Facebook, Twitter, or Google—if that you’ve registered your app with one of them. See Get started with authentication in Mobile Services.
  • Sending notification: in the raw, you have to send HTTP requests to the channel URIs used with push notification. With AMS< you can attach scripts (written in the variant of JavaScript known as Node.js) to database operations, and also created scheduled jobs in JavaScript. In these scripts, a simple call to the push.wns object with a channel URI and a payload generates the necessary HTTP request to the channel. It’s also a simple matter to capture push failures and record the response with console.log. Those logs are easily reviewed on the Windows Azure portal.

Now instead of spoiling the fun of my devblog posts where push notifications are concerned, here are other capabilities of AMS that you will want to know about.

  • The ability to authenticate the service with OAuth providers is very cool. Just as you can use OAuth providers to authenticate a user in a Windows Store app (using the Web Authentication Broker), you can also use that same provider on your service back-end. This means that having access to a unique user identity is pretty simple and straightforward, allowing you to manage per-user data in the service.
  • AMS builds on SQL Server databases hosted on Azure. Those databases are just like any other online SQL Server instance and can be accessed in the same way. This means that you can have other services, apps, web sites, etc., all talking to the same database that the Mobile Services part uses. This allows you to use that database as a central gathering point for data that you’d use for things like periodic and push notifications (OK–that’s a spoiler for Part 2…).
  • Whether or not you need push notifications in an app, the client library gives you a very easy way to save records to a database table and have any server-side modifications reflected back in the client. You can, of course, just read, delete, and update those records as well. In other words, the table-management capabilities in AMS can be used by themselves just for data management, which is super-cool. Even more so is the dynamic scheming capability with the database, meaning that you can just add columns (properties) as you need without having to separately manage the database tables.
  • You can easily do paging of data from the database, e.g. having your app only acquire so many records at once.
  • The scheduled jobs feature of mobile services lets you run code on your server whenever, for whatever purpose. You’re just setting up these jobs with little bits of JavaScript, so it’s not like you have to learn everything about server-side programming.
  • AMS works with Windows Store apps, yes, but also Windows Phone, iOS, and basically anything else that can talk to a service. Don’t think of AMS as just a Windows thing.
  • You can use AMS to send emails from the server.
  • AMS also provides mechanisms for managing server-based storage, e.g. for uploading images and other data from an app. You can use the Background Transfer APIs in WinRT to do this directly, but it means writing a service that can deal with those data streams. AMS does that for you, and employs the background transfer APIs on the client side.

And from what I hear, the story will get better in the months ahead when new features are added.

In short, it’s worth spending a few hours just looking through the AMS docs on http://www.windowsazure.com/en-us/develop/mobile/resources/#header-1. I think you’ll be pleased at what you find. ANd check back in every few months to see what’s new.

By the way, if you’ve read this and find yourself a little nervous about all this “service” stuff that takes you away from the concerns of client apps, let me say that I really do understand! Learning about HTTP, etc, well, I didn’t want to touch services for a long time, as it can be a very different world than writing apps. However, in the process of writing Chapter 13 of my book, I really didn’t have a choice. Because no one, to my knowledge, had put up a sample service to work with tiles, toasts, and badges (the Windows 8 SDK only has client-side samples), I took the plunge. Having done so, I have to say I’m really enjoying learning about this space, not just with Azure, which is very cool, but boning up more on ASP.NET, refreshing my PHP (in which I’ve worked a little), checking out Node/node.js (for writing servers), learning about the whole world of web APIs (see http://programmableweb.com), and thinking about how to use services creatively in apps.

And now that I’ve been looking into AMS, what’s so very cool about it is that you don’t have to deal with all that HTTP stuff at all!

So don’t be that afraid of it (I’m still a little iffy on OAuth…but that’ll come!). Take it a little at a time, and I’m hoping my devblog posts will help you bridge to that space as well.


Process lifetime events, like suspend, resume, and being restarted after being terminated by the system from the suspended state, are very important to test with your app. This is because when you’re running in a debugger, these events typically don’t happen.

Fortunately, Visual Studio provides a menu at debug time to trigger these different events:

Figure 3-8 (PLM controls)

Selecting either of the first two will fire the appropriate events, allowing you to set breakpoints in your handlers to debug them.

The third command, Suspend and shutdown, simulates the case where the app is suspended (as if the user switched to another app), and then the system drops the app from memory due to the needs of other apps.

In the debugger, you’ll see your suspend events fired, then the app exits and the debugger stops. More importantly, however, is that when you start the debugger again, you’ll see the previousExecutionState flag in the activated handler set to terminated. This gives you an easy way to through the startup code path where you’ll be rehydrating the app from whatever session state you saved during suspend.

After testing in the debugger, it’s a good idea to test the app under real conditions as well. Suspend and resume are easy enough–just switch to other apps. Be sure to leave the app suspended for different lengths of time if you have any kind of timestamp checking in your resuming handler, e.g. code that determines how long it’s been since suspend so that it can refresh itself from online content, etc. If you can, try to leave the app suspended for a day or longer, even a week, to really exercise resuming.

To test terminate/restart in a real world scenario, you’ll need to basically run a bunch of other memory-hungry apps to force Windows to dump suspended apps out of memory (large games are good for this). You’ll make it easier on yourself if you have less memory in the machine to begin with; in fact, to test this condition you could shut down your machine and pull some physical memory (or use an older, less powerful machine for this purpose).

Alternately, you can use a tool that will purposely eat memory, thus triggering terminations. A good list of tools for this purpose can be found on http://beefchunk.com/documentation/sys-programming/malloc/MallocDebug.html.