Running a Beta on Windows Phone

As many of you know, over the past couple of months I’ve been developing Foundbite for Windows Phone 8 and running a beta version of the app which has around 800 users. While nowhere close to the number of beta testers that apps like 6tag and Instance had, the testers have provided just as much value and it’s been great receiving and acting on it. Through running the beta I’ve used several tools which might well be useful to others looking to run a beta on Windows Phone.

Getting People Interested

So you need beta testers, where do you find them? Being part of AppCampus I was in a lucky position and able to drum up interest through their social media channels. However, the two other biggest channels I received sign-ups from were WPCentral and WMPoweruser.

WMPoweruser just requires you to draft up a post on your own but is definitely worth the effort. Although the site’s content isn’t close to the standard of WPCentral many Windows Phone users read it, especially in emerging markets. If you can reach out to the guys at WPCentral and see if they are interested in covering the launch of the beta. We were lucky enough to get a great bit of coverage from Rich Edmonds at the start and a month into the beta.

Dealing With Signups

I’ve noticed developers using all manner of tools to collect beta signups including having to email the developer directly, Google Docs, tweeting or posting in a forum. These are all far from ideal. Not only do you not have a list of all the people interested in using your app but any time you wish to send them an email you have to copy and paste all those names into an email to BCC.

May I now introduce MailChimp.

MailChimp is a emailing marketing service that allows people to sign up to your beta using a nice sign-up form, collect info about them such as name or device type if they chose to give it, it’ll then give you a nice list of your signups which you can easily send an email to should you need it. Best of all MailChimp is free. Yep, free. The only condition is that you don’t send more than 12,000 emails a month – a limit I didn’t come close to.

MailChimp also allows you to segment the list of testers. For example, users were signing up to the Foundbite beta every day and I didn’t want to miss adding anyone on or send people a signup email repeatedly. Segmenting the users by date, adding them on, sending them an email, then the next day sending emails to the users that were added since the last email was sent worked well for this use case.


Getting users from MailChimp into the Windows Phone developer centre

After getting articles up on WPCentral and WMPoweruser I had quite the influx of users and lots of emails to enter into the Windows Phone developer centre. Each email has to be added to a semi-colon delimited list which can be a bit tiresome.

To make this process easier I made a little Windows Forms app that takes in a CSV form (which you can export from MailChimp or Google Docs), verifies all of the emails and then pastes them to the clipboard separated by semi-colons. Download and find out more about it here.

Windows Phone Email Beta Helper

Windows Phone Email Beta Helper


Make it easy for people to give you feedback

In Foundbite, from any page of the app a user in two clicks a user can send an email asking for help or to report a bug. This has been really instrumental in getting some really useful feedback from the app.

In the app the user can just slide up the menu to send feedback.

In the app the user can just slide up the menu to send feedback.

The emails are sent to a Uservoice account where I can see all the support requests and also provide users with a forum where they can vote for features and prioritise them for development. Best of all, it’s free for a single user.

It’d be great to hear if anyone else has any experiences running a beta on Windows Phone and any tools they’ve used to help them.

Lessons Learnt Using the Windows Phone Camera API : Part 2

A few months ago I wrote a post about some of the stuff I learnt working with the Windows Phone camera API for Foundbite, here’s some more I’ve learnt since….

Disable Camera Buttons

Initiating a photo capture can sometimes take a bit of time, especially if you’re focusing as well, and I found even if you give the user some loading feedback it’s quite likely they might try to press the button more than once. If they do this the phone will try to initiate another camera capture which will most likely throw an InvalidOperationException. In Foundbite, after suffering from many of these exceptions, I’m disabling the on screen button and the physical camera button when the capturing process is occurring.

Dispose the Camera

You may have noticed that if you don’t dispose an instance of the PhotoCaptureDevice whenever you leave the camera page it’ll cause a whole host of problems, including giving a nasty bug where the camera feed goes green- often needing a phone restart to right itself.

