Cordova from the Trenches: Write Once, Run & Debug Everywhere!

Co-written by Gian Luca Ortelli and Ashkan Roshanayi.

Trifork was asked to develop a mobile app for crisis management in a “GRIP 1” crisis situation for Dutch municipalities.The users of the app are municipal employees involved during a crisis situation. The app was designed in co-creation with the involved municipal employees. But what is a crisis?

Welcome to the world of crisis!

Your mileage may vary but according to Dutch government there are different levels of crisis. Our project was targeted at situation “GRIP 1” meaning serious, but not too vital situation that requires the involvement of municipal employees besides other assistance crew like the police, ambulance and firemen.

Imagine there is a fire in a building. When someone calls 112, the police, fire brigade, ambulance crew and a person from the municipality (OvD-BZ) will be informed. The role of the municipal employee is to inform, assist and support people i.e. responsible for closing down the street, arrange that people have a place to stay, inform the mayor, etc. So this municipal employee has to make lots of phone calls, has to make notice of the situation and log all his actions, all according to a protocol.

So this was not about developing a mobile app for relaxed users sitting on their couch at home, but users in stressful situations that just want to get things done. They are not looking for the latest, most amazing UI transitions that are available in iOS 7.0.3 or Android 4.x.y. They needed focus and simplicity.

Other requirements, limitations, policies (you name it)…

It may sounds relieving to design an app that doesn’t need that much UI gymnastic but there were other requirements that shaped our decisions as the development team:

• the budget of the project was limited (which project has unlimited budget!?) and
• the desired target platform for the app was determined to be both iOS and Android

So the first obvious solution was going by a platform independent technology stack (e.g. HTML5). In general the app did not need specific services offered by the phone except for one small thing: we should be able to store files on the phone. However, as you probably know, storing files can not be done by using “pure” HTML5 because you need to be authorized properly. Therefore…

Add a wrapper framework to toppings!

After evaluating a few frameworks, we finally decided to use Cordova to build, package and deploy a “native-like” app. Cordova offers some nice abstractions on top of native phone functionality like file API that could be used to store files on device.

The promise of Cordova (and similar frameworks) is simple: developers who are good at html/css/javascript can leverage their knowledge to quickly develop mobile apps while staying within their comfort zone.

Obviously there are many other similar frameworks out there, but because of its good fit we decided to go for Cordova. However this doesn’t stop us from mentioning how much room still is available for technologies like Apportable (read our other blog post on this). To cut a long story short our technology / framework stack was:

• HTML 5
• jQuery Mobile for styling & themes
• WebStorage for storing data (SQLite)
• Cordova for accessing native functionality
• Dropbox.js SDK, a client lib for Dropbox API
• Cordova plugins: File API, InAppBrowser and CDVPDFViewer
• Mustache.js
• add2home.js
• TestFlight for easy beta testing distribution

The challenges

Despite our good take off especially with webstorage, challenges were waiting for us:

• Event handling – Webstorage uses asynchronous callback functions, that you can use to update listviews. Aligning this with JQuery Mobile events is quite challenging.
• Dropbox integration. For the integration we used a Dropbox.js SDK. In general this worked fine, but we had to tweak some parts to make it work smooth. We ended up using the default “Redirect driver”, which is not the nicest solution but at least works on all devices.
• Cordova development in team:  the development environment of Cordova  is platform dependent. This makes the usage of the Cordova CLI (which is the preferred way from version 3) not very easy when working on different environments. The behavior of “cordova build android” and generated artifacts could be very different for developer on windows and linux. This is not rocket science neither unsolvable but it takes time and attention to setup your environment, put things in a SCM, ignore some other from SCM and get confident with your individual and team workflow.
• 90% shared – 10% separated code between iOS and Android. Obviously we hoped to be able to write the entire application staying platform independent, but that didn’t work out. In particular the Dropbox integration and some inter-app communication (being able to open a PDF file from the application) required to spend time on iOS or Android specific tweaks. Android required less effort (not even 20 lines of code) but iOS required much more specific tweaking. At the end the time spent on platform specific issues, especially on iOS, took more than was expected.
• Tooling for cordova projects can be improved. This can be a minor issue but if you are using e.g. Xcode for building and emulating a project then you will miss the power of a true html/css/javascript tool that can be handy in a cordova project. So if you need defacto features like refactoring in javascript you will find yourself hopping back and forth between Xcode and Textmate/SublimText/… it looks like java development in notepad 8 years ago!

Lessons we learned on the way…

• Test and debug everywhere. Especially for iOS we were confronted with the fact that some of the Cordova builds didn’t run on certain devices,  and some builds did. The build configuration settings were identical. This is probably due to some build configuration setting “under the hood” of Cordova. Unfortunately we didn’t have the time to investigate this yet…
• Cordova is designed from start to be extensible using a plugin architecture. It means that if you need a specific functionality that is not provided by off-the-shelf plugins, you can develop it and in theory plug it in & play. There are already quite some plugins available for Cordova, but we needed a proper PDF viewer on the iOS which was not available off-the-shelf. Writing a plugin is not as easy as it seems as the supporting documentation is quite limited.
• Use one platform for development and deployment. Developing on OSX makes it possible to deploy on iOS and Android. So make sure you all have macs…