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);
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;
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.
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 – http://code.msdn.microsoft.com/windowsapps/Bluetooth-Rfcomm-Chat-afcee559
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 (http://social.msdn.microsoft.com/Forums/en-US/tailoringappsfordevices/thread/9da68387-e0cb-4e02-ac71-bad61f6ff7c6) 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…
When directly integrating video capture in your Windows Store app you can use the MediaCapture class. There are a number of methods which affect the video but not all will be supported on all devices. One of these is SetPreviewMirroring
This mirrors the preview video so that your image is, well, like a mirror. However I’ve discovered that although the method throws an exception if not supported, it also throws an exception on Surface RT even though it is supported and the video is correctly mirrored. Worse still the GetPreviewMirroring method returns false when the video is currently mirrored 😦