In the OnNavigatedTo event on the camera page I declare a new instance of the camera and in the OnNavigatedFrom I .Dispose() the PhotoCaptureDevice which has stopped this from occurring completely.

Don’t Assume All Phones Have the Same Resolutions

It’s best to assume that every phone has different resolutions available to avoid any unexpected problems when setting the resolution. I was initialising the camera in Foundbite using the 640 x 480 resolution which I though every phone would have as the minimum. However, it seems the new Nokia Lumia 1020 doesn’t have this low resolution so was causing a crash for that particular device.

I have an idea of what kind of size image I want so I just use this fairly schoolboy method to select the closest available resolution using the widths available and the desired width:

public static int GetNearestSizeIndex(List<int> widths, int wantedSize)
int distanceAway = int.MaxValue;
int index = 0;
for (int i = 0; i < widths.Count; i++)
int distance = Math.Abs(widths[i] – wantedSize);
if (distance < distanceAway)
distanceAway = distance;
index = i;
return index;

As I said, pretty basic but in Foundbite I’ve had to limit the size of images to improve image size and upload speed, so this is helpful for selecting the best resolution.

Focus Illumination Mode

The FocusIlluminationMode is the small flash you sometimes see when focusing the camera. I wasn’t aware you could even control this to start off with but to stop annoying your users its best to give them an option to turn this off if they so wish (or keep it on all the time).

Make sure you check that the phone has a flash before allowing the user to manipulate the illumination mode as a Nokia Lumia 520 only has one FocusilluminationMode (off) as it has no flash.

if(camera.IsFlashAvailable()) camera.SetIlluminationMode(Settings.FocusMode.Value);

Which uses these two methods:

public void SetIlluminationMode(FocusIlluminationMode mode)
Device.SetProperty(KnownCameraPhotoProperties.FocusIlluminationMode, mode);

public bool IsFlashAvailable()
return (GetAvailableFlashStates().ToList().Count() > 1);

For more help using the camera I found this Camera Explorer sample from Nokia amazingly useful……

Coordinates, Doubles and a Localisation Bug

I was recently driven crazy by a particularly annoying bug whilst developing a feature of Foundbite that allows you to view what other’s have uploaded in a certain location.

In the app you scroll over the area in the world you want to view and the app then sends a simple request to our Azure hosted API to get the foundbites in a given location rect. The request looks a bit like this:

It’s constructed by getting the coordinates and simply using double.ToString() for each individual lat/long.

Testing on my Windows Phone device it all worked fine but a select group of beta testers reported that whenever they visited the page and tried to load some bites the map was remaining blank and the web request was failing every time.

This was confusing to say the least and I spent a whole day trying to work out what was wrong, including trying different versions of the app but came up empty.

At my wits end (see above) I consulted with a fellow Windows Phone developer, George Spyrou, who had incidentally fixed the exact same bug in his app that very day.

It turns out, all the users that were reporting this bug were based in European countries and had different cultures on their phones. These cultures use a “,” instead of a “.” in decimal values and therefore when the app was composing the URL in these cultures it looked like this:,2&lonMin=-179,232&latMax=79,343&lonMax=179,99

It doesn’t look all the different if you can glance at it, but the commas in the URL invalidate it and the request will return an error every time without giving you much of an idea as to why.

Thankfully when I became aware of it, there was a simple fix at hand; instead of using double.ToString() you should use double.ToString(CultureInfo.InvariantCulture) which ensures the culture is ignored.

A simple bug but hopefully this’ll prevent other devs falling into a similar trap when incorporating GPS Coordinates into URL’s.

Lessons learnt working with pushpins and maps in Windows Phone 8

Given the location-based nature of Foundbite, I’ve had to do a lot of work with pushpins and maps. When I was first starting out I ran into a couple of hurdles with the difference between WP8 and WP7.

