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.