Windows Phone Windows Store

WinRT Background Task Processes

I’ve been working on a Windows Phone 8.1 project which has several background tasks. One of these uses the device’s sensors – using a DeviceUseTrigger. This is different to how a regular periodic task works because the task implementation creates a deferral and keeps running handling the event generated by the sensor device until it is explicitly cancelled. The task is created normally with a class implementing IBackgroundTask and runs under the context of BackgroundTaskHost.exe. Because I wanted to share some data with the other tasks as a when they run I was interested if these other IBackgroundTask implementations were also hosted in the same process. If so this means that any static instances would be shared between them. Since I couldn’t find the answer I did some testing with some additional debugging and discovered that no, they each run in a separate process.

This lead me to explore how to share data between them. There are no built in IPC classes in the Windows Runtime like MessageQueues or similar so really the only options are the LocalSettings for individual setting values and files placed in the LocalFolder for any other data. The added complication here is that you have to handle the situation where both processes may try to read/write the file at the same time. Luckily you can use a named Mutex to enforce exclusive access to the file and have the other process wait on the Mutex.

Windows Phone Windows Store

Rating control for Windows Phone 8.1 Apps

In Silverlight 8.x you can use the Toolkit Rating control to provide standard star rating functionality in your app. If you’re moving to a Windows Phone 8.1 App project you can’t use the Silverlight based toolkit and there isn’t a native control to replace it.

If you’ve worked with Windows Store apps you’re probably familiar with the Callisto toolkit – a set of controls for Windows Store apps that brought things like settings flyouts (prior to them being rolled into the Windows Runtime) and a rating control. You can use this control within a Phone app with one caveat. If you try to reference the NuGet package for Callisto it will tell you it contains no library for Phone apps. However if you are using a Universal project this is easy to overcome:-

  1. Add the Callisto NuGet package to your Windows Store app
  2. In your Phone project select Add Reference and browse to the packages folder in the root of your solution
  3. Locate Callisto.1.4.0/lib/netcore451 and select Callisto.dll
  4. Bingo you can now add the rating control to your phone project.

I haven’t tested all the functionality in a Phone project so it is possible there may be some items which don’t work on Phone…

Hopefully in a future update to the Callisto NuGet package it will include a dll for Phone 8.1 apps too to avoid these extra steps…


Events Windows Phone Windows Store

//publish/ Event Manchester

If you haven’t already heard, we are running a developer event for Windows app developers in Manchester on the 16th and 17th May as part of the global //publish/ event. Pete has more details on his blog post here so I urge you to take a look and then


Windows Phone Windows Store

Linking to your other apps

Using the Windows Phone SDK the only method to return a list of your other published apps (e.g. for your About page) is to use the MarketplaceSearchTask and specify your company name in the search criteria. The problem with this is that it doesn’t return the actual publisher list but does a keyword search so you may find that a few other apps appear if other devs have used your company name in their descriptions or keywords.

The solution is to use a Uri and the LaunchUriAsync method in Windows Phone 8. The zune (yes it’s a throwback from the olden days) Uri scheme includes the ability to specify a publisher name e.g.

Windows.System.Launcher.LaunchUriAsync(new Uri(“zune:search?publisher=In The Hand Ltd”));

In case you don’t want to hard-code your publisher name (to create a shared component for example) you can add this from the metadata of your app using Charming ApplicationModel e.g.

Windows.System.Launcher.LaunchUriAsync(new Uri(“zune:search?publisher=” + InTheHand.ApplicationModel.Package.Current.PublisherDisplayName));

The equivalent functionality in Windows 8 is implemented through the ms-windows-store Uri scheme:-


or again using package information:-

Windows.System.Launcher.LaunchUriAsync(new Uri(“ms-windows-store:Publisher?name=” + Windows.ApplicationModel.Package.Current.PublisherDisplayName));

Windows Store

Launching System Features From Windows Store Apps

