For more posts in this series, see the series index.

Something I have started to do with my applications is to make it easy for the people who use the applications to send feedback – since that is the best way to improve it is based on the feedback of those who use it. The question then becomes, how to I collect this feedback?

I could put some screen in the application but I decided to rather have a simpler method for this – email. All I need now is a way to launch the email program and ideally have my email address & subject prefilled – which is not possible with the share source experience.

The solution to this is something we have used for a long time before Windows 8 – protocol handlers, and in particular mailto.

So how do you launch a protocol handler in a Windows Store app – the same way you launch a web page, the Launcher.LaunchUriAsync method.

The usage of protocol handlers does open a lot of possibilities too for sharing between Windows Store apps & Windows desktop apps!

For more posts in this series, see the series index.

Here is an interesting issue, you need to implement a Share Source but to do the sharing you need it to be an async call. So what do you do? You can add the async & await modifiers but it won’t work correctly. The solution is to use the deferral which is given to you in the arguments of the event and when you are done you call the Complete method on it to indicate that you are done with all the async goodness:

async void App_DataRequested(DataTransferManager sender, DataRequestedEventArgs args)
{
    var deferral = args.Request.GetDeferral();

    // async code with await keyword here

    deferral.Complete();
}

For more posts in this series, see the series index.

When you start with development of Windows Store apps, you may want to run tasks in the background and an important aspect of that is deciding if you want to be a lock screen app or not.  Microsoft has a guide on this, which is ESSENTIAL reading so this post should be seen as a cheat sheet for a portion of that document.

Triggers

Background tasks kick off on a trigger so what triggers can lock screen & non-lock screen apps use. Non-lock screen apps can run background tasks based on

Lock screen apps can use those and much more, the extra triggers for lock screen apps are

CPU

Now we know when the background task will happen, how much CPU can background task consume during it’s execution is also affected by lock screen & non-lock screen.

Before we look at the table there is three things to know:

• This is per app – NOT per background task!
• Think of the refresh period as the point were we get filled up with more resources. So you can run multiple background tasks and they all consume from the pool of resources. At the refresh period the bucket is filled & any unused time will be lost.
• CPU second is not the same as a real second. A CPU second is the amount of time that is consumed by the CPU – so if you are doing I/O (like a download) then it is not counted.

Bandwidth

In a similar way to CPU the amount of data you can consume is also effected by being a lock screen app, but in addition to that the average speed of your internet also effects the amount of data. There is another difference to CPU, rather than one bucket – there is two:

• Small period: The shorter amount of time and has a small amount it can be downloaded.
• Day: The max per day – so accumulation of all the smaller ones cannot exceed this.

The table below has 1Mb & 10Mb as the average speed options but you could think of them as 1Mb = WiFi and 10Mb plugged into a network. These amounts are the top end, so if the network is slow you get less.

Global Pool

Above we have looked at the resource constraints for CPU & bandwidth but what happens if that isn’t enough? Windows has a global pool of additional CPU & bandwidth resources that are shared system wide. This means that if you need 2.5CPU seconds you will likely get it! However the global pool is shared across all the apps, so it is not guaranteed (the above resources we have looked at are guaranteed). So if you have some abusive apps that use it, then your app may not get anything from the global pool. The global pool is replenished every 15min.

You can test your app works with an empty global pool, and you really should do this, by turning it off in the registry

Control channel

The network trigger feature supports two possible resource types for a push notification or keep-alive network trigger:

• Hardware slot - Allows the app to use background network notifications even in low-power or connected-standby mode.
• Software slot - Allows the app to use background network notifications but not in low-power or connected-standby mode.

This notion of slot is integral to the network trigger and is not required for WNS.

One of the options to specify while registering for the network trigger feature is the hardware or software slot resource type. This resource type capability provides a way for your app to be triggered by an incoming notification even if the device is in low power mode. By default, a software slot is selected if the developer does not specify an option. A software slot allows your app to be triggered when the system is not in connected standby. This is the default on most computers.

On the other hand, a hardware slot allows your app to be triggered at all times including when the system is in connected standby. Only systems with network devices that support connected standby will have a hardware slot. Note that the app cannot be triggered through a software or hardware slot when the system is in Sleep or Hibernate mode, or is shut down.

An app can create and use a maximum of 5 network triggers. There is also an additional system limitation on number of network triggers that specify hardware slots. The first 3 lock screen apps that register for a hardware slot for a network trigger can use a maximum of 3 hardware slots per app. Any other lock screen apps beyond the first three apps registered for hardware slots are limited to only software slots for their network triggers.

