Thursday, 31 January 2013

M25 for WP8 Reviews

My M25 app for Windows Phone 8 has been in the store for a couple of weeks now and has gotten some positive reviews, currently with a 5-star rating.  Here's a few (I know...shameless self-promotion):

"Where have you been all my life!! The at a glance section for each junction is a brilliant feature and showing all the planned roadworks is great."
"Awesome app if you use the m25 daily"
"Just downloaded and had a quick play with it - so surprised someone hasnt come up with this app sooner - I live in Romford and regularily use the bridge and tunnel to get to and from Dartford. Will stop me blindly driving into the car park at the toll booths. Good job. Its well presented and the route plan and planned roadworks info are great additions - at a glance section is genius. Left you a short 5 star review as well. Thanks Ron"

From the official Microsoft User Community:
"Great work on M25, Ron! Just showcased the app to the community. Next time we're in London we'll be using it. :)"

And my personal favourite...
"Ooooo. This is good :-)"
I've got a minor update coming out in the next couple of days.  Anyone who has installed it will find it as an update in the store.

Thursday, 24 January 2013

New UI Gallery

I've added a link in the header toolbar to a UI Gallery, with some examples of my WPF/Windows Phone work.

Here is the link to the page:

Sunday, 20 January 2013

M25: My First WP8 App - Part V

One of the areas which gave me some grief was the ScheduledTaskAgent.  It was important the the app periodically refresh its data and update the Live Tile.  Setting this up is pretty simple, however, getting it to behave proper was another.

You can think of ScheduledTaskAgents like a mini-Windows Service.  Once a ScheduledTaskAgent is  registered the OS will run it every approximately every 30 minutes allowing it to do its business and you have 10 seconds to do your thing.  This is done through the ScheduledTaskAgent.OnInvoke method.  With my app, my ScheduledTaskAgent needed to re-fetch all of the latest traffic data, process it and update any Routes (if defined).

Within my M25.Data component I have a RefreshTrafficData method which is marked with the new async keyword.  This was done to allow the WP UI to retain control while the DataManager was busy fetching and processing new data.  The DataManager fires appropriate events, such as DataTransferStarted and DataRefreshed, to allow the UI to display a progress bar.

While all this works wonderfully from the WP app, calling this method from the ScheduledTaskAgent is another matter.  When refreshing traffic data we don't want this to run asynchronously, since we need to take the result of the refresh and update our Live Tile with the new data.

To make a long story short, I ended up creating a new method in the DataManager which effectively was a wrapper around RefreshTrafficData, but which returned a Task object.  By returning the Task object I can this call the Task.Wait method from within the ScheduledTaskAgent.OnInvoke.  Execution will pause until completed and proceed to call the NotifyComplete method signalling the end of our operation.

There are a couple of extension methods which I found/created which were beneficial.  The first method addresses the fact that in WP8 WebClient.DownloadString has been removed and replaced with the asynchronous DownloadStringAsync (which fires the DownloadStringComplete event with the result).

The DownloadStringTask extension method allows you to call DownloadStringAsync synchronously, if needed.

public static Task DownloadStringTask(this WebClient webClient, Uri uri)
            var taskCompletionSource = new TaskCompletionSource();
            webClient.DownloadStringCompleted += (s, e) =>
                         if (e.Error != null)

            return taskCompletionSource.Task;

This allows you to do this:

Task data = new WebClient().DownloadStringTask(new Uri(SOME_URL));
await data;

if (data.Exception == null && !string.IsNullOrEmpty(data.Result))

The other extension method relates to setting the BackContent of a Live Tile.  WP8 introduces a new large size to Live Tiles, so now the user can pick between small, medium and large tile sizes.  In most cases you will want to display dynamic information on the back of your tile.  But, there is no way of know which size the user has selected for your Live Tile.  Forget about the small size, since it does not permit back content.  Unfortunately for medium and large sizes the text WP does not provide automatic wrapping of text, so you will have to do it yourself.

