Matt Lacey: Awesome with Windows Phone

Renewing a Windows Phone developer subscription with an MSDN token

2013-06-15T14:10:00.001+01:00

For the last 3 years I've paid (yes, with real money) for my Windows Phone developer subscription. As I've just come up for renewal again I wanted to use the token I get as part of my MSDN subscription (that I also pay for).

In the phone dev centre there was a nice link prompting me to renew. On that renewal page there was an option to pay for renewal or enter a code. Obviously I wanted the "enter a code" option but where to get that code from? Unfortunately it wasn't as easy to find as I would have liked so I thought I'd share it here.

It's actually quite simple (once you know how)

Log into your account on msdn.microsoft.com.
Got to https://msdn.microsoft.com/en-us/subscriptions/manage/
Under the Subsccription Benefits find "Windows Phone developer account"
Click on the "get code" link to reveal your code - it is a GUID
Enter that code (GUID) in to the phone dev center renewal page.
Done!

Hope this helps.

ShellTile.ActiveTiles sometimes forgets about one of the tiles

2013-06-12T22:22:00.001+01:00

A couple of times, when working with an app with lots of tiles pinned, I've seen `ShellTile.ActiveTiles` "forget" about one of the tiles. By that I mean that when updating all the tiles from a background agent one of them isn't updated.

This is with code like:

    foreach (var tile in ShellTile.ActiveTiles)
    {
// update the tile.
    }

At the moment I only have anecdotal evidence of this behaviour but wondered if anyone else could shed any knowledge or experience of this while I continue to investigate.

Deleting and repinning the tile in question seems to make the problem go away but this isn't a real solution.
Additionally it doesn't seem like it's the first or last created pin but I can't be sure of this.

Has anyone else seen this?

LongListSelector does not "play nicely" with a static DataContext

2013-06-08T12:35:00.000+01:00

Here's a lesson from a day lost to debugging an obscure issue.

Microsoft recommend that you should "use the LongListSelector instead of ListBox for phone apps".

That's great advice, especially if upgrading an existing app where ListBox wass used previously. But there's a gotcha you may need to be aware of.

If a LongListSelector is bound to a static ItemsSource then a reference is held that stops the page being collected. This means that such a page would leak memory!
If it's a large or complex page or one that is opened a lot (so you end up with lots of copies in memory) this could be very bad for your app.

This doesn't happen when bound to a non-static source. It also doesn't happen when using a ListBox bound to either a static or non-static object.

If you're upgrading an app built several years ago when using a static view model seemed like a not unreasonable way to architect an app you may be more likely to hit this. (That's why I discovered the issue-when upgrading an app originally written in 2011.)

Don't believe me or want to see this in action for yourself?
I've put a project at https://github.com/mrlacey/WPMisc/tree/master/LlsStaticTest which demonstrates all the above.
It allows opening of pages which contain:

a ListBox bound to a static object;
a ListBox bound to a non-static object;
a LongListSelector bound to a static object;
a LongListSelector bound to a non-static object;
and a way to force garbage collection.

Each page also outputs creation, navigation and destruction information to the debug window.
To see this in action, open each page then tap "FORCE GC" twice and you should see the destructors for all but the static LongListSelector page being called.
You can also see the same by running the app through the memory profiler but I think it's easier and faster to see this problem via the debug output.

There are two ways to address this issue:

Remove the use of a static view model. Depending on your application this may or may not be a viable solution but I would recommend against using a static view model whenever possible.
Remove the binding when backing out of the page. It feels slightly imperfect but works and is easy to do.

To remove the binding when leaving the page, just do something like this.

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
    base.OnNavigatedFrom(e);
 
    // The following removes the binding of the LLS to the VM
    // so the page can be collected
    if (e.NavigationMode == NavigationMode.Back)
    {
        this.DataContext = null;
    }
}

Note that this is done in OnNavigatedFrom and not in OnNavigatingFrom as if done before you have navigated away from the page the removal of the binding may cause the UI to update and you may see screen flicker before the page closes.

This discovery was found via a lot of experimentation, insight and a process of elimination.I couldn't find any indication of what was holding a reference via the profiler. If you know where this would be indicated (or even hinted at) I'd love to know.

App store credibility

2013-06-08T09:14:00.000+01:00

I'm thinking out loud here. If I wander I'm sorry. If I cause you to jump to conclusions, please don't attribute them to me if they're your conclusions rather than mine.

Do apps that get featured in the marketplace/app store matter?
It's been well documented that being featured in the store directly leads to an increase in downloads. In that respect, being featured matters to the person who owns/created the app. But I wonder...

Do they have a bigger impact?
Do featured apps impact more than just those who created or downloaded the app?

Does the quality of a featured app impact opinion on other apps?

If it's the featured app I'd expect it to be either highly popular or (and hopefully "and" as well) of a very high quality.