Adding a pushpin to a map I can’t remember how exactly I came about this method of adding pushpins (or if it’s completely necessary) but I’ve been adding MapLayers to the map which include several MapOverlay’s each containing objects you want to display at a certain location (in this case pins). Pushpins do have a location property you can set but using a MapOverlay means you can add anything.

MapLayer layer = new MapLayer();
Pushpin pp = new Pushpin();
MapOverlay overlay = new MapOverlay();
overlay.Content = pp;

Setting the overlay (and therefore the pushpin’s) location

You just need to select the correct MapOverlay from the layer. Easy.

layer[x].GeoCoordinate = new GeoCoordinate(Latitude, Longitude);

Changing the pushpin’s style

If you want to change the style of your pushpin, it’s as easy as using the editor in Blend, saving to Application resources in App.xaml and then calling this line of code:

pp.Style = App.Current.Resources["MyStyle"] as Style

Changing the position origin of your pushpin

If you edited the style of your pushpin you might not want it to be placed on the map by its bottom left corner as normal. This can be changed via the PositionOrigin property of the overlay:

overlay.PositionOrigin = new Point(0.5, 1);

This sets the position origin to the bottom middle of the pushpin. (0,0) is the top left.

Get the position of a tap on the map to add a pushpin

Definitely one of the most useful and least used parts of the map control is the ability to get the geo location of a user’s tap on the map. You just need to get the screen coordinate of the click in relation to the map control (measured from the top left again) and then use the handy map method below to convert this to a GeoCoordinate.

var point = e.GetPosition(map);
var location = map.ConvertViewportPointToGeoCoordinate(point);

There’s also ConvertGeoCoordinateToViewportPoint which does the reverse.

I discovered this method after writing a version of the ConvertViewportPointToGeoCoordinate myself over the course of the weekend – so much time wasted!

Hopefully these are useful!

This is a a copy of a post I wrote on my previous blog:

What I learnt building a gimmicky app for Windows Phone…

Before taking the startup route with Mendzapp and subsequent development of Foundbite, it was really just a professional front for my Windows Phone app development. The first few apps I developed, Travelnapp and YuleTile, I knew weren’t going to make me rich in the very early days of Windows Phone, but I won’t deny hoping for at least a bit of money, I was a lowly student after-all. YuleTile made some money for myself and the Railway Children charity but we’re only talking a couple of hundred pounds really.

Browsing the api site, Programmable Web, I came across – a company that ran a service that analysed photos, recognised faces and even went as far as guessing how old they were. It was pretty impressive stuff and I immediately came up with a concept for an app that I though could really be quite good.

I remembered an app called Fit or Fugly that had been demonstrated to me on the iPhone by a friend. The app, which told you how fit or fugly you or your friends were, was able to judge the degree of unfortunate looks by working out the distance ratios between your nose and eyes. It was a fairly polished app but there wasn’t actually anything that clever (technically) about it. You snapped a picture of a friend’s face and simply dragged and dropped markers on their face where their mouth, nose and eyes were. The app then made a big show of processing the data and gave you a percentage score (I’ve since conveniently forgotten my score).

Gimmicky yes, but at the time people were really liking these fart style apps and the developer, Ed Nash, went on to do amazingly well from it with over 2 million downloads worldwide according to the app description. At £0.69, that’s quite a lot of money!

I saw how much he’d made from something so basic and got the dollar signs in my eyes and set about making VizAge for Windows Phone. Even though Windows Phone has far less users I figured I could still make a pretty penny.

Alas, my thoughts of earning a quick buck were not to be.

It didn’t come down to the app really, it was given some strong praise by Richard at WPCentral, was featured on the marketplace, got about 4.4/5 stars on average, 11,000 downloads and took a slightly fun and odd take to metro design.

I think the real problem was the different ways users behave on Windows Phone compared to iOS when it comes to buying apps due to the lack of trial mode. In the case of Fit of Fugly, this meant that people who were shown the app by a friend and wanted to try it on their phone just shelled out the inconsequential £0.69 for the app without batting an eyelid (iPhone users are younger an wealthier don’t you know).

