My most popular posts of 2013?

I don't know, don't care and won't be looking them up.
What value would it add?

Here's how this blog works. I write about what I want, when I want.
I write things because I feel compelled to share them. Sometimes because they are things I want to say (and this is my soapbox). Sometimes they are things that I'm amazed others haven't already said.
And the final type of post I write is to document a technical issue or, potential, gotcha that isn't documented anywhere else. My hope is that by documenting it others will be able to find my post (Google is normally quite good at helping with this sort of thing) and save themselves some time and frustration. I really try to avoid documenting things that are already written elsewhere.

What about the people who read what I'm writing?
The vast majority of people who read what I write here do so after finding a particular page as the result of a web search. I hope that what they find is useful to them.
A smaller number follow what I write here by subscribing to the RSS feed. (Link at the top of each page)
A number of things I write here are also re-posted on the Nokia community developer blog and on Dzone.

I hope and expect that what I write in future will continue to be of interest and value to each of the three types of reader identified above.

My intention is that I will write more [often] in 2014. It'll probably be along the lines of what I've been writing recently.
If you have a specific question or topic you'd like me to write about feel free to suggest something.

Advise the user when something bad may happen but don't necessarily prevent it.

Let's say you've built an app that needs to download a large amount of data. As part of trying to ensure the best experience for the people using the app, you have add code that detects the type and speed of connection the device currently has.

So, what do if the device is on a particularly slow connection? And/or they're on a mobile data connection (rather than a wireless/WiFi one) and so the financial cost of the transfer may matter? Or maybe they're using roaming data and so the cost of transferring the data could be considerable?

As you may have guessed from the title of this post, the thing you shouldn't do is stop the person from attempting to make the download.
To do so say that you know better that them what they want.
Doing so says that your idea about what should be allowed is more important than what the person using the app is trying to achieve.
The data the app needs may be really important to what the person is trying to achieve. The desire to access the data and/or use the app that they've opened (presumably to perform a specific task) may be worth the cost of obtaining or delay in accessing the data.

Asking the person using the app to confirm their actions in this case not only makes sense but is recommended.

Asking for confirmation at this time allows you to make sure that the person is aware of the consequences of what they're asking the app to do by downloading the data.

"You appear to be on a slow connection. Downloading may take some time. Are you sure you wish to continue?"

"You appear to be using roaming data. Downloading the data may cost more than usual. Are you sure you wish to continue?"

Asking each of the above questions (or similar) as appropriate, when combined with a "Remember my answer" capability, can lead to happier users.

APP: Phone Book

I'm not normally big on writing utility apps as there are already many written for most, if not all, scenarios you can come up with.
Recently though I was asked, by two different people, how to do something on Windows Phone that wasn't possible and for which an app hadn't already been created to fill the need.

It seems it's common when new to Windows Phone to want to be able to list only those contacts for whom you have a phone number. For many, the fact that the people hub contains so many people (once you've linked all your social networks) can be a little overwhelming and it can be reassuring to see a list of contacts similar to what people had on their old, non-windows phone, device.

This is the app gap I've just filled. I've called it Phone Book.

If you're giving someone their first Windows Phone this Christmas or someone you know gets one and asks about filtering their contacts to be more like what they were used to with their old phone then this app could be just the thing to help them transition to Windows Phone with greater ease and comfort.

If you just want to see the contacts for whom you have a phone number this app lets you.

Here's how I works:
The app is simple and upon starting just loads the people for whom any phone number is known.

Just tap the contact and you'll be asked f you want to call them.

If you have multiple numbers for an individual then you'll be prompted to choose which one to use upon tapping the person's entry.

Get it from the store at: http://www.windowsphone.com/s?appid=0589eead-a4f9-4f96-a3ac-d82056050006


All feedback greatfully received.

Batteries in mobile devices

Batteries in mobile devices get a bad wrap.
As users of phones, we don't want to have to think about how long the battery will last.
As developers, we don't want to have to think about the impact on battery life our apps will have.

Unfortunately, as developers, we do need to consider our codes implications on battery life.
It's not all bad though.
Battery lifetimes have been increasing though. It's just that devices have started having larger screens (which require more power) and are packed with more sensors.
Things have got better in more ways too. I can now buy a device and use it straight out of the box. It's not too many years ago when the first thing you had to do after buying a new device was take it home and charge the battery for 12 or more hours. Far from a delightful first experience with a wonderful new phone.
Yes this is only a small thing and due to a change in battery technology. I was just struck by this recently though and think it's important to remember all the little improvements we have seen while we focus on building the future.

We're not yet in battery utopia where batteries last indefinitely. Maybe we never will be. Just don't forget what we do now, compared to how things used to be. ;)

Saving my users 3.5MB in downloaded data

Some may call it a micro-optimisation but I call it "pride in craftsmanship". Here's a little Azure config tip if you're hosting your app's web service there running ASP.Net MVC or WebAPI.

Simply add this to Global.asmx.cs

protected void Application_PreSendRequestHeaders()
{
  Response.Headers.Remove("Server");
  Response.Headers.Remove("X-AspNet-Version");
  Response.Headers.Remove("X-AspNetMvc-Version");
  Response.Headers.Add("Arr-Disable-Session-Affinity", "True");
}

If you're not running on MVC you can exclude the "X-AspNetMvc-Version" line.
If you need session affinity in your requests then you'll need to exclude the last line too. Hopefully you've built a nice stateless REST service API so it's not needed though. ;)

