To date, the majority of our efforts on this project have been focussed on developing the MCA web server. This is partly because as a web platform it’s already accessible by most mobile phones, but also it serves as the main repository for our data. With the last couple of weeks on the MCA project, we just had enough time to try a little native iPhone and Android application development.
As an Android user with an interest in the platform, I chose to develop an app for the Android application. As we had very little time to create any new functionality, instead we chose to (re)implement the busstop departure times map from the MCA website. This application overlays all bus stops within the City of Bristol on to a Google Map. When a user clicks on a bus stop icon, the system issues an ajax request for departure information from this stop. The server acts as a proxy to scrape the live departure times from the NextBusBristol website and return them as a json string.
The web version of the bus stop application
{
"stop":{"id":"0100BRP90231","name":"Park St Top (Da)"},
"departures":[{"service":"9","due":"4 mins","destination":"Cotham-Redland-Zoo"},
{"service":"8","due":"8 mins","destination":"Clifton-Zoo-Redland"},
{"service":"8","due":"19 mins","destination":"Clifton-Zoo-Redland"},
{"service":"9","due":"22 mins","destination":"Cotham-Redland-Zoo"},
{"service":"8","due":"27 mins","destination":"Clifton-Zoo-Redland"},
{"service":"9","due":"32 mins","destination":"Cotham-Redland-Zoo"},
{"service":"9","due":"39 mins","destination":"Cotham-Redland-Zoo"},
{"service":"8","due":"44 mins","destination":"Clifton-Zoo-Redland"},
{"service":"9","due":"49 mins","destination":"Cotham-Redland-Zoo"},
{"service":"8","due":"54 mins","destination":"Clifton-Zoo-Redland"},
{"service":"9","due":"59 mins","destination":"Cotham-Redland-Zoo"}],
"base_time":"16:11"
}
Implementing the same functionality as a native android App gives us a couple of advantages over a purely web-based application. Firstly the user experience is more intuitive and fluid – rather then displaying a map in a webpage inside a browser, the map is the application. Users can zoom, scroll around and expect the same level of interaction that they get from the main Google Map application. Secondly we can use a database behind the scene to store our bus stop information and cache departure times. This gives us at least some form of off-line access and speeds up the responsiveness of the application. Finally, without the surrounding website chrome, the application can fill the whole screen and allow more departure information to be listed (the website version only shows the next 6 departures for a given stop).
Using and Android platform, we could harness some of the additional features supplied by Google API’s; a set of libraries for interacting with various Google services. For this application we used a MapView instance, which provides all the code needed to render a Google Map on screen. It also gives us the ability to easily show the user’s current position (as determined by the device) and overlay our bus icons. Unfortunately the MapView does not provide a popup window as you get for the web-based map API when an icon is clicked on. Instead we create a secondary dialog window which displays the necessary information. Although more programming is required, it does let us be more flexible with the window and it can easily expand to fill the whole screen allowing us to show more departure times.
public class BusTimesActivity extends MapActivity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
...
// obtain an overlay of the user's position
mMyLocationOverlay = new MyLocationOverlay(this, mvMap);
// enable the mobile/gps location information
mMyLocationOverlay.enableMyLocation();
...
}
}
A problem faced on both the web version and the android one, is handling the rather large dataset we have to work on. The official National Public Transport Access Node (NaPTAN) data set for bus stops in Bristol provides us with over 1700 locations. On the Android application, these locations are downloaded and saved to a SQLite database when the application is first run. If we took the simple approach and tried to overlay them all onto the map then this would require a lot of memory and slow down the response rate of the map. Even on a desktop machine with a large amount of memory this was found to be impractical. Instead we intercept the request to render icons on the map and filter out stops that lay outside the visible region of the screen. This approach works when the user is looking at a close-up section of map, however as the user zooms their map out, more and more stops will still need to be displayed. On the web version of this application, a limit was imposed on how far the map can be zoomed out. While this works, the user’s experience is a little clunky as the map initially zooms out and then automatically zooms back in again. For the native app, we looked to alternative solutions. To handle rendering bus stops for the visible region of the screen only, we used the excellent mapview-overlay-manager by christoph.widulle. To handle the zooming problem, as the user zooms out and the number of stops that need to be displayed increase beyond a pre-determined maximum value, the system drops into a secondary display mode where bus stops are merged together and replaced by an alternative ‘?’ icon.
The view when zoomed out
When this happens, the user needs to zoom back into the map to a level where individual bus stops can be rendered before being able to click on an icon and getting departure information. In addition, if the zoom level has reached a certain threshold, the system simply ignores all bus stop data and provides a single alternative icon over Bristol. A last performance enhancement measures the length of time it takes to calculation bus stop locations in this secondary mode – if the processing time exceeds a threshold value, the system will stop further calculations and render just what’s been calculated up to that point.
Developing environment
I followed the majority of android developers by using Eclipse with the Android ADT Plugin module. This provides an an easy hook into many of the Android SDK’s tools, including an excellent debugger, an emulator with which we can send ‘faked’ GPS coordinates to, and a great tool for taking screenshots.
Eclipse + Android developing environment
Future directions
There are several more ways this application could be extended. For instance some of the bus stop data provided by NaPTAN is incorrect or out of date. It would be good if we could allow a feedback mechanism so that users of the application could identify old or new stops and update not just their local database, but also the central repository on the server. There are many more ways the application could be extended by harnessing this form of community-driven feedback mechanism. Another way the application could be enhanced is to allow users to store their favourite stops, so that departure times could be looked up instantly without having to navigate to each location on the map. Using background services in Android, we could even register alarms to alert the user of scheduled departures, or inform them whenever they approach a bus stop.
The code for this project will appear on the MCA project’s GitHub account.