If a featured app isn't very good (however that's defined) isn't it reasonable to assume that, as a consumer of apps, I should not hope for very much from other apps either? Afterall isn't the purpose of a featured app to highlight something I may want to install and use? Why would something that isn't very good be featured?* You want me to install crummy apps that aren't as good as others which do the same thing?

I see many featured apps that aren't very good, do not give me confidence in the general quality of other apps, are buggy or otherwise very poorly designed. :(

And a related question:

Does the credibility of the store affect apps? and the platfom?
Let's take, as an example, a recently featured app.
I'm anonymising the app in case my comments are taken as being focused directly at the app. That's not my aim. I'm trying to look at the wider picture.

It had no description (just the default text of "Check out this Featured App of the Day!") and a single rating.

That's right the app that the store thinks I should know about today, because it's good, relevant to me or in some other way useful has only ever had a single review. That's not encouraging, because we konw that ratings are a two part feedback mechanism. The number of ratings is an indicator of the number of people who have also used that app - there are very, very few apps with large numbers of users and very few ratings. The average (mean) value of the the ratings (subject to skewing from a small sample size) gives an indication of the quality of the app.

So, from that we can infer that the "best" app in the store today has a small user base. But maybe that's because it's new. Nope. It's had 5 updates and the last of which was 8 months ago.

Maybe the featured app is being targetted directly at me based on some heuristics or algorithm based on my other app and device usage? I doubt it and I hope not because if that's the case the algorithms are way off.

And what of that review:

I've anonymized it because the app in question doesn't count and the review included three potentially offensive words which weren't filtered or masked by the store.

I find the ratings count potentially confusing. It says there was one 4 star rating but we can only see one review. There's lots of potential here for confusion. Can't the store count? And if not what confidence should I put in it?
Actually zero star ratings aren't included in the average. If they were there would be 2 ratings with an average of 2 stars. This would bring average ratings down and so, while potentially misleading, ignoring them improves the overall perceived quality of apps. - I'm not sure what I think about this.
This is a consequence of there not being a way to actually give a no star review because the interface for leaving reviews and ratings doesn't have a way to distinguish between a rating not being left and a rating of zero. Ignoring no star ratings may be preferable to including the scores from reviwers who forget to give a rating though. I don't have the figures to say if this is an issue. I bet the people who are genuinely wanting to leave no star reviews (like the one above) are disappointed their rating is ignored though. Do people realise that zero star ratings are ignored and if you want to rate an app badly you must give it a 1 star review?
Anyway, I think I'm getting off topic.

If the store doesn't look great (i.e. doesn't appear to be able to count) then won't your opinion of the apps it sells be tainted? When you buy something from a physical store does that affect your opinion of the products you can buy in that store?

And what about the store as an app. The quality of it, like any app, impacts the perception of the platform. It's easier to say "that phone's rubbish" rather than "app X on phone Y is rubbish" or "it's hard to find good apps on phone Y".

Am I against apps and their developers getting promotion?

No, I want people to create successful apps. But I'd rather they had an awesome app that was successful, offered real value, helped people and showed what was possible with an app.
The quality of apps impacts the whole ecosystem and that in turn affects all of us, both the consumers and creators of apps.

* I'm aware of some of the finer points about what is featured and the business deals and implications that impact marketplace promotion. I've just chosen to ignore them for the sake of this post. They don't impact every featured app and would just serve to complicate the above thoughts. Anyway - my blog, my rules. ;)

New business cards :)

2013-06-03T20:39:00.001+01:00

I've given them an update and added some new background colours. :)

Nothing really to see here. Feel free to move on.

Win phones for getting your PhoneGap app running on Windows Phone

2013-05-28T22:01:00.000+01:00

Built an app with PhoneGap? If so you could win a phone and a Surface if you also release it for Windows Phone.

Just head on over to http://www.phonegapwpchallenge.com/ for more information.

Almost 3 years ago I made the first port of PhoneGap to support Windows Phone. I know it's a popular subject as it's the most popular subject here on my blog. Since then PhoneGap has taken on that code and and incorporated Windows Phone (7 & 8) as an officially supported platform and Microsoft have helped too.
While there have been a number of apps built with PhoneGap so far but it'd be great to see a lot more there. Afterall, that's why I did all that work in the first place.

Want to build an app, but don't know what?

2013-05-21T11:48:00.000+01:00

I've spoken with a number of people recently who want to build an[other] app but they don't know what.

Does this sound like you?

If so, check out IdeasProject.

Officially:

IdeasProject is an online global community of people who have a passion for brainstorming and creating innovation. The community enables the exchange of ideas among mobile enthusiasts, designers, developers and incubators. IdeasProject is based on co-creation through Open Innovation and has delivered consumer inspired applications and mobile technologies.

What that means is it's a place where people with ideas go when they want help to help with developing an app.

If you're stuck for ideas it could be just the palce for you.

Also, if you're a member of DVLUP then some of the suggestions from IdeasProject become challenges there, which can help you earn extra XP which in turn can be exchanged for "fabulous" goodies.