In Windows Phone we have a number of Launchers and Choosers for interacting with system features. For the most part the approach used in Windows Store is to use special URI schemes to achieve the same end result and launch platform features. I’ve collated together a list below of some known ones. Some like maps are documented in detail, others not. All can be launched with Windows.System.Launcher.LaunchUriAsync() (which also exists in Windows Phone 8 for launching other apps via a uri).


ms-windows-store: – Windows Store “Hub”

ms-windows-store:PDP?PFN={your package family name} – App detail page. Get your PFN from Windows.ApplicationModel.Package.Current.Id.FamilyName

ms-windows-store:REVIEW?PFN={your package family name} – Write a review page

ms-windows-store:Search?query={query term} -Remember to URI escape your query term text


xboxgames: – launches the games hub


The following launch Microsoft/Bing apps (if installed)

bingfinance: – Finance

bingfoodanddrink: – Food & Drink

binghealthnfitness: – Health & Fitness

bingmaps: – Maps. Full details here:-

bingnews: – News

bingsports: – Sports

bingtravel: – Travel

bingweather: – Weather

microsoftmusic: – Music

microsoftvideo: – Video

ms-mail: – Mail

windowsreadinglist: – Reading List

wlcalendar: – Calendar

wlpeople: – People

xboxsmartglass: – Smart Glass


Jumping back to the first set which cover the Store. In order to make these simpler to call and help with porting existing code from Windows Phone I’ve added a new library to the Charming suite. This is the first library to go the other way – provide a phone style API for Windows Store.

This library provides the MarketplaceHubTask, MarketplaceDetailTask and MarketplaceSearchTask which we know and love from Windows Phone and launches the equivalent functionality on Windows. The key differences beside the namespaces are that the content identifier for the MarketplaceDetailTask is a Package Family Name and there is no ContentType property to distinguish between apps, games and music. For the purposes of Windows Store all apps and games are treated the same and there is no music in the Windows Store. Code and documentation will be updated on the CodePlex site shortly though if you’ve used these features under Windows Phone you already know how to use it!

Windows Store

Detect When Running on Windows Simulator

The Windows Simulator is a deployment target for Visual Studio which allows you to run your Windows Store apps in a simulated device. This allows you to test touch interaction and different screen sizes and orientations on your development machine. The way this works is that it creates a Remote Desktop session into your PC. This is why when you run it you’ll see your own start screen and user account. The problem with this is that some APIs fail on the simulator such as setting up a Push Notification channel. We need a way to detect if we are running in the simulator so that we can react accordingly. If you try to poke around for hardware information you’ll find it returns the same as running directly on your machine. This makes sense when you know it’s a Remote Desktop session. Luckily there is an API specifically designed for this scenario:-

bool isRemote = Windows.System.RemoteDesktop.InteractiveSession.IsRemote;

This will return true in a Simulator session. We can use this to avoid calling any code which will fail on the simulator and can easily switch between local machine and simulator deployment to test various aspects of the app without touching the code or using different project configurations and conditional compilation.

Windows Store

Windows Store Apps: Application Tile Colour Within an App

When you define your package manifest for a Windows Store app you can specify the background colour used for your tile. Chances are this is a brand colour which you want to use throughout your app. You could specify it twice – once in the manifest and once in a XAML resource. However imagine the scenario where you are creating a custom control and need to use this colour without actually having access to the executing app code. The solution is quite simple and involves reading the compiled manifest from within your executing app package. The file in question is called AppxManifest.xml. We can use an XmlReader to locate the specific attribute we need. I wouldn’t poke around for too many things in this file as most of this information is accessible through the Windows.ApplicationModel.Package class. The code below (error checking removed for clarity) shows the steps to open the file for reading, locating the required Element and reading the “BackgroundColor” attribute. This string contains an RGB value in HEX notation so we can extract the Red, Green and Blue values and save to a Color. I’ve saved this to the apps Resources dictionary with the name “AppAccentBrush”.