Per MS documentation, the WideBackContent takes 27 characters, while the BackContent takes 13.  The
GetTitleLines extension method allows you to parse your Live Tile data into lines of text to accomodate both WideBackContent and BackContent.

  public static List GetTitleLines(this string theString, int wordCount)
            string[] parts = theString.Split(' ');

            var lines = new List();

            string line = string.Empty;
            int index = 0;
            foreach (string part in parts)
                if (!string.IsNullOrEmpty(part))
                    if (line.Length + part.Length + 1 <= wordCount)
                        line += part;
                        line += " ";
                        line = part;
                        line += " ";


                if (index >= parts.Length)

            return lines;

Here is how you can use it:

  private void SetLongData(string data)
            List lines = data.GetTitleLines(27);

            if (lines.Count > 1)
                foreach (string line in lines)
                    LongData += line + "\n";
                LongData = lines[0];

        private void SetMediumData(string data)
            List lines = data.GetTitleLines(13);

            if (lines.Count > 1)
                foreach (string line in lines)
                    MediumData += line + "\n";
                MediumData = lines[0];

In the next part in this series I will be wrapping things up.

Tuesday, 15 January 2013

M25: My First WP8 App - Part IV

Concurrent with my UI experiments, I began researching sources of data.  This work ended up consuming the most amount of time.  I had a number of potential candidates, including the RAC and Twitter, as well as the Highways Agency and Transport for London.

In recent years, the UK government has invested in opening up transportation data to the public.  This may explain why we see a growing number of public transportation (bus, tube, National Rail,etc) mobile applications.  I spent several days exploring all the data feeds and schema, looking for something suitable.  In addition to wanting to keep my app small and lightweight, I did not want to be forced to pull down unnecessary data and process it on the mobile device.  This was a case of too much information.  Certainly forcing a mobile app to pull down 25MB of unfiltered data was out of the question.

Twitter feeds were also on the table.  However, Twitter has recently announced upcoming changes to its usage policy, such as deprecating RSS feeds.  As well, relying on a Twitter feed puts me at the mercy of a third-party, which could change its privacy settings, effectively putting me out of business.  I also did not want to dive into the whole oAuth area at this time.  So, I backburnered Twitter for version 1 and ended up going with the Highways Agency RSS feeds.

Highways Agency (HA) RSS feeds were ideal for my requirements, offering:

  • Easy to ready XML schema
  • Small, lightweight payloads
  • Offered feeds specific to the M25

I ended up using three HA RSS feeds:

A combination of these three feeds gives me all of the planned events for the M25, as well as unplanned (e.g. accidents, congestion, emergencies, etc).  So all I had to do is pull this data down, parse and process and update my UI.   In the end, a relatively straightforward operation.

In sticking with my original core functional goals, I had my reliable source of data.  I can still introduce other data sources in future versions, including images, enhancing the app and its usefulness.

Sunday, 13 January 2013

M25: My First WP8 App - Part III

Once I determined what my version 1.0 feature set would be I next started work on the UI.  I know other developers who approach it differently, starting with a data model and working their way to the UI.  I've done both and I prefer starting with the UI and letting that drive the model.  This is more of a needs-based approach.  The best approach is the one that works for you.

During this phase I did quite a bit of prototyping and experimenting.  At one stage I envisioned having a clock-like representation of the circular M25, with each junction positioned in its relative position along the rim.  While it was pretty cool, there were usability issues due to limited screen real estate and the number of junctions on the circle.  Unfortunately I had to abandon what was going to be a centerpiece control for my app.

Instead I went with a more conventional edit screen and list picker.

The governing reason for this decision was usability.  It was simple and intuitive.

Early on I had decided to adopt a colour-coded status (red, amber and green) to indicate traffic status.  I wanted to keep things simple and not complicate the user experience.  I wanted the user to simply glance at the screen and get an immediate feel for the traffic conditions.

After reviewing some sample data from the Highways Agency related to the types of incident reports, I came up with this:

The result is the My Routes page:

I chose to use the Cambria font as a title font instead of the standard Segoe WP, more for aesthetic reasons. The same colour convention was used throughout the app, as in the Junction List page:

Another temptation was to incorporate the built-in WP8 maps functionality.  Again, my objective was not to create a SatNav application or journey planner, but to keep the app focus on the current traffic conditions of the M25.  That said, there was a point where I felt access to maps was relevant and potentially useful.  On the Junction Detail page I display a small map snapshot along with traffic data for the junction.  From here the user can jump to WP8 Maps using this location.

