Windows Phone and a Solid Back End

I have now published 7 Apps to the Windows Phone Marketplace.  Some have been better than others.  I’ve discovered a great respect for those who create games… they are just, well, hard.  But a new emerging theme has been smacking me over the back of the head recently.  Windows Phone Apps and controlled Web Data (Azure?) go better together.

My most recent App, Border Wait Times, uses data.  That data is pulled from at least two sources, the US Customs and Border Protection (CBP) who kindly provide an easy to digest XML formatted document containing border wait times for key crossings and the Canada Border Services Agency (CBSA) who give you an html page that you better hope never changes.

The Setup

Now, the easy thing to do would be just to have my App run off to their respective web sites, process it and splat in some user’s phone and hope and pray that the data formats never change.  Getting data directly from the horse’s mouth is easy, it just isn’t necessarily smart.  When I designed the app, I actually did what I usually do, went lazy, and that turned out to be a very good idea for several reasons, some of which I haven’t even taken advantage of yet.

The Model

I needed to collect the data, but quite honestly going back and forth with my phone or even an emulator takes time and I’m in a hurry… always.  I figured a better way to go would be to write the code to fetch the data and mash it together in a simple C# desktop application.  Basically I used the WebClient object to aquire both the CBP XML data and the CBSA html data.  The Canadian data took a lot more grunt work to get the bits I needed but it was pretty simple.  Because I had the code to get the data (and there was lots of it) I decided I might as well just put it in a web service that the phone would call because I knew there would be problems, and fixing and deploying a web service was easy, no changes to the phone app required.

I setup the Border Wait Times to just call MY web service instead of direct through to the CBP and CBSA.  In my App, I just used the same WebClient() object (Asynchronously of course) to get the data from our server here.  Piece of cake.

The Hallelujahs!

Ok, so, why did doing this produce a big win and a recommendation that you should do it too?  Of course, this is assuming that your application needs external data from somewhere that you might not control.

Consistency of Format

I always know exactly what format the data that I get from the web service will look like.  No matter what CBP or CBSA does to their data, my App knows what to expect.  If CBP or CBSA changes their data format, no problem, I just update our web service right here in my office and I don’t have to submit any updates at all to the Marketplace.  The App will just work.  The other day, I encountered just such a change, although it would not have been noticeable, within minutes I had updated our web service and corrected the data.  The Windows Phone owner never had to do a blessed thing!  Sweet!

Another example, we received a support request asking if a particular border crossing that wasn’t showing in our App could be included.  Again, we just went back to the web service, included another data source and were able to provide the border crossing to the user on the same day the request was made.  The same thing works for the new Border Cam feature we just introduced.  If we get a request to add a Border Cam, we can also do that without any update to the App in the Marketplace.

Conservation of Data Bandwidth

The CBP xml file contains border crossing information for Canada and Mexico.  They also include commercial and non-commercial traffic.  As my app currently doesn’t do Mexico and we also don’t do commercial lanes there was a whole bunch of fluff there.  By having a centralized web service, I could grab the data, and then just send the data I really need to the Windows Phone.  The Canadian Data at CBSA was even worse.  It was HTML wrapped in all sorts of presentation stuff and CSS.  Huge in size.  Once again I could really cut the data down.  By consolidation I was able to reduce the amount of data actually going to the phone by a factor of 7.  So basically Border Wait Times uses 1/7^th the amount of data bandwidth to the phone that another app that goes directly to the data source would consume (from 140K to 20K).  Yikes! (unless you have an unlimited data plan, then never mind.)  To the right are the examples of the XML produced by our Web Services and that which is produced by the CBP.  I am only showing about half of 1 border's complete information for the raw CBP data, and they give you twice as many borders because of Mexico.

Performance

Well first, transmitting 1/7^th the amount of data is going to be faster.  Next, because the CBSA and the CBP only update their data once every 60 minutes, there really isn’t a lot of need to make lots of round trips.  If the data hasn’t changed just send it to the phone.  This can be a big time saver.  And the nice thing is it’s all controlled on our web service server and I can change it anytime things change without having to bother the phone user with an update.

Scalability

What if all of a sudden Windows Phone took off?  What if suddenly a few hundred thousand downloaded my app?  Now consider that they all are checking the border at the same time?  Do you think it might slow things down?  You don’t know how much traffic the government web sites that give you your data can handle.  Right now we host the web service on our own server.  But we did design things so that if there was greater demand, we could just shuffle it off to an Azure Cloud instance and then “ta da” instant scalability and no worries.

Customizability

And one other little tidbit.  Some of the information I need for a more complete App is just not provided by the CBP or CBSA.  No problem, with a web service I can add the information from another source or from a new source that we created for the purpose.  Either way, it allows us to offer things like Directions and Border Cams that we could not otherwise provide.

The End

Basically the big benefit I saw immediately was the ability to assist a customer who wanted an enhancement WITHOUT having to go through a development cycle including re-certification in the App Marketplace.  The other benefit was a change in the data format.  If I couldn’t fix that on the fly then I might have racked up a whole bunch of negative reviews waiting for the slow tick on the Windows Phone App Marketplace certification team.

Anything that saves my bacon is just a good thing.

See it in action with Border Wait Times