Native Cross-Platform Applications
3. Harness power of mobile devices through native cross-platform applications.
Developing an application for multiple mobile platforms (Android, Blackberry, and iPhone) has proven to be the most challenging piece of this project. Unlike the browser-based solution, a native application does not run on the web browser, but on the device itself. An application will run at an optimal speed and offer the user the functionality of a phone that is not available in a web browser, such as the device’s GPS, vibration, accelerometer, camera, or phone. But mobile devices rely on platform-specific development that requires programming in different languages, and imposes different limits on how code can be shared and licensed.
We understand that it is difficult for museums to develop for multiple platforms, so in order to help the museum community reach the broadest possible audience, our goal was to create a single development solution that works across three major platforms: Android, Blackberry, and iPhone. We hope to encourage further cross-platform development, which is why we are releasing this open-source code to our prototypes.
Go directly to the code: http://code.google.com/p/art-in-the-city/
The Phonegap application relies on the Art in the City Omeka installation we already created. There is a client/server relationship between the mobile application and the Omeka database. When a user installs and opens the mobile application on their device, our server is pinged to download specific data. When returning data to the device, the application formats that data in a specific way. This basic API (application programming interface) allows the application’s users to receive recently-updated information from the live Omeka installation.
In order to exchange data between the Art in the City website we created, and the mobile application developed using Phonegap, we needed structured information that could be accessed remotely. A variety of formats are favored online for exchanging data, such as XML-based specs such as RSS and RDF, or OAI-PMH. After several performance tests, we chose to access Omeka data using JSON, because the size of files containing information for the mobile device are smaller. The amount of data sent from the server to mobile application is an important consideration, especially if users have limited bandwidth or slow cellular connections. Omeka natively has a JSON output format, however we chose to create a plugin which provided additional metadata. The Enhanced JSON Output plugin shares data about museum collections, artwork, tags, and other information such as featured artworks.
Accessing a mobile devices hardware, notably GPS, distinguishes a mobile application from the mobile-optimized website. Most of today’s smartphones including Blackberry, Android, and iPhones come with a GPS that provides the geolocation of the device as it is being used. By integrating GPS functionality into our native mobile application, we are able to provide location-based search. When a user opens the application, they see a splash screen notifying them that the GPS will plot their current location. All artwork displayed within the application will be ordered based upon the physical distance from the user, and users will see the distance calculated for them. So, if a user stands at a street corner, they might discover four pieces of public art located within a 0.5 mile radius from where they stand. The user also may access more information about those artworks by browsing on their phone.
Finally, we complied all of the code used in our mobile projects. We generalized the Phonegap code so it may be translated into the necessary language for each mobile device. Compiling this code creates a file which can easily be downloaded onto a Blackberry or Android device. iPhone applications, however, must be approved by Apple before anyone may install them. Once approved, the application will be available in the Apple application store.
All code developed for these prototypes is available to download on Google Code, (http://code.google.com/p/art-in-the-city/). We released this as open source and invite anyone to test and expand it, and then to contribute back to the museum community by sharing your enhancements.