We now have the data, time to do something pretty with it.
As part of my Code for Europe project, I have setup a proof of concept Open311 server on Heroku that provides a subset of the data that we intend to have opened up by the end of the project. For now it simply returns some XML about the car parks in Aberdeen. The XML is formatted to match the Open311 API specification. As I’m currently working to release a Minimum Viable Product I’ve not gone as far as providing an optional JSON version of the output. As of the time of writing it is only the name and location of each car park that is returned. However, once a live feed of car park occupancy is made available behind the scenes then the server will be upgraded to present it as Open Data.
As interesting as raw XML can be to look at it is not going to fire the imagination of the people of Aberdeen – the intended audience for the data we are liberating. To allow the data to be visualised easily I decided to create a very simple mobile app that allows the user to:
- view a list of car parks in Aberdeen
- view a map showing the car parks in relation to the user’s current location
This simple app would also allow me as the developer to:
- fail quickly if required
- refresh my stagnant Android development skills
- have some pretty images to talk about
Return to Android development
The iOS platform is the one I’m more used to developing for, however there are some drawbacks to creating the demo apps for iPhone and iPad. The first being that it is not easy to distribute pre release apps out with the App Store environment. The second, and very important on a practical level, being that my liaison within Aberdeen City Council does not have an iOS device to try the apps out on.
This left the alternatives of Android or a HTML5 based pseudo app. Coming from the background of native app development, personally and based on my skill set, I’ve yet to be convinced that HTML5 is the way to go for me.
Things have improved since I was last here
Since I last released an Android app things have certainly improved in both the IDEs available and the way some of the things are implemented by the Android SDK. Previously I’d used Eclipse as the development environment but now there is the alternative of Android Studio. Even though Android Studio is still in beta, to me, it felt a much more enjoyable experience compared to my last outing with Eclipse. So much so that in about a day’s worth of development I had a working usable app. The slight downside of using Android Studio is that because it is so new many of the Android development examples in books or online are out of date or needed some understanding and reworking before they could be used. Of course this is nothing new as computing changes so rapidly that no one knows everything or if they do it is yesterday’s everything and they are out of date for today.
Car Park app
Behind the scenes the app consists of the following key parts:
- data download service (for downloading the data from our Open 311 server)
- data provider (for hosting the data in a local database)
- list display (for displaying the list of car parks)
- map display (for displaying a map of all the car parks)
- settings (for setting the data download refresh rate)
My test device for the development was an HTC One Mini running Android 4.?
As the app is purely a tech demo I decided there was no point in worrying about making sure the app runs on anything pre Android 3.0. Everything I required the app to do is supported from Android 3.0 onwards. (If anyone is really offended by my lack of support for some historical devices then please feel free to create a pull request of the source code and implement the the necessary modifications.)
Once the app was up and running I dusted down my old 2012 model Nexus 7 and tried running the app on it. With no modifications to the code required it was up and running straight away. This was another plus point over building an iOS version first as often some considerable work is required to make an iPhone app work well on an iPad.
Having managed to get a the MVP Car Park app up and running so quickly it was time to put the code reuse theory to the test. I wanted to see how long it would take to use the basics to build something new to visualise another set of location based open data.
This time I decided to use the sporting / physical activity venues in Aberdeen as my data set. Back in June I was part of a team who put together the MatchTheCity engine during Aberdeen’s inaugural Code the City event. One of the data sets MatchTheCity presents is a list of venues within Aberdeen City that sports or exercises classes take place. It also provides a list of reoccurring activities that take place at the venues during a week.
For my purposes I was just going to use the venues to display them as a list and on a map in a similar way to the Car Park app.
Behind the scenes this time the app consists of the following key parts:
- data download service (for downloading the venues from MatchTheCity server)
- data provider (for hosting the data in a local database)
- list display (for displaying the list of venues)
- map display (for displaying a map of all the venues)
The first difference between the two apps was that the internal database fields required changing as MatchTheCity provides a richer set of data per venue compared to the car park feed.
The second change was more substantial. MatchTheCity outputs its data in JSON format compared to the XML of the Open311 server. Replacing the XML parser with a JSON one was straight forward and within the space of a couple of hours I’d gone from an empty project to a Sports venue viewer. Or rather I thought I had. The venues appeared in their list but the map was blank.
After much searching through log files, doing clean rebuilds, restarting the IDE I discovered that I’d slightly misunderstood Google’s Map API key. I had thought it was one key per developer but it is in fact one per app. Once I added the app to the list in my Google account the map appeared.
I’ll admit both apps have potential for a lot further development before they are really useful, but that was not the aim of this exercise. The aim was to visually present the raw data we have and to test the reusability of the code. Both of those aims were met.