As the number of smartphone users who can consume data continues to increase we are constantly seeing an ever an increasing number of industries that are putting there data out there for consumption.  A few years ago, Codemash, one of the biggest conferences in the country, was among the first computer conferences, that I know of, to do this.  They exposed REST feeds and challenged attendees the create applications for conference goers.  Since then, most, if not all, conferences seem to be doing this in one way or another.

While the idea has been a huge hit, it is not without its problems.  For one thing, conferences like Codemash always seem to tax the internet (both cellular and LAN) to the point that it tinkers with being unusable.  It is also a known fact that conferences undergo session changes during their course.  This meant that a REST feed was being updated.  In general, there was no way to let app users know of these changes, without redownloading the session list.  As you can imagine, with the Internet already being slow this amounted to the app being nearly worthless next to a provided book (I noticed this at DevLink).

My idea, create an infrastructure to record these changes into “changesets” and push a notification to the user.  I figured if I took advantage of Push the user would not have to actively engage in looking for changes, but could be told when they existed.  The Codemash Windows Phone apps are the first version of this system that I hope to expand out much further, provided it is successful at Codemash.

The Poller

One of the things that was essential with this solution was the ability for changes to be recorded.  Since I didnt want the user checking because of slow Internet or (in the case of a background task) heavy battery consumption, I felt this should be done somewhere else, and what better place than in the Cloud with Azure.

I devised a single worker role which, every 30m, queries the REST API for Codemash Sessions and Speakers and compares the data with the existing data.  It then updates the existing data, creates a changeset for the changes, and then pushes a notification out to registered clients.  The clients must store their client type, so the notifications can be appropriately structured (Win8 vs WP8 vs WP7).

To make this easy, and eventually support Apple and Android clients, I utilized Ninject to inject the appropriate notification manager class depending on the client type.  This allows me to continually support new clients without changing my Poller.

The API

Codemash has its own API which will always be the most up to date.  My cloud server also contains its only local copy of the Codemash data which is kept in sync for new clients as they register.  This ensures that new clients arent not behind in terms of the state of their data.  The API is responsible for handling registration and change querying.  To get changes, the app merely sends a request (along with its client identifier) to the Change controller.  The API users this identifier to ascertain what the last confirmed changeset the client received was and if there are any new ones, if there are new ones, they are sent to the client for processing.

The Apps

So now we come to the apps, the most crucial pieces in this process.  I had a few issues that I wanted to make sure I overcame, otherwise the apps would not achieve what I wanted them to achieve.  I even ended up scrapping the Windows 8 client so that I could ensure the Phone apps were solid.

The biggest rule for the apps was to ensure that they queried as little as possible and that when a query that could take time happens it does so in a way that would still allow the app to load quickly.  The goal is to give the user the quickest startup time so that the app can legitimately replace the book.  With this in mind, there is only one mandatory blocking internet call, and that is the initial populations.  Beyond that, the only querying done is for changes, which is done each time, but done once the app has loaded so as not to inhibit the UI experience.

With this mind, after the initial call all session and speaker data is stored locally and updated locally as changes are brought done.  When changes are brought down they are applied and the user has the option to view those changes.  The result is an app that, after the first run, can start in under one second and with the initial screen aimed at displaying what sessions are next and what sessions the user has favorited.

This means that when the network is clogged at Codemash, the app will still open up quickly and let the user browse sessions without needing to download anything.

Conclusion

Having written an app in the past for Codemash, and more recently for DevLink, it is clear to me that one of the problems is the lack of consistency in the data provided.  For example, the DevLink sessions provided a unique session and speaker identifier values which made things easy.  However, Codemash does not provide such a value, so I had to resort to hashing the session title to generate the identifying value.  As you can imagine, this is going to easily break if the session title every changes.

What really need to be created is a common service which can allow conference planners to put their session and speaker information into a common database.  This way the data is consistent for conferences and the ability to reuse data is provided, this feature has many advantages.  This would allow us to define a common schema for JSON and XML for consuming clients.