Champions, Ambassadors and MVPs

2013-05-14T02:07:00.000+01:00

Nokia and Microsoft use these titles to identify certain people and reward certain community members. Quite what the different terms mean can be confusing though. Let me clarify.

Nokia Developer Champion
Someone who does not work for Nokia but is recognised by them as an exceptional member of the developer community.

Nokia Developer Ambassador
Someone who works (usually part-time) for Nokia with a responsibility for helping people create apps.

Microsoft Valuable Professional (MVP)
Someone who does not work for Microsoft but is recognised by them as an exceptional member of the developer community

Microsoft Windows Phone Champion
Originally this term referred to people who work for Microsoft who could serve as a point of contact for people wanting help with Windows Phone development. This term is also now includes Windows Phone developer MVPs too.

I hope that's clear now.

Windows Phone app submission "signing failed"

2013-04-22T22:28:00.001+01:00

If you ever get a submission report like this (above) it can be quite disconcerting. It's realisitic to think that you may have done something wrong or missed something that caused this.

If you get this it can also be hard to know what to do next. The dev center will provide no more information and there isn't a lot in the forums either.

If this happens to you though, fear not. If you've run the xap through the store test kit and verified capabilities and requirements there could be another reason for this status.

Simply try uploading the XAP again. You may get this if there was a problem (corruption?) during the upload process.

It worked for me :)

I'm speaking at MobDevCon in July - Tickets on sale now

2013-04-22T21:08:00.004+01:00

On July 3rd, Naked Element will be hosting Norfolk's first ever Mobile Developer Conference. I'll be there to speak about Windows Phone and application pricing.

Early bird tickets are now on sale from http://mobdevcon2013.eventbrite.co.uk/#.
You can find out more about the conference at http://mobdevcon.com/

Why Windows Phone isn't more popular - the view from the phone shop

2013-04-03T19:40:00.001+01:00

I know there are lots of people developing apps for Windows Phone who bemoan it's small marketshare. There are lots of opinions on the success (or lack of-depending on your perspective) and these are often informed based on the perspective of the person talking. That is, developers typically think from a development perspective, etc.

Last week I had the opportunity to talk with a number of people who have a very different perspective to me and a different view of the mobile marketplace. I got to speak with a number of people who work in the operator, and independently owned, stores where a large number of people get their phones. They advise people on what phones people should get and know exactly what people are after when they choose a phone.

When asked about Windows Phone they were generally positive about the platform and spoke highly of the cheaper devices (Lumia 610, 620 & Ascend W1) and have seen some of these sell faster than they can stock them. It's when I talked about apps that things got interesting though.

