December 6th, 2011 by Chris Bailey
In this blog entry we discuss how we tackled the development of the nature locator mobile applications; why we made the decisions we did and what architectures we finally adopted for both the mobile apps and server-side technology.
We were lucky to have considerable design input with this project and right from the start we followed a user centred design approach to the development of this project. Questionnaires were used to gather feedback from individuals who’d uploaded photos in last year’s leaf watch trial. The results of this feedback clearly indicated that we should be targeting iPhone and Android platforms first as those were the devices most users owned. We also knew that publicity could be high as spots on radio and the BBC’s One Show last year helped generate public interest in the research.
After our initial requirements gathering, we started to think about implementation approaches. We were under considerable time pressures and only had about a month’s development time before the moths started to make an appearance in the wild. Given that we knew publicity on TV and radio could lead to a large surge in uploads, we needed a solution that could cater for large spikes in traffic. Clearly a cloud-based solution was an ideal infrastructure for this project. We looked at the two most popular cloud frameworks – Amazon EC2/S3 and Google’s AppEngine. After investigating each, the Platform As A Service (PAAS) approach offered by Google was a clear favourite. The lower costs to getting something up and running, coupled with the (almost) free usage and a well-developed tool set meant that we could concentrate on the code and leave the system administration to Google’s own engineers.
Having chosen the App Engine, we were still faced with a number of options for server-side development. The AppEngine supports Python (which has the most complete set of tools), Java and Go (their latest offering). The developers on this project were seasoned Java programmers so Java was our natural first choice. We were able to quickly generate HelloWorld projects in MVC frameworks such as Grails, Groovy, Gaelyk, Spring and Play and deploy them on the AppEngine to see how each framework behaved and how easy it was to work with them. From this analysis we chose the Gaelyk framework (managed by a maven gaelyk architype). Gaelyk is a Groovy-based web framework specifically written for the AppEngine. It essentially offers a thin layer over Google’s own APIs to make them play better with Groovy.
With the understanding that we needed to target iOS and Android end-user devices we started to look at frameworks that could aid development on mobile devices. The short timescales and reduced development effort (both developers had other projects on the go at the same time) meant we needed a single solution which could be repurposed for both platforms (and possibly others down the line such as Blackberry). Titanium and PhoneGap both offer frameworks for building apps using web technologies (HTML & CSS). The app can be packaged up as you would a native app but when it’s run, the device fires up a browser-based render which loads the initial web page. Some of the main advantages of this approach as it relates to our project are:
- Shared platform/repurposable code – both iPhone, Blackberry and Android use webkit-based browsers meaning that the HTML & CSS would be rendered in the same way. This enables us to reuse the same code across each platform – in the NatureLocator project, our final solution shares 95% of the same code across Android and iPhone platforms.
- Leveraging existing knowledge – for our developers (and more importantly designers) working with web technologies provides an already familiar environment for development without the need for any platform specific knowledge.
- Quicker development cycle – code could be run/demonstrated inside a traditional browser,and even hosted on a website for others to view.
The are also some disadvantages to web-based mobile applications that are worth noting. The main issue comes from the fact that the HTML code is interpreted by the webkit renderer which is itself compiled code. This additional processing layer results in slower execution of the code, most noticeably with graphically intensive operations. In our code, this became an issue when implementing slide transitions to mimic those found on native iOS apps. The designers and developers worked hard on making the NatureLocator application look and feel like a native iPhone application but there is still a noticeable difference. It’s interesting to note that the iPhone render handled slide effects much better then the Android one did using the same code. In the end we took the decision to disable transition effects for the Android release which leads to a much snappier experience.
Although all the frameworks we’re pretty good, in the end, we choose jqTouch which provided the best (smoothest) user experience, a nice abstraction between content and functionality as well as a good theme-based implementation of all the interface components we needed in our design.
The final codebase uses a common folder of resources (html, css & images). Outside of this directory there are specific iPhone and Android folders with the necessary project skeleton code. We also have a resources directory which contains design and artwork for the project along with the PhoneGap libraries. The PhoneGap iPhone build process uses Xcode and an accompanying build script to compile the resources into a single application package. For the Android platform we created a similar ant-based build script to combine and compress the files, while Eclipse was used to generate the final application package.