For more posts in this series, see the series index.

So you have created your background task and now you want to test it – do you wait for 15min and hope it runs? Nah – there is an easier way (which is unfortunately hard to find).

First launch your app as normal and then while it is running swop to VS (this is where multiple monitors is fantastic) and you should see the Debug  Location toolbar.

if you do not see it then right click on the toolbar/menu area and you will be able to enable it.

This toolbar is very useful to test Suspend & Shutdown scenarios for your application but what is not obvious is that if you click the little arrow next to the suspect button – all your registered background tasks will be listed there. You can then click it to kick it off immediately! Great for testing.

For more posts in this series, see the series index.

Here is a interesting requirement of Windows Store apps – they must run on a low-power computer, and if (like me) fail this you get the error message you see in the screenshot which suggests a test tool exists.

The problem with this tool is it can only test HTML apps :/ The question is then, what can XAML developers do to help avoid this situation? Use task manager – really. It is that easy! Just watch your memory usage while using your application once you have that there is two things you can do.

At the bottom of the Selling details page is the option to specify if you need more than 2Gb of RAM – which feels really high for the types of apps I build, but maybe worthwhile to those developing games. If you are over 2Gb of RAM, make sure you set that.

The second location is under the Description page which has a completely optional Recommended hardware

Here is some free form space for you to put in conditions about the application including things like disk space & memory usage. I resubmitted the app that failed originally with just this specified and it passed, so it appears that this is taken into account.

For more posts in this series, see the series index.

A lot of the guides for developing Windows Store apps talk about an event log where you can see information from the apps – this is of special importance for those doing background processing, live & secondary tiles. In the documentation it is either called just TWinUI or it is called Microsoft-Windows-TWinUI, however you may battle to find that in the event viewer since the group it is in, is not named that.

To get to it go to

1. Application and Services Logs
2. Microsoft
3. Windows
4. Apps

And you will find it inside that group! Happy debugging.

For more posts in this series, see the series index.

In a recent application I made use of the amazing Metro Studio tool for the logo of the application and needed to create a lock screen image. Lock screen images must be white & transparent and 24px square so I used the tool to create the image as in the image below.

However I kept getting an error when trying to certify the app:

Image reference "ClusterGroup.png": The image "\ClusterGroup.png" has an ABGR value "0x9BFEFEFE" at position (8, 0) that is not valid. The pixel must be white (##FFFFFF) or transparent (00######).

Huh?! My image is white & transparent! Using the awesomely improved graphic editor in Visual Studio 2012 I went to check the pixel (column 8, row 0) in the error message. I used the eye dropper tool to get the colour into the right hand window and sure enough it isn’t white. It is a grey colour used to anti-alias the image. (This has been reported to SyncFusion – but no response at time of publishing)

The problem is this is not valid you can either have:

• Fully transparent – from the error message the alpha channel needs to be zero and the RGB can be anything: 00######
• White – from the error message the RBG must be max (so white) and then the transparency can be set to anything: ##FFFFFF

The second one means you can have solid white #FFFFFFFF or a more transparent option #77FFFFFF (for example). The idea is to use the transparency rather than a grey colour to anti-alias. For me the fix was to manually edit the pixels to fix this.

For more posts in this series, see the series index.

One of my applications had two sets of images, one with English and the other with Russian. While it is great to support both languages I did not want to fully localise the application, such as changing all the labels because I do not have the time & resources to do that. When I setup the project I put the English images in a folder named Comic/en and the Russian images in Comic/ru.

When I built the application I noticed some smart messages in the compiler about finding localised content – which I thought was nice and just ignored it.

(The text there is: MakePRI : warning 0xdef00522: Resources found for language(s) 'en, ru' but no resources found for default language(s): 'en-US'. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899)

The problem is that when you upload to the Windows Store that information is used to figure out what markets your application should be localised for, this meant I needed to submit a description for English, US-English & Russian! This would allow me to write the description in different languages but since that is not in my scope it became a hassle.

The “fix” was to prefix the folder with lang (so en became langen) – this tricked the compiler into not seeing this as localised and removed the problem.

For more posts in this series, see the series index.

With one of my earliest apps I kept having a problem with a COM exception being raised, when trying to setup the Share & Settings event handlers. A key factor is it didn’t happen all the time. I had it the following code on the constructor of my ViewModel class:

this.DTM = Windows.ApplicationModel.DataTransfer.DataTransferManager.GetForCurrentView();
DTM.DataRequested += ShareRequest;

Eventually I figured out that the exception was raised if the event was already attached, but this was in my view model class and this was in the constructor of the class (so should be new and fresh every time) – this didn’t make much sense to me. However the answer was in front of me the entire time: GetForCURRENTVIEW.

Windows 8 apps can be built in one of two ways:

• Page Model – This is the same model as Windows Phone 7 where when you want a new UI you navigate to entire new page, or view.
• Composition Model – In this model you have a single page, and you inject content in the form of user controls into the page. I am working with AtomicMVVM which follows this pattern.

The problem with the composition model, is that the events are tied to the page (or view) & since I never changed the page (just the content was swopped in and out), the event handlers were never being changed.

The solution for me was to make it possible for the view models to state if they have Share or Settings and then have a single place in the constructor to setup the configuration for the charms. I used a simple interface based system for this which the following code should illustrate. Since the event handler was attached once – the exception went away. This also allows my view to be very smart about the share & settings events and what it passes to those.

// during the startup I bind once to the event. Note that I onlt do this once the UI is up.
    bootstrapper.AfterStartCompletes += () =>
        {
            SettingsPane.GetForCurrentView().CommandsRequested += SettingCommandsRequested;
        };


void SettingCommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args)
{
    var settings = Bootstrapper.CurrentViewModel as ISettings;
    args.Request.ApplicationCommands.Clear();

    // if the view model implements the interface then I can call the method to set the commands it needs.
    if (settings != null)
    {
        settings.LoadCommands(args.Request.ApplicationCommands);
    }
}