There were 4 key points that I think developers should take note of (even if there is one that they probably can't do anything about themselves.)

1. The number of apps on a platform doesn't matter to people buying phones
700,000, 500,000, 130,000 - they're just big numbers and don't really impact purchasing decisions. I suspected this was the case. They're just a useful metric for journalists to compare platforms. I suspect changes in the rate of new submissions and updates is a more useful metric for platform health but harder to obtain than number of apps in store.

2. Having certain apps on a platform matters
While the total number of apps isn't seen as important, there are certain apps which are seen as essential. These fall into two categories: communication and flavour of the month.
Apps which enable communication between users on different devices (be that text based messaging, voice calls, picture calling or anythign else) need to be on the platform. If a person choosing a phone used a certain app on their old phone and all their friends/contacts use that app too (on other platforms). They won't choose a phone which doesn't have it. It'd mean being unable to communicate with their friends/contacts and isn't that the primary purpose of a phone anyway-communication?
"Flavour of the month" apps are those that everyone is talking about and using right now. Be that a game (usually it's a game) that allows you to throw animals, guess words or draw pictures, if "everyone" you know is talking about and using such an app you risk being left out if you can't get that app too. Coming to a platform 6 months after everyone elase has stopped talking about or even using the app doesn't help.
These may seem trivial issues and you could argue that there are alternatives available, but these are things that affect the phone people choose!

3. Feature parity matters
If an app is on multiple platforms but doesn't have the same features users can feel tricked. Say, for instance, you and your friends use a certain app for group messaging of texts and photos. If you get a new phone and have been told that it supports that app, it'll reflect badly on both the app and the phone if you get home to discover that the app on your phone only supports text messaging and not picture messaging as you'd suddenly be excluded from certain conversations. Not something you or the people using your apps want.
If an app is missing key features it would be better, in some peoples eyes, if it wasn't there at all!

4. Quality matters
While the number of apps doesn't really matter, the quality of the apps that people do choose to use does.
Windows Phone apps are generally perceived as being of a lower quality than apps on other platforms - people you need to raise your game!

What can we, as developers, take from this?
Three things:

Focus on quality, not just quantity.
Support multiple platforms. Especially if there's a social aspect to your app.
Aim for feature parity (especially core features) when moving to multiple platforms

Where to get icons for your app?

2013-03-30T21:07:00.000Z

So, you need some icons for use in your app.

If you just need icons for the application bar buttons, then start with the ones that come with the SDK. You'll find them at "C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Icons\Dark\" and these are also the ones that Blend can add for you.

If you need more then there are a numberof free resources available:

Metro Studio 2 (By SyncFusion)

It's a downloadable app that comes with 1700 FREE icon templates that can be sized and modified as required. You can see all the icons at http://www.syncfusion.com/downloads/IconPackagePopup/Application

The Noun Project

Loads and loads of icons that you can search online. Download what you want in vector formats. Most are creative commons licensed and/or very cheap to license. (I've never paid more than $1.99 for an icon there.)

Modern UI Icons

A collection of almost 1000 free icons. They're availabel sized for the application bar and in vector formats.

iconmonstr

1300+ icons thast are free to use in personal and commercial projects. They're also helpfully categorized to make it easy to find what you're after.

There are also other sources and you could always make your own or commission an icon if you needed something special.

As an extrs tip, it's usually best, as far as possible, to get all your icons for an app from the same source. This helps make it look like they all belong together. If you have small/subtle differences between icons (e.g. differing line weights or the radius on rounded corners) then some people will spot this and will think it looks bad. Remember, the little details matter.

Microsoft's advice about Panoramas is wrong!

2013-03-28T13:45:00.000Z

The advice Microsoft's designers will tell you (23:30 into the video) about a page hosting a Panorama control is that the page should not also include the System Tray.

This is wrong!

Let me tell you why.

Consider this scenario:

A person launches your app and upon starting it attempts to load the latest data from a web server or other external source. - Hopefully you'll agree that so far this is a reasonable and common scenario.

After a few seconds no data is displayed and the app still indicates that it is "Loading...". - Again, a common occurrence.

Now what?

Well, the person wonders if the delay is due to not having a connection or maybe they've only got 1 bar on a 2G network. - I hope you still think this is a not unreasonable scenario.

So, having wondered about connectivity, what does our person do?

Well, they swipe down from the top of the screen to reveal the network connectivity indicators that are included in the System Tray.

And it's at this step that we reach the crux of my argument.

If the page includes the System Tray the person will be able to see the state of their connectivity. If they have a connection they'll probably wait a little longer. If not they can, hopefully, do something about it.

But if the page doesn't include the System Tray what can they do?

They can do 1 of two things.

1. They can wait longer, but with the uncertainty of not knowing if the connection is there and if they'll ever get a response (at least until the connection times out.)

2. They can leave the app and check connectivity there.

If 1, you're forcing the person using your app into a situation of uncertainty with your app that can't be a good thing. Uncertainty in what your app will do, or when, is not a feeling you want to instil in people.

If 2, you're forcing people to leave your app when they want to use it. You're also increasing the likelihood that they won't come back. I'd be amazed if you want the people who have downloaded and installed your app to not be using it when they have wanted to.

My advice:

Include the System Tray on any page that has content that comes from a remote source.

Microsoft doesn’t even follow their own advice!

Checking on the WP8.0 device in my pocket I can see that:

While the store, music and video hub, games hub, photos hub and wallet don't include the system tray, the People hub and the Office hub DO include the System Tray

The exception when this isn't true.

My reasoning above is based on a Panorama with dynamic content that is obtained from an external source. Obviously there are apps which use a Panorama control but don't use external content. (I've even written some.) In this scenario there is, potentially, very little value to the including the System Tray and so there may be an argument for not including it.

Yes there is potentially an argument for including a System Tray even if the Panorama uses entirely local content so that it's possible to see things like the clock and battery status. Include it at your discretion in these scenarios.

Disclaimer. Yes the title of this post is quite broad-brush and I'm only talking about a potentially minor issue here. I understand that but small details matter.

tl;dr: DO include the System Tray on Panoramas. Even though Microsoft tell you not to.

10 Tips for designing your mobile APIs

2013-03-22T09:15:00.000Z

It's common for a mobile application to need to communicate with a web/cloud based service. At its simplest this will be just to retrieve data but it could also include sending data and user authorisation and management.
If you have to build the API that your application will use the following tips may be useful:

1. Version your API (from the very beginning)
At some point in the future the API will need to change. This may be to add, remove or change functionality. When this happens you may have to stop the use of part of the API or allow the consuming application to be clear about which behaviour, and type of response, it is expecting to be returned.
Your API is like a contract between your backend and the apps that use it. Without proper versioning you are risking the situation where one party can change the contract without the other even knowing. Having support for multiple versions of the API you can also continue to support users of your application who haven't been able to upgrade to the latest version of your app that uses the latest version of the app that knows all about the latest API changes.
Without versioning of the API you make it much easier to, inadvertently, stop applications working when changes are made to the API.

2. Don't return more data than you need to
The amount of data that is sent between the application and the server will, to some extent, impact the time it takes for the request to be made and the response to be received. Not only does this impact the amount of time a person spends staring at a loading animation, it may also impact the amount they spend on data charges.

3. Compress the data that is sent and received
In addition to not returning more data than is necessary, by compressing the data that is sent you can experience further benefits in speed and cost of data transfer.

4. Don't require unnecessary steps/requests
It's very common for APIs to be designed to provide separate discrete steps that reflect how the service is intended to be used. Quite often though, such discrete steps aren't the most efficient way of implementing a mobile application.
Let's take a simple example. Imagine the situation where a user has to log in (provide valid credentials) before being able to request data. It would be perfectly reasonable and understandable to think of this as two separate steps:
Step 1: The credentials are provided and, if valid, the API responds with a session token.
Step 2: The session token is passed when the request is made for the data.
That's probably unnecessary though. It would be much better if a single request could be made, passing credentials and the details of the data that is desired and, assuming valid credentials, both the data and a session token, for use in future requests, are returned.
The benefit of this is that fewer requests are faster and cheaper for the person using the app and may also (depending on how it's implemented) lead to simpler application code, which can lower development and support costs.
This may mean that you have to build the API to support both types of usage. This may lead to higher costs to support, document and maintain. But, if you're building your API just (or primarily) for your own use this may be more acceptable.

5. Combine requests (and responses)
In addition to multiple requests being made as part of an authentication or app start up process, it can also be common for multiple requests to be made to retrieve all the data for a single page or view in an application. Making a single request for all the data that a page requires, will be faster and cheaper than making multiple calls. Both factors that will be seen positively by the people using the application.
Again, this can also make the application code simpler. Especially with regard to handling the situations where multiple calls are made and not all of them are successful. If it becomes an all or nothing scenario the exception cases become much simpler.

6. Consider security from the beginning
Security is a massive and potentially complicated subject. This makes it particularly difficult to add on in a hurry in response to a security issue.
Remember to consider: securing data in transit; securing your data at rest; inappropriate or unauthorised use of the API; and potentially malicious or unexpected data having unintended consequences.

7. Plan and implement your caching policy carefully
If the data your API returns doesn't change very often be sure to implement appropriate caching strategies. This could involve keeping data in memory, rather than repeatedly reading it from disk. This should almost certainly involve the caching capabilities that are part of HTTP (assuming that that's the protocol you're communicating over).

If you do implement caching on your server, be sure to offer a way to forcibly invalidate it though.
Also make sure that you implement appropriate caching in the client application that consumes the API. You save time and resources if you can make a call and be told to keep using the data that was returned last time. You save more time and resources if you can avoid making that call in the first place.

8. Integrate analytics
Analytics are an essential part of understanding how an application is used. It's common for calls to an analytics service to be made in addition to the requests for data that are made during normal use of an app. For instance, if the app will attempt to call the server to refresh the displayed data on a page every time that the user navigates to that page then there is redundancy in adding a separate tracking/analytics call to track navigating to that page as well.
At its most primitive, the use of the API can serve as an indication of how and when the application is used. At the other end of the scale there are rich analytics tools and frameworks which can provide very detailed information about how users interact with the app. If you're somewhere in between then think carefully about how or if you're making additional/unnecessary calls purely for the purpose of tracking usage when you could get this from the calls made as part of the usage of the app.

9. Consider names carefully

The names you give the methods, objects, properties and parameters of your API will greatly impact the way those who are using the API understand it. It can be very tempting to use whatever terms or wording first come to mind when creating the API. As with all code though, the words you use play a great part in how the API is understood and expected to behave. Poorly named APIs can be a great source of confusion. Confusion leads to mistakes, mistakes lead to bugs, bugs lead to delays and support costs. Spend time on naming.

10. Don't forget your privacy policy and responsibilities
If you're capturing user data (and if you have logging on your server to record requests then you are) you need to have a privacy policy that details how you'll use the data. You'll also need to think about how you store and protect that data. Especially if it's personal and/or belongs or relates to children.

Debugging binding issues is hard. Having simpler code makes it easier.

2013-03-20T23:28:00.000Z

Recently I had to deal with a strange bug.
Sometimes the menu option to create a secondary tile was not being enabled when it should be.
After analysis I was able to get the most consistent reproduction of the issue on a lower spec device (a Lumia 620). Obviously this isn't acceptable so a solution had to be found.

I tracked the most likely candidate to the `CanPin()` method. You can see the "before" version below.
You'll notice that it "smells" of all sorts of issues. It's also not something that can be debugged or instrumented easily.
It also isn't immediately obvious how it works because it's not easy to read.

There's definitely the possibility for something funny to be going on there.
Could all those checks be being made in an order differently to how they're listed?
Could there be a bug in the logic?
Could the time it takes for them to be run be taking longer than is available to trigger the binding to update?

The only option available is to refactor to make the method clear about what it does and in what order.

And, as if by magic the problem went away.

So what was the problem?
I can't be 100% certain.
But I'm not sure that matters.
That well written, easily understandable code doesn't display unexpected, unintended consequences--that's a good thing. Why badly written, hard to undertand code has certain unintended consequences--isn't a priority for me just now.

This leads me to be reminded of three important lessons:
- Debugging binding issues is hard (Bind to simple properties to help avoid binding issues.)
- Simple code is better (both to debug and to maintain)
- Be sure to test on real devices (both low and high spec)

TL-DR:
Bind to simple properties to help avoid binding issues.
Write code that is easy to read so it's easier to maintain in the future.

3 MiFi topup fail

2013-03-20T20:41:00.002Z

One of the devices I have to keep me and my devices connected to the Internet is a MiFi unit (portable access point) for (UK network) 3.

I don't use it very often but sometimes I can't use Wi-Fi or Internet sharing from another device. Today was one of those times so I got out the unit and, as I have it on PAYG (because I don't use it enough to justify a contract) I attempted to top up.

I turned on the MiFi unit and paired with a device, a Nokia Lumia 620. All good so far, then I opened the browser to be automatically redirected to the top up site.

1st problem - I was given the full site, as I'd expect on a PC or other large screen device. This meant I had to wait ages for the page to download (over HSDPA) and render on a device which wasn't suited to displaying all that content and wasn't related to the task I was trying to achieve.

2nd problem - I had to go through lots of unnecessary steps/pages to achieve what I wanted. The page I was initially taken to had what looked like 4 big buttons for each of the available top up options. The only problem was they weren't buttons - just images. There was actually a text link to top up but I had to zoom into the page to see it. Clicking the "I want to top up" link redirected me to the account overview page. From there I had to click another I want to top up link. This took me to a page that provided a drop down list for each of the top up options. Selecting from this list caused the page to reload. There were then separate pages for selecting to use my preconfigured credit card and entering the card security code (CVV number). This finally led to another page for...

3rd problem - the 3D secure step in the payment process tried to open a page which had a mime type or other content that the phone couldn't display and so prompted me to visit the store to download an app to view the content. Of course, the problem here is that I couldn't connect to the store as I had no Internet connection. Even if I could connect to the store I doubt my credit card provider has an app that could allow me to complete the in browser transaction. In fact I don't just doubt it - I know it's not possible, at least not without having some Microsoft implemented changes to the browser and as the bank and card provider have nothing in the way of apps in the windows phone store, what are the chances that Microsoft have built something into the OS for them?

Ok, that's a partial HSBC/MasterCard and Microsoft/Internet Explorer failure but still, it's left me a very frustrated and disappointed customer. :(

I ended up getting out my iPad to top up.

So, rather than just moan about the situation, what can we learn from it?

Be smart about the content you serve to devices. Especially ones with small screens.
Remove unnecessary steps, page reloads and redirects from processes. Especially sign up and payment processes.
Provide, simple, easily identifiable short cuts to do often repeated tasks.

Yes these are all obvious and often repeated recommendations. I hope by repeating them again here it'll help someone remember them next time it's appropriate.

Online privacy when building apps for kids

2013-03-18T14:03:00.001Z

This weekend just gone I was at the Windows Phone 8 Lock-in organised by Dev4Good, so issues around apps for children and young people is on my mind at the moment. That's probably why this caught my eye:

http://momswithapps.com/category/online-privacy/

It's a set of resources relating to online privacy curated specifically for people creating educational apps for children. If you're building apps for this audience they're an invaluable read.

Azure Mobile Services error: "The request could not be completed. ()"

2013-03-17T09:13:00.000Z

Having just published my first (Windows Phone - obviously) app using Azure Mobile Services, I thought I'd share something I learnt in the process. When first testing on an actual device (always test on actual devices!) I hit an issue where the MobileServicesClient was failing with the following message being intercepted by the Application level UnhandledExceptionHandler:

"The request could not be completed. ()"

Notice the empty brackets at the end. In most cases (based on similar exceptions that others have reported and Google helped me find) these would include an indicator of the issue. Such as "(Internal Server Error)" or "(Send failure)".

The call stack wasn't much help either:

   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.CreateMobileServiceException(String errorMessage, IServiceFilterRequest request, IServiceFilterResponse response)
   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.ThrowInvalidResponse(IServiceFilterRequest request, IServiceFilterResponse response, JToken body)
   at Microsoft.WindowsAzure.MobileServices.MobileServiceClient.<RequestAsync>d__f.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.WindowsAzure.MobileServices.MobileServiceTable.<SendInsertAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.WindowsAzure.MobileServices.MobileServiceTable`1.<InsertAsync>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
   at RadioNow.MainPage.<OnNavigatedTo>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__0(Object state)

Even when I wrapped all my uses of the client in try..catch blocks this exception was still only getting caught at the application level unhandled exception handler.

Anyway, the issue came down to the devicenot having Wi-Fi enabled and for some reason it wasn't using 3G ro USB passthrough to connect instead.

So, 2 lessons:
1. The WP8 AMS client might throw errors, based on connectivity, that you'll have to catch and deal with at an application level.
2. Be sure to check/test Wi-Fi connections on devices when tethered.

AccentComplimentBrush v2.0

2013-03-13T20:34:00.000Z

Yesterday I showed my new AccentComplimentBrush as a way of having a second color that can be used within an app and will work with whatever accent color has been chosen.

There was one big issue though. It only worked with the default accent colors in Windows Phone 8.

I've just pushed a new version to GitHub that is both forwards and backwards compatible.

It now works on both Windows Phone 7.X and Windows Phone 8.
It also works with operator and manufacturer defined accent colors. In fact it will work with any accent color whatsoever (yes, even for the people who've hacked in their own colors) as it now determines the compliment on the fly, rather than relying on a precomputed list of compliments.

Please enjoy.

Using a complimentary accent color

2013-03-12T21:38:00.000Z

Sometimes you may want to use two colors in an app. If it was just one then I'm sure you'd just go with the Accent color.
The acccent colors all work well when on Black or White.
The problem though is that there is no single other color that can be combined well with any accent color and you probably want black and white elsewhere on the page. What you really want to avoid is a design that looks bad with one (or more) accent color(s).

If only there was a way to have another brush resource available that would adjust to the selected accent color and work in compliment to it.

Introducing the AccentComplimentBrush
It lets you have another SolidColorBrush available via a an Application wide resource that will work with any of the default accent colors. The complimentary color is based on the exact opposite position on the color wheel. See how the two pairs all go together:

The accent color above and it's compliment below.

How do you use it?
Just 2 simple steps

1. Add the resource.
Get the file, add it to your project and then reference it. (Either at the application level or on a specific page.)

    <phone:PhoneApplicationPage.Resources>
        <mrlacey:AccentComplimentBrush x:Key="MustBeSetButCanBeAnything" />
    </phone:PhoneApplicationPage.Resources>

Note the key value I've used above. Resources must have a key, but we don't actually ever use it. Because of this, ReSharper (or equivelent) might try and tell you that the resource isn't used. It is. Usage just can't automatically be detected at design time it because it's implemented with some run time trickery.

2. Use it!
Just refer to it in the XAML.

    <TextBlock Text="accent"
                Foreground="{StaticResource PhoneAccentBrush}" />
    <TextBlock Text="compliment"
                Foreground="{StaticResource AccentComplimentBrush}" />

or in code:

(SolidColorBrush)Application.Current.Resources["AccentComplimentBrush"];

Important!
1. It currently only works with the default accent colors, not any added by the operator or OEM. If you use this and want some help with adding support for any accent color let me know.
2. Because it uses "run time trickery" it doesn't work with the designer (in Visual Studio or Blend). If you know a way that would allow design time support I'd love to hear it.

What do you think? Useful?

Update I've now made a version 2.0 of this code which supports 7.X too and will even work with OEM/MO defined accent colors.

Telford: done! Next it's Bristol.

2013-03-11T20:31:00.000Z

Last month I talked about Windows Phone 8 development at the university in Telford. Next week it's the UWE in Bristol.

The feedback from Telford was very positive.
There were 3 questions on the feedback form and each was marked on a scale of 1 to 10.

The talk was well delivered and I could understand the concepts discussed: 9.1 / 10
I got something out of this that I could use in a project, either in work or as a hobby project: 8.5 / 10
I would attend one of your talks again: 8.9 / 10

I'm particularly proud of those results considering only 1 person in the room with a Windows Phone 8 device and no one there had any previous experience developing for Windows Phone.

If you're in the Bristol area next Tuesday and are interested in hearing about Windows Phone 8 development,why not come along. More details, registration, etc.

NCLDR on Windows Phone 8

2013-03-08T12:00:00.000Z

Earlier this week, uber-UK-community-bod and I18n expert, Guy Smith-Ferrier announced the alpha launch of NCLDR.

If you're not familiar with CLDR you can think of it as being like a version of the Globalization parts of the .net framework with lots of added extras. NCLDR is a .net port that allows access to all these lovely goodies.

As is my way and because I was interested if I could use the data in a phone app so I attempted a port/conversion to Windows Phone 8. It's just a POC at the moment, but look, I can get a regex for validating postcodes for each (well most) supported culture(s). If you're capturing a postal or zip code in your app this would allow you to validate it on the device, regardless of which country it was in.

I'll be honest, it wasn't as simple as I'd hoped. There was a lot more work and work arounds needed to get it to work than I would have liked and if Windows Phone support was to be officially added it would be better to add it in early and maybe remove use of some of the types and methods which are not supported on the phone, to aid greater cross platform code reuse.

Here's the changes I had to make to get it to work:

Biggest issue: WP doesn't support BinaryFormatter.
Second but related issue: By switching to using a JSON serializer I was potentially making the data file even bigger. I countered this by only including the minimum I needed in the generated file. This no only made the data file smaller but meant I had to load less and so save on precious memory consumption.

Add missing System elements:

CultureTypes
DigitShapes
ICloneable
SerializableAttribute

Replace use of HashTable with Dictionary<string, string>. In:

Culture.cs
Numbers.cs

Replace verison of string.Compare that was used with a WindowsPhone supported version. In:

Calendar.cs
CultureData.cs
Currency.cs
CurrencyPeriod.cs
Language.cs
MessageSet.cs
NumberingSystem.cs
NumberingSystemType.cs
Numbers.cs
PluralRule.cs
Region.cs
RegionMeasuringSystem.cs
CultureInfoExtensions.cs
RegionInfoExtensions.cs

Added some null exception handling/wrapping/suppressing to the following (but didn't really look into why it was needed):

Language.cs
Calendar.cs
Region.cs
CurrencyPeriod.cs
NumberingSystem.cs
Script.cs

Hopefully unnecessary disclaimer: This is a quickly hacked together proof of concept on top of alpha code. Use at your own risk...

Why and what I blog about here

2013-02-26T20:59:00.000Z

I've been blogging here since August 2006. That's a long time (well it feels like it sometimes) but also shows I was late to the blogging party.
In that time I've used this blog for various things and covered a variety of subjects.
While there are still some exceptions, I mostly now write about Windows Phone related topics. Hence the current title of this blog. Yes it may sound a bit big-headed (but what is the web if not for self promotion ;) ) but the real aim is to help other people to be awesome with Windows Phone. Yes it's sometimes nice to blog things as a memory aid but I primarily write for others to read. Yes, it's nice when people (especially those I deem cleverer or most expert than me) let me know they found the answer to an question/issue/problem on my blog.

Why don't I blog more frequently?
Time. I just don't have enough of it and writing takes me ages. In fact one of the reasons for initially starting a blog was to encourage me to write more, in the hope of getting faster at it.

How do I pick content?
If we just consider the Windows Phone related content I post you'll notice something about it. That content isn't anywhere else online. I'm deliberately only adding to the cumulative knowledge of the internet. I'm not trying to duplicate it.
There are already lots of tutorials on getting started with Windows Phone development. The MSDN documentation is very comprehensive. I don't have the time to and see no real value in creating yet another set of getting started or beginner instructions. I see no value in reposting what is already on MSDN (Yes, I'm looking at a few certain people here!).
What I want to do is document what isn't documented elsewhere.

Who for?
I see two main audiences for my WP related content.
Primarily I write for the long tail. I hope that at some point when someone hits the same problem or reached the same undocumented issue they'll find my site (thank you Google) and information that can help.
The secondary audience for my content is those few keen Windows Phone developers (like myself) who want to know everything they can. By sharing what I learn and discover I hope I can contribute knowledge that helps them with their apps and let them know new things or edge cases which aren't documented elsewhere.

Personally, I want to be awesome at making awesome apps. But I know I can't change the world, and its apps, by myself. So I'm also trying to help others become better at making better apps. This is why I blog, answer questions on StackOverflow and organise user groups.
I want everyone to be building better software that helps create a better tomorrow. My first responsibility is to myself and the software I create but I also want to reach out to others and help them too.

CV tips

2013-02-26T13:26:00.000Z

A few tips for your CV:

Include your name in the file name - So it's easy to identify who's CV is who's when there are lots saved to a disk.
Include your contact details - Agencies may remove them before forwarding to companies but if you're sending direct to a company you need it there.
Spell check!
Give it to someone else to spell check! - Seriously. There should be no spelling mistakes in it. Especially in titles/subheadings (I just saw someone list their "KILLS", when I sincerely hope they menat "SKILLS"). Technical jobs demand attention to detail. Be sure you display some when selling yourself.
Put your work experience in order - Don't jump around in time. If the most relevant work experience you have is many years ago call it out separately and indicate clearly why it is still relevant. Don't put it between the work you did two years ago and three years ago when applying time headings.

Talking WP8 in Telford

2013-02-25T14:04:00.000Z

On Wednesday I'll be speaking at ShropshireDevNet. If you're in the Telford area why not pop along and say hello.

This will be the same as (or very similar to) the talk I gave in Southampton last week.

Here's what some of the people who came last week said:

"Really great presentation. Good tempo. Dry humour worked well. Well executed and useful examples. Inspired."

"Excellent. So much to learn and explore!"

"Excellent look at the features available for windows 8 phone."

"Great session. Learnt a lot of useful nuggets of information. I realy want to push ahead with some app ideas now."

"Good speaker. Whistlestop tour but useful. Speaker mentioned issues and problems as well as good features. "

"A lot covered, in short time. The constant questioning and boucing around actually worked really well"

"Great session, fast paced and good atmosphere"

"very fast presentation but liked the examples"