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:

We developed our prototype application in Phonegap <>, a cross-platform framework for building mobile applications. Phonegap allows developers to create mobile applications that are native to devices, programmed using only HTML and javascript that seamlessly integrate with device-specific installations. By using HTML and javascript, traditional web developers can now create mobile applications without requiring them to learn a new programming language, such as Objective-C or Python. In addition to being based upon these basic technologies, the pool of available developers with the necessary knowledge base to use Phonegap is much larger than for other languages, which makes using Phonegap an economical choice.

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.

Javascript is used within the mobile application to retrieve and display data from the Omeka website. To avoid starting from scratch, we used jQuery, which is a popular javascript framework. By using jQuery, the javascript code developed as part of our mobile development already performed several basic actions, such as displaying and hiding content on the screen, and retrieving data from a remote server. We focused on implementing code that would integrate with Omeka, and be reusable on other Omeka sites in the future. Similar language was used in the javascript as found in Omeka’s code, so that a developer who is learning both systems could avoid having to learn two different approaches to displaying collection data.

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, ( 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.