That's pretty much the summary for the UI development.  A lot of experimentation occurred to arrive at this point.  Some developers may view the Modern UI (formerly Metro) as being simple or easy to design, and in some respects it is.  I don't claim to be an expert in Modern UI design or that my app is a standard reference.  I do think that working with the Modern UI shifts the emphasis of design.  Instead of making something look pretty or have a wow-factor, the designer is really focused on information and how best to express that on the screen.  To some degree our GUI design legacy leans toward complex UIs.  Modern UI is forcing us to revisit and rethink user experience, stripping things back to the basics.  This is an interesting process, and ultimately a rewarding one.

M25: My First WP8 App - Part II

For anyone considering developing a mobile app, whether for WP or others, I think having a well-defined purpose is the first step.  After all, the app is supposed to do something, right?  I may be stating the obvious, but there are some subtleties here worth recognising.  Initially I wanted to incorporate real-time traffic speed, CCTV cameras, Twitter feeds, etc.  While these are perfectly valid features, including them in the first cut may not fit in my timeline.  So, I stripped things down to the basics, which included:

  • Pull down current traffic information
  • Pull down known planned events related to the M25
  • Allow the user to define routes
  • Display status information
  • Use a background agent to display current data in a Live Tile

So, this was my list of core functionality or deliverables.  Regardless of any extra bells and whistles, the app had to solidly deliver this set of features.  As well as naming those items "to do", you should also be aware of what "not to do".  I set a personal target to get this done within the month of December.  Given my time constraints I felt this was doable.  A lot of the other ideas I had are still valid, but can be added to my roadmap for future versions.

I created a new solution in Visual Studio 2012.  To my solution I added a Windows Phone application targeting Windows Phone 8.0 called M25.WP8; a Windows Phone class library called M25.Data; and a Windows Phone Scheduled Task Agent called M25.Agent.

I knew from my feature set that this was the minimal architectural requirements.  M25.Data would do all the data management and processing.  While the M25.WP8 phone application tended to the UI/UX requirements and M25.Agent was dedicated to running in the background and updating the Live Tile.  Not shown in the diagram is the reference between M25.Agent and M25.WP8; to get your Task Agent to be recognised by Windows Phone it has to be associated with an application so it gets included in your xap.  Pretty straightforward.


M25: My First WP8 App - Part I

I will be publishing my first Windows Phone 8 into the Windows Store in the next day or so.  It is called M25.  For those outside the UK, the M25 is the London Orbital motorway.  Like a huge wagon wheel, the M25 circles London with spokes running to the heart of the city.  It is the UK's busiest motorway, and some say in all of Europe.

So why create an app for a motorway?

For three years I traveled the M25 every day, and every time you plan to get on it you wonder what state it's in.  My carpooling passenger and I would have a routine when leaving the office; checking various web sites to determine whether we should even get on the M25.  Anyone who frequents the M25 has their own horror story of spending hours on the M25 parking lot.

I know what you're going to say - but, surely any decent SatNav app is going to tell you the traffic conditions of the M25 - and you would be correct.  But, the point is, I know how to get home.  And maybe I don't want to tie my phone up running Nokia Drive, when all I really want to know is happening on the M25.

What I really want is a lightweight app that is going to give me current, accurate traffic conditions for my section of the motorway.  I don't want to have to wade through traffic data about other motorways or even other parts of the M25 (the M25 is about 115 miles in length).  I'm just interested in what is happening between junctions 13 and 6.  So, I'm looking for the ability to filter traffic data from the volume of information pushed out by the Highways Agency.

Here's what I came up with:
So, that was the motivation for creating this app.  In subsequent articles I will discuss some of the issues I encountered, both technically and functionality.

I'm fully aware that this app is not going to set the world afire.  Developing it was as much for my benefit as it may be for others.  That said, I do think that it may prove valuable to those who wrestle with the M25 on a daily basis.

Thursday, 3 January 2013

USB Dongles and Serial Ports in .Net