On Windows Phone the trial mode makes the experience far better for users, less money wasted on apps that don’t do what they say, but for makers of gimmicky apps like myself at the time, it meant that people might try it for a bit and then decide it’s fun but not worth the money and never buy the full app.

For the trial mode in VizAge, I allowed the user to take and get the results for 3 images before they were then prompted to upgrade if they wanted to take more or compare themselves to some famous faces. In all honesty, it probably wasn’t a good enough value proposition for most and about 7% decided to go ahead and upgrade.

Don’t get me wrong, the app was by no means a failure (surprising given its power to offend if it got the ages wrong) as I recouped my investment (before the API was shut down by Facebook, – booo!) and I learnt a hell of a lot. However, it was clear to me that unlike the stories you read about in the paper of people getting rich “overnight” with their “hit” fart app it really isn’t all that easy and the apps gold rush where people will buy anything from a virtual pint to a lightsaber are truly over.

I figured I should concentrate on developing something more meaningful that won’t make me an app millionaire overnight and that is something far more useful and enjoyable for users to be a part of and for me to develop. With that in my mind, I started developing Foundbite.

If you disagree or had similar experiences, I’d love to hear from you:

Source Control, Team Foundation Service and your Windows Phone app

Source control is really essential when you’re working as part of a team on a software project but it can be just as useful when you’re working alone. This is probably obvious for many experienced developers but this is an article I would have found useful when I was just starting out.

For the development of my first Windows Phone apps such as Travelnapp and YuleTile I just saved my project to a code folder and occasionally backed up to a memory stick (I hadn’t heard of cloud storage at that point). Not only was there a lot to lose if I lost the backup and laptop, but I often found myself stuck with issues resulting from something I’d tampered with but couldn’t remember what.

If a late night’s coding gets the better of me and the next morning the app refuses to work I can now, using source control, look at the changes I made the previous evening and find the offending code.  Or if worse comes to worst, simply go back in time to before my tiredness took it’s toll on my code.

Now, with so many different tools and services available such as Beanstalk, GitHub and BitBucket to host your code repository which should you choose? If you’re largely a sole developer like myself you’ll probably want the cheapest, and it’s for this reason I swapped from Beanstalk to Team Foundation Service to host the Foundbite code repo.

Forget the name, Team Foundation Service is just as suited and useful for sole developers like myself as it is for large complex teams. It’s so easy bullet points are appropriate:

  • It’s free (for up to 5 devs) – yep, it won’t cost you a thing.
  • It’s heavily integrated into Visual Studio – pretty obvious but the ability to compare changes and view changelogs inside visual studio is handy.
  • There’s a nice web interface – The site is nice and easy to use to view changelogs and add new users.

There’s also lots of other features which I haven’t got around to using yet like continuous builds, test execution and agile planning. They’re all a bit foreign to me at the moment but I’m sure I’ll get around to using them eventually.

Have a look over at

Response time difference between Windows Azure extra small and small instances

This was originally posted on my old blog.

When Foundbite was in its very early stages I was using the Windows Azure Extra Small instance to host the API and with a very small number of beta testers the response time was more than fine, though did fluctuate a lot.

As the beta expanded and because I get a free allowance for Windows Azure through BizSpark, I decided to move my web role up to a Small Instance. Unlike the Extra Small, the Small instance is not shared with others and I was curious to see the response time gains that could be had. Turns out, they are quite significant:

Although I realise this isn’t a completely fair test as the number of requests and type of requests vary, it’s quite apparent that the response time dropped significantly. I hadn’t expected such a clear distinction.

You can see the difference in size between instances here, I have no idea how much an A7 costs but wow that’s a lot of power!

If you need help choosing an instance size, this article is also really useful.

The above graph was made using New Relic Performance Monitoring which you can get for free using your Azure subscription.