This blog post will walk through the overview of the technical architecture for the Stepping Into Time Android mobile app and the process we went through to define it.
Because of the nature and rapid speed of development of mobile technologies, some of the choices we made earlier on in the project have changed along the way, largely due to new options becoming available between the initial investigation and the building of the first prototype application.
Application framework – native or cross-platform?
The requirement for the project was to build a native Android app that people would be able to download to their handset from an app store to use enhanced features that we wouldn’t be able to offer them through the main project website – namely the augmented reality view of the bomb census data.
When building an app for a mobile device, you are writing code that will only be able to run on one platform (e.g. Java code for Android, Objective-C for iOS on the iPhone), meaning that if you want to release the app onto a different platform (e.g. iPhone) in the future, you’ll need to rewrite the whole thing in another programming language. As the project is only initially looking to release an Android app, this is perhaps not a major issue, but as we are planning to release the app code as open source, it would be good if it could be more easily extended at a later date, either for this project or others looking to do similar things.
Having had some experience in building Phonegap prototypes in the past, I had originally looked at Phonegap as an option for building the Stepping Into Time mobile app, but decided not to pursue it for this project as there wasn’t an Augmented Reality library available for it — at that point in time.
An initial prototype was built as a native Android application using the Wikitude augmented reality library (see my previous post comparing different libraries) and an Android-specific mapping library called OSMDroid.
The final decision will be made after we’ve built a Phonegap prototype, but this is looking like it will be the preferred choice.
Integration with the project website
Whichever way we build it, the mobile app will retrieve all of its bomb location data and historical mapping from the main project website and will use the same map tiles that the website uses.
Contemporary maps will be requested as tiled imagery from a mapping provider such as Cloudmade and used as the base layer for the map view.
The historical mapping will be requested as tiled imagery using the Web Map Service (WMS) provided by GeoServer and overlayed on the map view when needed.
I will post an update once we have built both prototype apps and decided which way to proceed for the final app.