Category: Windows Store

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:- http://msdn.microsoft.com/en-us/library/windows/apps/jj635237.aspx

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.

https://www.nuget.org/packages/InTheHand.Phone.Tasks.RT/

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!

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.

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", "http://schemas.microsoft.com/appx/2013/manifest");
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.

if(this.Resources.ContainsKey("ProgressBarIndeterminateForegroundThemeBrush")) 
{
 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:-

http://www.intowindows.com/the-update-is-not-applicable-to-your-computer/

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:-

http://answers.microsoft.com/en-us/windows/forum/windows8_1_pr-windows_store/the-windows-81-preview-isnt-available-right-now/274c3506-19f8-4bc1-ae32-9f35e855915b

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.