Write Once, Deploy Everywhere
When Lead Software Engineer, Bryce Mayrose, wrote about the Internet of Things back in July, he spoke of the myriad of devices that connect to the internet to transmit and receive information. The diversity of those devices demands an equally diverse collection of languages, frameworks, libraries, and techniques for getting software on those devices.
Today, we know that every single one of our favorite applications can be found on nearly every device we own from our wearables, to our phones, pcs, and even TVs. Should a company want to target all those devices, they would need to write applications for each one of them. As you can imagine, the costs of managing independent development for all those platforms is extraordinary. This is compounded when it comes to maintenance and replicateing new features and fixes across those systems.
Enter Apache Cordova. Cordova, in a way, acts like a minified browser that operates on all the aforementioned devices. But what makes it special is the integrated APIs that provide uniform access to the common features found in such devices. These are features like location services (GPS), accelerometer/gyrometer, camera, filesystem IO, and gesture observation.
Even on the same device (manufacturer and model), integrations with such sensors can vary across versions of the operating system. This makes implementations that are broadly compatible daunting; especially when you consider there are nearly 19,000 distinct devices running Android.
For this reason, when a partner is seeking to deploy an application on anything other than a desktop browser, we nearly always try to consider Cordova as an option.
Unified Language, But Any Framework
Google's Angular.JS framework is one of our most favorite pairings with Cordova. Aside from its flexibility to be extensible and its broad compatibility with other libraries, AngularJS is a winner because it turns the application into a Single Page Application. I touched on this in "Single Page Application SWOT Analysis" almost a year ago.
Single Page Applications
When we think of a web application, we commonly think of applications that involve flipping through pages and following hyperlinks. This is the complete opposite of what we come to expect from mobile applications where the experience is extremely fluid. Due to the high latency environment, returns to a server are readily noticeable by a user.
Cordova can, of course, be used to wrap an existing web application to quickly and cheaply get it on devices. In fact, we’ve done it before. If your user's have access to high speed internet, then that experience is extraordinary compared to trying to use your app in a browser. However, performance can degrade in high latency environments. If internet is inaccessible, the application is unusable. That’s simply unacceptable for most users.
When we pair Cordova and AngularJS, we are able to develop an application that behaves more like the typical mobile application. When AngularJS is compiled down with Grunt, all of the application resources get packaged together and installed on the device. Limited amounts of data can also be installed in this fashion. With minimal to no returns to the server, the application has all the fluidity of a native application, but with all the benefits of Cordova.
When Cordova is Not the Answer
No framework is perfect, and there are situations in which Cordova is not the best solution for your application. The obvious situation is video games. Video games engage the device's GPU heavily for complex calculations and renderings. While many games can and are written to run on Cordova, we still don't think we'd consider it optimal. We aren't game developers though, so what do we know?
Another might be when native libraries exist and you must integrate them heavily. Cordova does expose an API for invoking native libraries. Reasons may be things like video encoding, image manipulation, custom driver calls, or root level device interaction. Despite the compatibility, if you end up with a great majority of Cordova invoking those libraries, then you might as well have written the whole application directly in the device's native language to avoid over complexity of the ecosystem.