This allowed me to change the response headers from:

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 118099
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=714c53d6b632a8f0cb8d9df96bafc60e300af0e3709b2c58e8e56273d9fc4120;Path=/;Domain=mir.azurewebsites.net
Set-Cookie: WAWebSiteSID=10eb484b1b294411b6aac209166dbe9b; Path=/; HttpOnly
Date: Thu, 12 Dec 2013 22:21:31 GMT

to:

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 118099
Content-Type: application/json; charset=utf-8
X-Powered-By: ASP.NET
Set-Cookie: WAWebSiteSID=cd9d0b49a2ea4f2986c535ed9bba9ea4; Path=/; HttpOnly
Date: Thu, 12 Dec 2013 22:46:15 GMT

Cutting out:

Server: Microsoft-IIS/8.0
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
Set-Cookie: ARRAffinity=714c53d6b632a8f0cb8d9df96bafc60e300af0e3709b2c58e8e56273d9fc4120;Path=/;Domain=mir.azurewebsites.net


That saves 206 bytes per request.
Now if the request is made by a periodic background agent that means the request will be made approximately 48 times a day, 365 days a year.

That adds up to 3524.53 KB per year. Not a massive amount but every little helps when saving users data.
I made this change as part of some other optimisation work (that I might eventually blog about) but thought it was worth sharing here as it's easy to apply to a wide variety of uses.

An example of making a BETTER Windows Phone app

If you were at the London leg of #WinPhoneWeek or the last WPUG meeting you'd would have seen me show an example of a very basic app, talk about why it wasn't as good as it could be and then show some examples of how and why it could be made better.

I've now written a detailed overview of what I talked about and released the two sample apps to the store.

You can read it on the new Microsoft UK Developer site.

And you can find the apps in the store:

Basic app:

Better app:

A #WPDev quiz

At NDC London this week, as part of the community area, WPUG ran a Windows Phone related quiz.

While you can't win "fabulous" prizes for taking part, you may be curious to see the questions and work out how you would have done if you'd been there.

You'll find the questions at http://wpug.net/2013/12/05/ndc-london-wpdev-quiz-questions/

Then, once you have your answers you can check them at http://wpug.net/2013/12/06/ndc-london-wpdev-quiz-answers/

Splash screens and interstitial ads

"The splash screen isn't displayed for long enough." It's something I've heard from clients and companies creating apps but never from the people actually using an app. To be fair I have heard people comment that an app shows a splash screen for so short a period of time it looks like the screen is flickering but that's a separate issue with a separate resolution.

Let's start with some history. Where do splash screens come from?

Many years ago, when computers were much slower than they are now and programs took a long time (relatively) to start up, someone had the idea to have the app display an image as the first stage in its start-up operations to give the impression and reassurance to the person who wants to use the app that it is loading. Over time the use of a static image was enhanced with animation and sometimes progress messages. All this was to reassure the person that the app/computer was doing something and to hide from the user that an app was taking so long to start.

Lets be clear, there was never a person who said I want an app to take longer to start or have an artificial delay between saying I want to use an app and actually being able to use it.

For many years, on the desktop, more and more apps started using splash screens and they started being displayed for longer as apps got larger and more complex, thereby taking longer to load.

For lack of a better option the splash screen would typically contain an app or company logo. Collectively, we became used to these "adverts" being displayed to us as we started apps. In fact some companies even began including their own adverts on their splash screens.

Over time and as application monetization models evolved, some apps began including full screen, or almost full screen, interstital ads when an app started. These would either be displayed for a fixed period of time or until they were physically dismissed.

That's all well and good, but what about Windows Phone?

The Windows Phone 7 application templates included a special file in the SplashScreenImage.jpg.

When an application was launched on the phone the OS would first look for the existence of this file. If found it would be displayed until the first "proper" page in the app was ready to be displayed. This was really useful as WP7 devices were relatively low powered and the application load process wasn't as optimized for speed as it is in WP8.

For the most part, the people developing apps would modify the image and the person launching an app would get a near instant visual response to launching an app. 

Some developers didn't modify the default splash screen image and their apps looked worse because of it.

With Windows Phone 8 a lot of work was done to improve the time it takes for an app to start. The improvements were such that they removed the placeholder image from the project templates. Partly as a way to highlight the improvement in start-up time and partly as a way to encourage the people creating apps to think about optimising the application start up experience with regards to what they're doing that impacts start up time too.

All this leaves us in a situation where a Windows Phone (8) app shouldn't need a splash screen. Apps should be developed to start quickly and get into a state where they are usable as quickly as possible.

However, many PMs, clients, marketing folk, etc. still have an expectation from history and the desktop regarding splash screens. They can think they're a necessity or something that should be included in every app. Then, when they are included we end up with feedback like the opening quote above.
Based on external and historical expectations, the requirement is added that the splash screen be displayed for a minimum length of time.
Depending on the ultimate owner of the app they may argue for the inclusion of an extended splash screen display duration (so it behaves like an interstitial ad) and you as a developer cannot persuade for an alternative. In that case so be it. For some people or companies the need to have a logo displayed to the person using your app is something they can't be persuaded against.

However as a developer interested in producing the best apps you are better able to do your job if you can explain why this may be a bad idea.

Let's return again to consider the person using the app. When they launch the app they're doing so because they want to use the app, not look at a logo. They've already probably just seen the logo anyway as it's on the tile, app icon or tile used to launch the app. I'd also assume that the person knowingly installed and launched the app and are aware of what it is and what it does.

