During my development journey with Windows Phone 7 , there have been a number of things that I overlooked when writing your first app – things I wished I’d kept front of mind. None of these items are necessarily difficult or complicated things to cover off, so I thought I'd mention them here to save you the trouble, and at the same time show you ways to overcome each of them.

Globalisation

Windows Phone 7 devices have been released to a total 63 different markets at the time of this post’s writing, and while we might not sometimes talk about it too much the majority of the world doesn’t speak English.

Even more relevant when writing apps that process third party data, lots of countries also don’t use the same date or decimal system as the US or British do – and when parsing dates or numbers in a local region this can easily break your code.

If you are in France or a large percentage of Europe for example, instead of One Hundred Thousand being written as “100,000.00” as in the US it is instead written as “100 000,00”.

The way to get around this depends on whether you are receiving data in a foreign region, or sending data in a foreign region.

Below is an example piece of code to represent this problem (This is not how you should your app because it is best practice  to keep the culture local and instead change how you parse).

// Switch the current culture to French to simulate a French User
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");
Double Number = 123.00;

// This will be "123,00"
string Output = Number.ToString();

// This will be "123.00"
string InvariantOutput = Number.ToString(CultureInfo.InvariantCulture);

This means that if you are parsing Strings that are from the US to Ints or Doubles (such as those fetched from remote American APIs such as Twitter or Google) and your users are in France, your app will throw an exception as the number format won’t be properly recognised – you need to either specify the culture of the incoming string or specify the culture as Invariant Culture (defaults to United States).

Take the following example run on a US based device. Here we take a set the culture to French (to simulate a French user) and then successfully parse the US/British number string.

Double Number = 123.00;

// This will be "123.00"
string Output = Number.ToString();

// Change the current culture to simulate a French User
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");

// This will throw an exception
Double FrenchParsedNumber = Double.Parse(Output);

// This will not throw an exception
Double FrenchParsedNumberInvariant = 
    Double.Parse(Output, CultureInfo.InvariantCulture);

All of the above examples also definitely apply to Parsing of Dates. There is a good write up on MSDN showing how to do this with DateTime format providers.

Also, You can test your application under different conditions by changing your emulator’s regional culture.

Localisation

While this is not really a problem with your app per se, while we are on the topic of foreign users it’s worth mentioning  that because very soon only a tiny percentage of the market will be English speaking countries, separating your text content into international resource files will make selling in these markets a lot more lucrative – and anyone who’s done this before will tell you it’s a lot easier if you do this from the start, even if the only language resource you have is English to start with.

Steps to add local language support to your Windows Phone 7 app pages (Based loosely on this MSDN article)

Create a new Resource File in your app called Resources.resx

Add a new file for each additional language you want to support (i.e. named Resources-FR.resx for French, Resources-ES.resx for Spanish).

The MSDN article linked above shows you how to create the LocalizedStrings class, however they don’t go on to show you how to use it for DataBinding, so lets solve that.

WPF/ASP.net and Silverlight handle data binding differently than Winforms. Silverlight uses the term Resource to refer to files that use the the Build Action of "Content”, as these files get wrapped up into the .XAP file similar to files with the Build Action of "Resource” get embedded into the .Dll assembly.

I found that instead of using the Text="{Binding Path=resourceFile.resourceName, Source={StaticResource Localizedresources }}" XAML syntax it was easier to follow the steps below:

1. Open your primary XAML page (usually MainPage.xaml) in the Visual Studio
2. Open the properties for the PhoneApplicationPage and set the DataContext to be Application.Resources –> LocalizedStrings. NOTE: if you already are using a DataContext object, then you should integrate the LocalizedStrings class into that object so that it has localization support.
   
3. Once the Page’s DataContext has been set you can change the data binding for any control on the page by simply selecting the property (ex: text, checked, etc) and selecting “Apply Data Binding…”, and setting the Path to LocalizedResources.BtnText or whatever the resource key that you are trying to bind to is.

Remember: the Application Bar is not a Silverlight control and therefore can’t have resources bound to it in the same way. To achieve this you will have to create or update the Application Bar at runtime.

Wi-Fi Internet browser login problems

This is another problem that is far from 100% clear at first.

Your users will probably come across bad data while connecting to wireless access points that require a browser login (such as a hotel or library). Usually the device should kick up a session of Internet Explorer to take care of this, but there are a number of situations where this won’t help you:

• When your background task runs to update a tile and the user hasn’t logged in yet.
• When the user ignores the browser login page or is interrupted while using it (phone call etc.) – this leaves them in a state of “online” but not net connected.

Quite often these browser-login walls for Wi-Fi will simply return the login page for every request. This means that you application will think its speaking to the internet (or Twitter or whatever API you are using) but instead will get back bad data or a 3XX redirect response code.

What does this mean for you?

It means that when pulling down data from an external internet source, make sure to the following:

• White defensive code for WebExceptions such as Try Catch statements (as long as you only catch the exceptions you are looking for – not just any exception).
• If accessing a data source with a known or documented schema (such as a third party XML API), validate returned data against a schema file (in XML’s case, use an XSD to validate the data format before accessing it or deserializing it). This will ensure that even if data is returned, you know its what you were actually looking for.

Always assume the data that your app will be getting back from the internet is invalid.

Network Interface Online Without Internet

Another problem that can affect your users and leave them thinking bad things of your app is when their devices think they are connected to the Network but don’t necessarily have internet access. This can happen in areas of bad coverage, or when their carrier has internet connectivity problems.

Ensuring that the device has Network connectivity won’t fix this problem as your app will still timeout if it can’t access the internet.

There are two ways to minimise this problem:

• While your app is running, every few minutes download a small text file, similar to Microsoft’s NCSI service and use this to establish Network Connectivity (you could even use the MS URL to save yourself time).
• Set timeouts on your app’s network downloads to a lower figure than the default of 100 seconds – the standard Windows Phone 7 SDK HttpWebRequest doesn’t support the Timeout property, so the guys over at WP7Contrib have put a nice solution in place for putting Timeouts in place. I put mine at 40 seconds, as this seems to be a good compromise between slow network speeds and users waiting forever – your mileage may vary so test this until you find a happy medium.

Summary

Overall there are a number of little things that can add polish to your app – often your users may have a totally different experience when using your app in the wild, and the closer we can get to covering all of these things to better – and happy users rate you app highly, and you get more downloads. Either way you look at this it’s a good thing.

Do you have any little niggling things you wished you’d kept in mind when first writing your Windows Phone 7 app? I’d love to hear in the comments section below.