For a complete example of this see the Metro Demo in the AtomicMVVM samples: MetroDemo

For more posts in this series, see the series index.

The call to pin a secondary tile looks like this:

SecondaryTile(string tileId, string shortName, string displayName, string arguments, TileOptions tileOptions, Uri logoReference);

The important part for this post is the last parameter: Uri logoReference. This is the the path to the image you want to show on the tile – but I had a problem, I didn’t want to show an image! I just had some text I wanted to show on the tile. After a lot of digging the solution was non trivial – generate an image at runtime. This was made even harder as the Render method in WPF does not exist in the XAML implementation used in WinRT.

WinRT does include a WritableBitmap class which allows you to create a in memory bitmap, manipulate the pixels and save to a file format with the BitmapEncoder classes. The problem for me is I do not want to fiddle with pixels manually – this lead me to WritableBitmapEx which is a great library for having primitives (fill, line, circle etc…), the only down side was that I wanted text, not graphic primitives. 

More searching lead to two posts on StackOverflow from XXX (post 1, post 2) which provided a solution:

1. Create a sprite map using a free tool called  SpriteFont201
2. Use the code provided in the answers with WritableBitmapEx to extract the sprites and combine them with a WritableBitmap.

I took the code and adjusted it slightly so text would always be centred and allowed me to play with font scaling. I’ve attached the modified code to the post below.

In the end the code I used looks like this:

public async Task<StorageFile> CreateImage()
{
    uint width = 512;
    uint height = 512;
    var writableBitmap = BitmapFactory.New((int)width, (int)height);
    writableBitmap.Clear((App.Current.Resources["SecondTileColour"] as SolidColorBrush).Color);
    
    writableBitmap.DrawStringHoriztonallyCentred(this.DisplayPostalCode, 50, "title", Colors.White, 4);
    writableBitmap.DrawStringHoriztonallyCentred(this.Town, 175, "title", Colors.White, 2);
    writableBitmap.DrawStringHoriztonallyCentred(this.City, 275, "title", Colors.White, 2);
    writableBitmap.DrawStringHoriztonallyCentred(string.Format("box code: {0}", this.BoxCode), 375, "title", Colors.White, 2);
    writableBitmap.DrawStringHoriztonallyCentred(string.Format("street code: {0}", this.StreetCode), 450, "title", Colors.White, 2);

    var file = await Windows.Storage.ApplicationData.Current.LocalFolder.CreateFileAsync(Guid.NewGuid().ToString("N"), Windows.Storage.CreationCollisionOption.ReplaceExisting);
    using (var fileStream = await file.OpenAsync(Windows.Storage.FileAccessMode.ReadWrite))
    {
        var encoder = await BitmapEncoder.CreateAsync(BitmapEncoder.PngEncoderId, fileStream);

        encoder.SetPixelData(BitmapPixelFormat.Bgra8, BitmapAlphaMode.Straight, width, height, 96, 96, writableBitmap.ToByteArray());

        await encoder.FlushAsync();
    }

    return file;
}