Stream s = await Windows.ApplicationModel.Package.Current.InstalledLocation.OpenStreamForReadAsync("AppxManifest.xml");
System.Xml.XmlReader reader = System.Xml.XmlReader.Create(s);
reader.ReadToDescendant(<"VisualElements", "");
string attr = reader.GetAttribute("BackgroundColor");
byte r, g, b;
r = byte.Parse(attr.Substring(1, 2), System.Globalization.NumberStyles.HexNumber);
g = byte.Parse(attr.Substring(3, 2), System.Globalization.NumberStyles.HexNumber);
b = byte.Parse(attr.Substring(5, 2), System.Globalization.NumberStyles.HexNumber);
accentColor = Windows.UI.Color.FromArgb(0xff, r, g, b);
this.Resources.Add("AppAccentBrush", new SolidColorBrush(accentColor));

What else might you want to use this for? Well one feature we found annoying was that regardless of your colour scheme the indeterminate progress bar uses a default colour. As it turns out this is defined in the ProgressBarIndeterminateForegroundThemeBrush resource. You can access this Brush and modify its colour to match your tile colour.

 var brush = this.Resources["ProgressBarIndeterminateForegroundThemeBrush"] as SolidColorBrush;
 brush.Color = accentColor;
Windows Store

Installing Windows 8.1 Preview onto a UK Surface RT

It soon became clear that the Preview update package supports only a small subset of languages and while US English is of course supported the update would refuse to install on a device running UK English.

I first followed these instructions to install the update package:-

This worked and enabled the Store item to upgrade but that itself would not work because of the language issue. I then found this answer on the forums with a solution. It requires editing the registry so use it at your own peril:-

After this (reboot required) I was able to start the update process. It requires a 2GB+ download so took a while followed by quite a lengthy install but has now completed and I’m running 8.1. After the update I was able to set the keyboard language back to UK English, but you can’t set it as your primary display language because there is no UK English language pack in the preview. This isn’t a big problem as I’m already used to working regularly with US spellings.

Bluetooth Windows Store

Bluetooth Development with Windows 8.1

Unless you’ve been stuck under a rock (in which case what are you doing reading this?) you’ll know that Microsoft announced a preview release of Windows 8.1 at Build yesterday. While I haven’t got a development machine up and running yet (No easy upgrade if your device is UK English) I’ve been looking at the updated documentation at MSDN. Of the many new APIs described there are a couple of new namespaces which will be interesting to those working with Bluetooth devices:-

Windows.Devices.Bluetooth.GenericAttributeProfile – Contains functionality to work with Bluetooth LE devices. This will make it possible to interact with devices such as FitBit and other low energy sensors and devices from within apps – which means support on ARM devices.

Windows.Devices.Bluetooth.Rfcomm – Support for normal serial sockets Bluetooth. While completely different from the Windows Phone 8 API it provides the same functionality and more. Ability to enumerate and get notified of device arrival and departure and access to SDP attributes. There are identifiers for a number of standard profiles – Generic File Transfer, ObexFileTransfer, ObexObjectPush, PhoneBookAccess (client and server), SerialPort (SPP).

A new Chat sample is available for 8.1 here –

NFC Windows Store

NFC Text tags on WinRT

To follow the last post I thought I would quickly round it off by looking at the code required to listen for tags on a Windows 8/RT device. Devices with NFC built in are like hens teeth but one such RT device exists in the Asus VivoTab RT. Because it’s an RT device that means running the Remote Debugger and doing the development on a separate Windows 8 PC. The problem with the Windows 8/RT experience is it is not as set in stone as Windows Phone and so issues like this occur ( where some devices don’t correctly advertise support for all tag types. The good news with the Asus is that it does support subscribing to NDEF messages and you can use the same code as in my previous Windows Phone example to read a Text tag. The same Ndef library is used as this supports both Windows 8/RT and Windows Phone 8.

One thing which is a little frustrating when remote debugging is that you have to register for a developer license on the tablet before the debug session will continue. So even though you have a license on your development machine you also need one on the tablet (despite the fact you can’t actually compile an app on it). There doesn’t seem to be a limit to how many devices you can register for a license using your Microsoft ID so this shouldn’t become a problem. You will find that you have to renew it regularly though…

In a future post we will delve into other tag types…