If the person/company responsible is insecure about how the branding is reflected in the app then there are better and more appropriate things that can be done than just force the user to stare at a logo when they want to be doing something else.

Remember.

Just because things have been done one way in the past isn't always a good reason for doing them now. Especially when the reasons for doing them the old way no longer apply.

Think before you add a splash screen to your app.

Think REALLY carefully before adding an interstitial splash screen or other artificial delay to application start up.

Formatting the page title / application name

Have you ever looked at the text at the top of the page in an app and wondered why it didn't look quite right? Let me show you why.
Take a look at the three versions of "SETTINGS" here. They show how the page or application name is often displayed at the top of a page.

The one on the left is how it looks with the default Silverlight page template. The middle one is how it looks in the native settings application. The third is how I've reformatted the TextBlock in Silverlight.
Notice how the default Silverlight template is smaller and lighter than the native one.
Here's how that default template looks.

    <TextBlock Text="MY APPLICATION"
               Style="{StaticResource PhoneTextNormalStyle}"
               Margin="12,0"/>

[Line wrappings added to aid readability here - it's a single line in the template]

Firstly notice the redundant Margin that's specified in XAML. This is identical to the margin that's included in the PhoneTextNormalStyle definition. (For more on what's in the predefined styles see the Theme Resources for Windows Phone on MSDN.) The TextBlock would be displayed identically if the explicit margin definition was removed.
The PhoneTextNormalStyle template is not what we want here.

Here's how to adjust the styling so it looks more appropriate.

    <TextBlock Text="SETTINGS"
               FontFamily="{StaticResource PhoneFontFamilySemiBold}"
               FontSize="{StaticResource PhoneFontSizeMedium}"
               Margin="{StaticResource PhoneHorizontalMargin}"/>

Much better.

But, you may ask, what about the pivot control? That includes a Title template that by default is equivalent to the TextBlock we've been looking at.
In the below image I've added this as a second row on the right hand side. You'll notice it's identical to my above defined adjusted styling.

Make your app look like the native look and feel with the above FontFamily, FontSize and Margin settings. Fix templates, don't just rely on them or assume the defaults provided by the SDK are perfect.

Better alphabetic jumplist formatting

The following no doubt looks familiar to you. It shows the JumpList from the people hub. Recently I wanted to recreate this view in an app and was surprised at the lack of documentation available for recreating this view accurately.

Unfortunately the MSDN docs on creating a jumplist (from a LongListSelector) with alphabetic groupings leave something to be desired.

Here's what the formatting in the MSDN docs produce:

Admittedly I haven't done anything to improve the display of the names but hopefully you can see a lot of differences in the alignment, margins and spacing of the characters in the red boxes.

Unfortunately I've seen lots of apps which include something that looks like the above. I can't help but notice all the ways it varies from the native one. The lack of attention to detail it shows and the failure to craft something to be proud of is disappointing.

Here's my attempt:

As best as I can do it's pixel perfect ;) with the exception of the size of the globe icon which I've chosen not to resize and so left slightly larger than the native one. - It would be easy to make smaller if you wanted to though.

So how did I do it?

Firstly the formatting:

Also at https://gist.github.com/mrlacey/7779351

The picture converter is from MSDN and the JumpListItemBackgroundConverter is from the Toolkit.

Secondly a tweak to the CreateGroups method in the AlphaKeyGroup class:

    private static List<AlphaKeyGroup<PhoneContact>> CreateGroups(SortedLocaleGrouping slg)
    {
        var list = new List<AlphaKeyGroup<PhoneContact>>();
 
        foreach (string key in slg.GroupDisplayNames)
        {
            var k = key;
            if (key == "...")
            {
                k = "🌐";  // &#x1F310;
            }
 
            list.Add(new AlphaKeyGroup<PhoneContact>(k));
        }
 
        return list;
    }

If your browser has trouble rendering the globe character you may be able to see it better at https://gist.github.com/mrlacey/7779172

Let me know if you use this in your apps. :)

GenerateWinPRTManifestV2 error

Documenting this as Google was unable to find anything. Bing found nothing exact that matched but a few things that pointed me in the right direction.

I've had some "fun" trying to resolve the following error relating to the "GenerateWinPRTManifestV2" task during build.

Error 255 The "GenerateWinPRTManifestV2" task failed unexpectedly.
System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.CCIHarvestRegistrationInformation(ProcessWinmd processWinmd, Dictionary`2 inprocServers)
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.UpdateWinmdRegistration()
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.ExecuteImplementation()
   at Microsoft.Silverlight.Build.Tasks.GenerateWinPRTManifestV2.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()

It turns out that there were two projects referencing different copies of the same library and MSBuild wasn't able to differentiate between them. (They weren't strongly named.)

The fix was just to make sure that all the projects in the solution only use one version of any library.

I hope this helps save someone else some time if they hit the issue and end up searching for the same task name.

Remember. Strong names FTW!

'tis the season to...release apps

We're fast approaching the time of year when more people are releasing and updating apps in time for the big shopping holidays (Thanksgiving & Christmas).

The store typically takes at most 5 working days for processing submissions but they have advised that due to traditionally larger volumes at this time of year things may take longer than usual*.

The announcement was made in the Dev Center forums but you may have missed it. (Don't feel bad, I don't monitor the forums too carefully either.)

If you want the app certified by Thanksgiving, you should submit it by Wednesday, November 20th.

If you want the app certified by Christmas, you should submit it by Monday, December 16th.

If you want the app certified by New Years, you should submit it by Friday, December 20th.

Of course submitting early won't hurt and meeting these dates still doesn't guarantee it will pass certification if it doesn't meet all the requirements.

* For reference I submitted an app on Sunday just gone and it was ready this morning. Taking approx. 4 days.

Be careful about when you interrupt your users

It's common to want to ask your users something. Maybe you want to prompt them to rate your app, provide feedback or update to the latest version.
The way I see most people do this is with a MessageBox being displayed when the app is launched.

I don't think this is the best approach.

I hope you're creating apps with the user and what's best for them in mind.

When a person starts your app they probably have a task, goal or purpose in mind. People don't launch apps to rate them or send feedback, although the desire to do this may come up while they're using the app.

By prompting the user to take some action that you want, you're putting a barrier between them and what they really wanted to do when they launched the app.

Adding a minor frustration just before you ask for a review may not be the smartest thing to do.

I suspect that a better approach would be to prompt the user with such requests when they've done what they launched the app to do.
For some apps it may be harder to identify just when the user has completed what they wanted to do.
As a general rule, prompting when a person leaves the app, rather than when they start it seems to make more sense to me.

Thoughts?
I'd love to hear from anyone who's experimented (and tested) in this area.

Sharing a resource with a TextBox.CaretBrush can cause some weird behaviour

I think I've found another bug in Windows Phone but it seems really odd.
I'm documenting it here before escalating to find out if it really is a bug but I can't believe its intended behaviour.
Maybe you have an idea or explanation as to why this is happening? If so, do please share.

Have a look at this code:

It creates a page that looks like this:

The thing to note is that the CaretBrush on the TextBox, the Foreground on the Button, the Foreground on the first TextBlock and the Fill of the Rectangle are all bound to the same resource.
This is exactly the sort of thing I'd expect to see when wanting to apply the same colour to multiple elements on a page (or app).
What's probably unusual, or somewhat of an edge-case, is setting a custom colour for the CaretBrush, although this is often necessary when using a heavily customised UI. (That's where I first discovered this. - The above is the simplest reproduction I could find.)

So what's special, well, the caret (if you're unfamiliar) is the little line in the TextBox that flashes to show you the edit point when the control has focus.
The odd thing here is that rather than just the caret flashing, in the above example everything with the "colour" bound to the same resource as the CaretBrush flashes too. That what the right hand image shows.

This can be quite an odd experience when you see seemingly random elements on a page start to flash while typing into a TextBox.

Fortunately the fix is easy. It's just to not bind the CaretBrush to the same resource as anything else.
Of course this means you will have some otherwise unnecessary duplication in your XAML though.


My guess is that there's something odd internally with the way the TextBox finds the caret so that it can cause it to flash. If not that the the Brush is remembering the items that reference it in an incorrect way. Either of which are very odd.
I'd love to hear any thoughts on this and will report anything I hear back from official channels.


*** UPDATE ***
I've had it confirmed that this is a very old (over 5 years) known bug with the Silverlight TextBox control. One to be aware of if heavily styling a TextBox and easy to work around.

Why ShellToast may be blank

Just made a discovery that may be worth noting.

If creating a ShellToast with a Title of more than 64 characters (including any whitespace) then the toast will be displayed but the title will not be shown.
If Content is specified this will still be displayed. If no Content is specified then the toast will just include the application icon.

This is both undocumented and unexpected behaviour.
It's particularly unexpected as deliberately specifying an empty string for the title causes an error.
I'm not sure if this is a bug or a built in back door to avoid displaying the title. Either way this worth being aware of when working with toasts.

Why Windows Phone developers should care about large screen devices

Yesterday, in an article on Mobile Industry Review by Stefan Constantinescu, he made reference to a survey carried out earlier this year by Open Signal.
That survey discovered that people with devices with larger screens download more data.

"[with] each additional square inch of screen ... 288 MB more data [was] downloaded per month,"

What does this survey mean to Windows Phone developers?
The survey is based on Android users so there's an argument that it might not directly apply. I don't see a big issue with assuming that the results of the survey can be universally applied. Anyway, it's not as if such a survey is really possible of Windows Phone users just now as the range of devices currently available would prevent such a survey being possible.

Why might this be the case?
Why would people use more data (over Wi-Fi) with larger screen devices?
I can imagine a couple of reasons:
1. Apps (and websites) may be downloading larger assets (images) on larger devices to prevent the best looking content to the user. If this was really the case then I'd expect increased data usage not only on Wi-Fi though.
2. People usage larger devices differently to smaller ones. We "know" this. But sometimes it's easy to forget. Different sized devices are used by different people, in different ways and at different times. Larger, handheld devices are used more for consumption than a "phone" traditionally is.

Why should Windows Phone developers care?
Nokia's new Lumia 1320 and 1520 devices will be available shortly. They are considerably larger than the Windows Phone devices currently available and so are likely to be used in slightly different ways and the above survey results may apply.

What can we do with this information?
Regardless of personal opinions about so called "phablet" devices it's worth remembering that some people like them and that they may use them differently to traditional phone size devices.

It might be tempting to assume that more data usage means more apps are used. I don't think this is the case.
I'd expect that apps are rather used for longer as is the pattern for larger tablets compared to phones.

If you're a developer working on a Windows Phone app that is focused on data consumption then the above survey should help confirm to you that making sure the app can provide the best experience on ALL devices is in your interest and that of your users.

Stopping a live tile from flipping

Sometimes you may want to remove the contents (and images) from the back of a [flip] tile to stop it flipping. How to do this isn't always obvious and it can be frustrating to discover that just setting the content to an empty string or null doesn't work.

To stop a tile from flipping you must clear it’s content, not just set it to an empty string.

Unfortunately the FlipTileData class doesn't provide a method or property to make this easy. Instead you must use an XML document that contains appropriate FlipTileDate template information.
Something like this:

var clearTileBackXml = new StringBuilder();

clearTileBackXml.Append("<?xml version=\"1.0\" encoding=\"utf-8\"?>");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");
clearTileBackXml.Append("");

var ftd = new FlipTileData(clearTileBackXml.ToString());

ShellTile.ActiveTiles.First().Update(ftd);

If you’re updating anything other than the primary tile you need to set the Tile ID in the XML as well as select the correct element from the ActiveTiles collection.

For more info and to see the full template go to MSDN.

Why MP3s may not play on Windows Phone

What follows is the result of at least 4 man-days worth of effort involving at least 6 different people. It ended with a solution that had people in disbelief at the simplicity of the workaround and the probable cause.

For the most part playing music from within an app is simple and there are lots of ways to do it: background audio; MediaElement; or launcher.

Sometimes things go wrong though and last week was one such time. I was asked to look at a bug in a new app that plays music. The bug was that for some tracks there is an obscure error when playing from isolated storage. If the file is copied to the PC from isolated storage then it plays fine though.

In the exception, with it's entirely external call stack, we could see a HRESULT of 0xC00D36C4 or a message of -1072875836. Neither of which are particularly helpful.

Even the internet couldn't give us much help. All we could find was a constant name of MF_MEDIA_ENGINE_ERR_SRC_NOT_SUPPORTED for the hex value but that was in a streaming video context. This didn't really help at all.
Beyond that we found records of bugs relating to playing some audio files on Windows Phones but these had all been closed and marked as "no repro".

I looked at files sizes when the tracks were downloaded on the phone and on a PC and everything looked the same.

After much experimentation I realised there was a step in our reproduction process that hadn't been fully explored.
When files are saved on the phone they were given name based on their identifier. This meant that in IsolatedStorage they looked like: "/tracks/tr123456".
When copied to the PC we were renaming the file to include an extension (of ".mp3") so we could double click them to try and start playback.
Starting to approach the limit of possibilities, I wondered what would happen if we tried to play the file with the ".mp3" extension on the phone. Low and behold the track started playing on the phone without issue.

So, the fix?
Just make sure that the files all had a ".mp3" extension on them and they all played fine. Yes, really that simple.

Why does this solution work?
Here's what I think is happening:
Without a file extension to tell the internal media stack what format the file is it guesses, probably based on looking at part of the files contents. In the instances where the file will not play correctly it is probably assuming that it is not a regular MP3 file, even though it is, and so tries to play it assuming a different format.
I must admit that my knowledge of the internals of the MP3 format is non-existent and my knowledge of the internals of the media playback stack is even smaller but this seems to be the most likely theory.

What can we learn from this?
Always include a file extension on your files. Not only does it make it easier/clearer for people to see what type they are, it also help the OS know how to read/play/process them.

Really glad to see all that PhoneGap effort paying off

If this comes off as a bit self-congratulatory then so be it. Sometimes my trumpet needs blowing and there isn't a big queue of people lining up to do it for me.

Earlier this year Microsoft ran a competition (challenge) to bring existing apps built with PhoneGap (Apache Cordova) to Windows Phone.
Recently, Microsoft highlighted and interviewed the winning apps again.

I'm especially pleased to see this.
Back in the summer of 2010 (yes, so long ago) I spent some time building what became the Windows Phone version of PhoneGap and then Cordova.

Honest. Look, here's a screenshot of the network graph from GitHub.

This was done at a time when there were questions about the ownership of the apps I built in my own time, with respect to my then employer.

Rather than spend my time building apps I might have to argue for ownership of I spent my time on other things. I spent a lot of time answering Windows Phone related questions on Stack Overflow and working on open source projects like the WP7 verison of PhoneGap.
I was familiar with PhoneGap from having used it to build iPhone apps in 2009 and saw that it would be beneficial to Windows Phone as a platform if it was easy for existing PhoneGap apps  to be repackaged and retargeted at WP. As there wasn't anyone else working on it at the time I decided to step up.
Unfortunately the performance of hybrid apps on Windows Phone 7 was a long way off that of native apps which greatly affected it's adoption. Fortunately things greatly improved with Windows Phone 8 and more apps are now being built and ported over from other platforms.
While I was only involved at the beginning when it came to the amalgamation of Windows Phone and PhoneGap/Cordova I still like to think I played a part and remember fondly the work I did at the time.

I look forward to seeing more great apps being built with PhoneGap in the future. :)

App Studio has been updated and shows some improvements

Having been critical of App Studio in the past and noting some of its short comings, the fact that it was recently updated deserves a review of these latest changes.

Rather than revisit the app I produced as a test previously I decided to go through the whole process of creating a new, minimal, app of the most basic variety. An app that just shows content from a single RSS feed.
For fun, this time, I've built it based on this blog. Not really a site that would justify and app but a fun source of content for me to play with.

First the good news
There are definitely improvements in the apps being generated now.
The biggest improvement is the offline/data caching support.
In turn this means that the apps that are generated could be submitted to the store and should not fail store certification testing.
There are also additional configurable options on the site which adds further improvements to the generated apps.
The generated code also no longer includes unused additional libraries. This brings down the size of the XAP file and in this instance smaller is better.

The bad news
Things are still far from perfect. Here's a few of the most obvious things I noticed:

 

 

• Images aren't well formatted. It appears that a square version of images is created for reuse and this is used regardless of where it's displayed in the app. The square image is also very small and so can be hard to read when scaled up. Especially when the image is tapped to show a larger version.

• On the page showing details all text is in a single control. This suffers the limit on the amount of content that can be displayed in a single control and so some of the text isn't visible.
• The alignment and spacing on this page is also consistent.
• If scrolled part way down an article/story/post and then you swipe to the side to go to the next article the scroll offset isn't reset so the new article is displayed part way down.
• The details page contains the same page header as the panorama. This is unnecessarily large and a waste of space by providing undue prominence to the screen element that probably isn't even needed on the page.
• Reading of articles (via TTS) still doesn't have a way to stop the reading once started and selecting it multiple times will queue multiple readings of the story.
• Pinning an article still creates a poor quality live tile. (If I don't blog about live tiles more soon - pester me about this.) There also isn't anything to tell you when an article is already pinned. Trying to pin it again just does nothing.

• The spacing between articles isn't consistent. Presumably because whitespace at the end of the snippet that is displayed isn't being accounted for.

 

• The "go to source" link from the app bar which should take the user to the original article in the web browser doesn't always work correctly. It appears to just be using the first link in the source XML but this isn't always the one you want. In this instance it's the "application/atom+xml" link to post comments. As you can see from above this doesn't lead to the appropriate content being displayed.
• This incorrect link is also picked up when trying to share the article/link.
• In terms of sharing: Sharing a link populates the message with much more text than can be supported by many of the share services, such as Twitter and its 140 char limit. When sharing a status or by email the default message includes the HTML from the original article.

These are all simple issues that should be trivially simple to identify and hopefully they are already in a bug list somewhere. If not, I can only figure it's because they're having as much difficulty hiring testers with Windows Phone experience as I know a number of other companies are.


The reality
I've only looked at a tiny part of what's possible with App Studio but what I have looked at is amongst the simplest of things that are possible in an app and even basic things like standard alignment and spacing aren't correct. This doesn't encourage me that the more complex elements and functionality are better implemented.
App studio is still a very long way off producing something that is anything but basic without further modification. But it's not all bad and still in development so further improvements should be coming.
Having such a tool is a great start in terms of having some code as a starting point for building upon, but, alas this is not all that it's being used for.
I have a feeling that this tool is seen by some within Microsoft as a quick and easy way to help boost the number of apps in the store. Unfortunately I don't think that consumers want a load of generic apps. Just filling the store with them only really helps the people who get measured on the number of apps in the store.

What the tool really needs is a guide to go with the generated xap/code with more detailed advice on how, why and where things could and should be changed to help make a high quality app. While the studio is in such a state of flux and development such documentation would be impractical though. Hopefully such a guide will be produced once App Studio gets out of beta.


If only I had the time to fix all the issues...or even just point them all out. :(

Stop submitting App Studio created apps to the store - you're just highlighting the poor test process

App Studio is a tool from Microsoft that will allow you to "take your app from idea to Windows Phone in record time". Unfortunately the apps it creates shouldn't pass the store's certification testing.

App Studio is still in Beta but already many people are using it to build apps and submit them to the store. Seems reasonable enough as that's what it's for. The only issue is that the apps that it generates contain bugs that mean they shouldn't pass the testing that is done as part of the application certification process. Every time such an app is certified it highlights a failing of the publisher and the store test processes to identify the issues and stop them reaching the consumer.
Even if the person using the app can get past the, arguably, poor design of the generated apps, no one deserves an app that crashes.

So what's the issue?

We'll, the biggest and easiest to demonstrate is an issue that should cause the app to fail the technical certification requirement 5.1.2:

The app must handle exceptions raised by the any of the managed or native System API and not close unexpectedly. During the certification process, the app is monitored for unexpected closure. An app that closes unexpectedly fails certification. The app must continue to run and remain responsive to user input after the exception is handled.
Recommendations
When handling exceptions, an app should provide a user-friendly error message. You may present a message that is relevant to the context of the app.

So how do the apps fail this requirement?
Just follow these simple steps to recreate a crashing scenario:

1. Launch the app
2. Tap on an item loaded from the internet.
3. Pin that item (via the link in the app bar)
4. Disconnect the phone's network connection (enabling flight mode is easiest)
5. Tap on the pin created earlier.
6. Observe the app open for a few seconds without displaying any content before crashing/closing.

I documented this and other issues previously but they all appear to still exist.


Two important lessons:

1. Don't assume that a generated app is good enough to release to the store. Test it thoroughly yourself!
2. All apps will be used in an occasionaly connected environment. You MUST test the apps behaviour in all network connection scenarios.

If you want to use App Studio then by all means go ahead. Just be aware that if you want to submit the generated app to the store then be aware that there will be a need to modify the generated code before you do.

Fixing the styling of the WPToolkit ToggleSwitch

If you've ever done any XAML based development for Windows Phone you'll be aware of just how essential the WPToolkit is.

One of the most popular controls contained in the toolkit is the ToggleSwitch. Unfortunately though, its default styling doesn't play well when you want to use it with custom foreground and background colours.

Looking at this image we can see the same page in both light and dark themes. (At 50% in Blend)
The first pair of toggleswitches show the checked and unchecked states with the default theme colours.
The second pair shows what happens if with the default styling when the background and foreground are modified though.
This is almost certainly NOT what you want to see.
With a modified foregound and background I'd expect you want to see something like in the final pair of switches.

So, how to get the toggleswitch to display "properly"?
It's just a case of modifying both the `toolkit:ToggleSwitch` and the `toolkitPrimitives:ToggleSwitchButton`.
Add a `Foreground` reference to `ToggleSwitch` and then replace all the StaticResource references to PhoneForegroundBrush and PhoneBackgroundBrush with TemplateBinding references to `Foreground` and `Background`.
If that sounds complicated, don't worry. You can just copy it from https://github.com/mrlacey/WPMisc/blob/master/ToggleSwitchStyling.xaml (Which also contains the xaml used to create the above images.)

If you've developed an app where the toggleswitches look like the middle pair you now know how to update them.
Similarly, if you know of any apps where there are toggleswitches look like the middle pair above, point them to this article. :)

Portable Class Libraries (PCLs) now on all platforms

If you care about the legal issues of redistributing third party libraries - which of course you should - this is huge news.

Earlier this week Microsoft announced that the platform restriction on using portable class library reference assemblies on non-Windows platforms has been removed.

PCLs are a great invention. They allow us to create assemblies that can be used on multiple platforms. This means I can bundle up some code and refer to it from a Windows Phone app, a Windows 8 app, a website, a desktop app and more.
This means I can reuse code without having to test it on each platform.

PCLs are great. However there was one big issue. If I was also building an app for a non-Windows Platform such as Android or iOS using the Xamarin tools then, legally, I wasn't allowed to distribute those libraries. At best that was a bit of an inconvenience. Fortunately now this issue has gone away. You can now build libraries you can share with apps running on all platforms without that particular legal concern.

Note that this is on the newest release of the assemblies only so make sure you are using those when distributing to anything non-Windows.

Alternatives to long web requests with long timeouts

Earlier I posted about how you can't create a web request with a timeout of more than the internal maximum of 60 seconds.

I was asked on Twitter about how to have the server tell the app that there was new data for the app to display.

As I said in the original post, the exact method to use will depend on the application but here are the main techniques to consider.

Direct notification
If the app is still running and the server has some new data for the app to display the server can tell the app directly. Either by telling the app to get it or sending it directly.

• Via a push notification (raw or toast)
• Via a socket connection - like with SignalR ;)

Smart polling
Having the app just check if there is new data on a predetermined periodic basis isn't the best we can do.

• If we've told the server we want some data and the server is indicating that it will be some time before the data is ready, the server should be able to provide an indication of how long it will be before the data is ready (based on typical load time, current queue size, etc.) The app can check back after that time. And, of course be given a new time if it isn't ready by then.

Offline notification
Of course if the server is taking it's time to generate (or prepare) the data the app needs then it's possible that the app might not still be running when the data is ready. In this instance the server may want to tell the user that there is data to view when they re-launch the app.

• The obvious option here is with push notifications (toast and tile)

But less platform specific options may also be valid too. Especially if combined with a custom schema to launch directly into the app.

• SMS
• Email

Of course a better alternative to any of the above would be to have the data ready when the the user/app wants it. This could be done either by preparing the data in advance so it's ready when needed or by being able to prepare it very quickly.

Get GRD3 now, in just 3 easy steps

If you're a developer and want to get Windows Phone 8.0 Update 3 on a device now, just follow these simple steps.

Step 0 - Make sure your device is developer unlocked. I'm assuming that as a developer you already have this, but it's probably worth noting.

Step 1 - Download and install this app: http://www.windowsphone.com/s?appid=178ac8a1-6519-4a0b-960c-038393741e96

Step 2 - Got to settings on the device and check for updates: It should find and download this:

Step 3 -Select "install" and wait. You'll see the spinning cog icons and a progress bar. It took just 7 minutes for me.

Done!

Making web requests with long timeouts on Windows Phone

It's quite common (I've seen/heard it several times) for people to want to make web requests from their app and have a very long time out. I.E. a timeout longer than 60 seconds.

Despite what you try there's no way to do this though.

That's right. Internally your web request will time out after sixty seconds. This means that while you can create a shorter timeout, you can't create one longer than this.

This shouldn't matter!
60 seconds is a lifetime on a mobile device. As a user, would you want to stare at your device for over a minute while your wait for new data to be loaded? Of course not.

But what if the server takes a long time to generate the data to return?
Then I'd suggest that this should be addressed in different ways:

• Have the server process faster.
• Have the server return some of the data initially while it prepares the rest for later.
• Have the server return some cached data while it gets the latest.
• Have the server push the data when it is available rather than relying on the app making requests for it.

Ultimately the "best" solution for this scenario will depend on your app, the data and the server. What you shouldn't do though is have the person using your app wait any longer than they absolutely have to.


Update: See a follow up post at Alternatives to long web requests with long timeouts

IE credential caching in Visual Studio (Error: F30063)

I get to work on a bunch of different projects that are stored in different Version Control systems on different servers. For the most part this is fine, despite the fact that Visual Studio (2012 - it may be better in 2013) doesn't like it when you have multiple instances open and they're connecting to different TFS servers.

Anyway, this morning I was trying to connect to open a project on a machine I hadn't used before. I did this by going to the TFS web portal and clicking on the "Open new instance of Visual Studio" link. Unfortunately, rather than seeing the project open in Visual Studio I was presented with this:

TF30063: You are not authorized to access https://XXXXXXX.visualstudio.com/defaultcollection.

After much investigation it seems that while I was viewing TFS in IE with one set of credentials, the embedded browser within Visual Studio was previously logged in to a different TFS server with a different set of credentials. As the set of credentials cached/remembered in VS weren't valid for the new server I got this error.

Simple solution:
Open the web browser window in Visual Studio.
Log out of the old server and log in to the new one with the correct credentials.
The "Open new instance of Visual Studio" link now works.


I hope this knowledge being documented here helps someone else avoid this issue or solve it faster than me if they do hit it and then find this post.

Gotcha when adding a Resources library to a project

Here's a fun fact I've just spent half an hour learning. Hopefully knowledge of it can save you some time in the future by avoiding the same issue.

"Resources" is a special (reserved) name when it comes to including things in a XAP file. If you name a file "resources" it will never be included in the XAP. (Noted thanks to this answer on StackOverflow)

Additionally (and this is the bit that caught me out) any file that ends ".resources" is also not included.

I had a library named like "MyApp.Resources.dll" that is referenced by my app but just wasn't being included in the XAP and so was leading to a spurious FileNotFoundException when running the code.
Fortunately it was just a case of renaming the outputted assembly to "MyApp.Res.dll" and all was fine again.

I hope this knowledge can save someone else from being caught out by this same issue.

How to put content on a lock screen image so it doesn't overlap with the text

I'm posting this for me own reference as much as for anyone else. ;)

When wanting to add lockscreen support to your app there is lots of useful information available about how to do this technically. Unfortunately there is little information about what you should put on the lockscreen or how you should position it to avoid it crashing into the text that may also be displayed over the lockscreen.
Today I'm going to look at the second of those issues.

Fortunately there are some values you can use to be sure your content won't overlap the text you can't control.
The values you need for WVGA screen devices are:
Left margin: 24px
Top margin: 56px
Space to use: 288px by 288px

If you're creating larger images for bigger screens that you don't want to be autoscaled then the values you need are:

For WXGA:
Left: 58px
Top: 90px
Space: 460x460px

For 720P:
Left: 36px
Top: 84px
Space: 432x432px

Here's an image to show the 720P values in situ.

At some point in the past I grabbed the above from a screencast. Sorry, I can't remember exactly where it's from but I think it was the Windows Phone design team. If anyone can help me point to the source that'd be great. Thanks :)

Of course, you may need to allow for variations due to language differences:

Linking to your app in the store

It's easy to create a link to an app in the store.
You just view it in a browser and then just copy the URI and then you can paste it for all to reuse. Don't you?

NO!

Unfortunately it's not that simple.
Let's consider the URI for the popular app, Facebook.

http://www.windowsphone.com/en-gb/store/app/facebook/82a23635-5bd9-df11-a844-00237de2db9e

The above is what I see. Notice the bit in bold? "en-gb" that's region specific and because the site knows I'm in the UK.

If I was I was in the USofA (or it didn't know where I was) then the "en-gb" would be "en-us". If I was in Finland then it'd be "fi-fi", etc. In theory this is a good thing. It means I can point people to appropriate, region specific, versions of the apps page so they can, if need be, see it in their language. Plus it lets me check how an app is displayed in different regions/languages.

So what's the problem?

The problem is what happens when trying do install an app from a region specific link that isn't your region.
Clicking install is fine, but then you'll see a screen like this.

That's not good.
But it's just an extra step as the user is redirected to their own regions store page. No big deal. Right?
In fact there are two problems here.

1. This is an extra step in the process. One important fact about the number of steps involved in a web based purchase is that the more steps there are the number of people who complete the process gets lower. In fact, taking steps out of a process means more people will complete it. Conversely, adding steps means more people don't complete it. (As an aside, this is one of the reasons that Amazon's 1-click purchase option is so important to them.)
   If someone has started the process of beginning to buy/install/download my app I want to do everything I can to help them to complete the process. It's worth money to me.
   While I can't change the windowsphone.com site, I can help potential customers avoid this situation by making sure they don't go to the wrong region in the first place.
2. Notice the text in the above screenshot. Particularly the term "buy". If I had a free app that someone was attempting to install I'd be worried that the introduction of the term "buy" would introduce doubt into their mind about what they were doing.
   "I though this was a free app. I don't want to pay for anything. Perhaps I'll stop."
   I don't want anyone who has expressed an interessed in installing one of my apps to end up thinking this.

So what can be done about this?

Fortunately there is a solution. 

The site provides a way for having a region agnostic URI that links to an app. These take the form:

http://www.windowsphone.com/s?appid={GUID}

So, for Facebook it'd be:

http://www.windowsphone.com/s?appid=82a23635-5bd9-df11-a844-00237de2db9e

It's very similar to the original one above as the largest part of the URI is the GUID anyway.

Just make sure you give people the region agnostic link when promoting your apps.

Does this really matter?

Well, in the grand scheme of things there are more important things to consider in terms of building and promoting a great app but it's so small it's easy to get right.

What about on device links?

On device it's a better story. Windows Phone will detect you're navigating to an app in the web version of the store and redirect you to the store app. At which point there are no region specifics to worry about other than the availability of the app in your region. If it's not available to you then you wont be able to purchase it regardless.

Again, this is so easy to do correctly and ensure a good experience for people who are viewing, and hopefully, ultimately, downloading your app then there should be no excuses.