I have spent the past three years working on mobile field applications for Centrica, mainly on the Smart Metering team.  One of the challenges we faced was with the use of USB dongles that create serial ports.  In our application we used a Zigbee USB dongle manufactured by Telegesis.  This dongle would be attached to a Panasonic H1 Toughbook and the Smart Energy Expert would proceed to commission/decommission smart devices.  Due to the design of the H1, the USB dongle would inevitably get knocked off abruptly terminating the serial port communications.
If you are reading this article you are probably familiar with the well-documented Serial Port issues in the .Net framework.  Many in the .Net community have declared .Net's Serial Port support to be unreliable at best.
In the above scenario, you will become aware of the removed USB dongle when you attempt to read or write data to the serial port - the serial port that no longer exists.  Unfortunately this is not a case where you simply wrap your code in a try/catch and you're good to go.  What you will likely experience are Windows IO exceptions or Dispose exceptions.  When these occur your application cannot recover from them, nor can you trap these exceptions.
Zach Saw has written an excellent blog on this type of scenario here. While this proposed solution goes a long way to resolving this situation, we were still getting unpredictable (and unrecoverable) exceptions.  I have to admit this was a tough nut.
In my research I stumbled upon an MSDN article written by John Hind entitled Use P/Invoke to Develop a .NET Base Class Library for Serial Device Communications written in October 2002.  For all you .Net historians, you might recall that SerialPort support in .Net did not appear until version 2.0.  So, here was John effectively rolling his own using Win32.  A brave soul.
Could it be that a 10 year old piece of code held the answer to our problem?  At this point I was willing to try anything.  Something about it made sense.  This approach removes Microsoft's dodgy SerialPort implementation and relies on the much more stable Win32.  Implementing John's code into our project took a bit of finesse, but we got there and it worked beautifully!
Since finishing up at Centrica I've had some time to put together a sample solution which implements John's code (with changed naming conventions and formatting) and includes a simple Zigbee Test application.

The sample uses WMI to detect the removal/insertion of the USB dongle (there are other ways to do this).  And utilises the custom Serial Port from John Hind.  You can download the solution here (

Wednesday, 2 January 2013

Beta Testers needed

I am close to publishing my first Windows Phone 8 application and would like to enlist the help of some beta testers.  Ideally you would be in the UK, but not essential.

If you are interested please contact me: ron(at)gramann(.)co(.)uk

Nokia Lumia 920 and WP8...Good News, Bad News

Well it has been quite a while since I've posted anything on this blog.  My bad.  Then a couple of months ago I upgraded to the new Nokia Lumia 920 and felt I had something worth blogging about.  Just as I sat down to compose a glowing review of Nokia/Microsoft's latest offering my 920 bricked.  Soft reset, hard reset - didn't matter, my 920 turned into a sexy paperweight.

After a quick call to Phones4U tech support and a visit to my local shop I had a brand new 920.  While I may have a certain tolerance for these types of hiccups, the general public does not.  In this situation it was clearly a software/OS issue.  The buttons and screen became non-responsive, but if I removed my SIM card the phone came back to life.  Unfortunately there was nothing I could do to resurrect my 920.

Since then I have not had any issues with my replacement.  In fact, I couldn't be happier.  It is a solid quality product from Nokia.  The battery life is impressive, on average I can go for a day and a half without charging - with WiFi enabled.

Windows Phone 8 is fast and fluid and is a perfect marriage with the 920.  The colours and sharpness of the screen is stunning. And the dual core processor is ample to bring about a thoroughly enjoyable WP experience.

All-in-all, I'm quite happy with the 920 and WP8.  I would not go back to the Lumia 800 and WP7.5, not that there was anything particularly wrong with it, it's just that the 920 is so much better all round.
If you recently purchased a 920 you can receive a free wireless charger from Nokia, just go to and fill out the form.  I've had mine for a couple weeks now and love it.

Update 25 Jan - My 920 is still going strong.  I have had two or three incidents where the OS locked up while running an app, forcing me to do a soft reset.  Battery life is still outstanding.  I've dropped the phone a couple of times, but no harm done.  I recently noticed a small scratch on my screen which is annoying.  I have no idea how that happened.  The wireless charging is fantastic.  Next step is to get some NFC tags...