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