Accessing native mobile device functions in IBM Worklight using Apache Cordova

/in /by

Introduction 

In this blog we provide an overview of advantages using IBM Worklight mobile platform for enterprise solutions, and especially for leveraging the Apache Cordova Framework, which is intergrated within Worklight.

Mobile Enterprise Application Platform (MEAP) 

A mobile enterprise application platform is a comprehensive suite of products and services that enable development of mobile applications. The picture here comes from one of Perficient’s Mobility presentations and shows a generic MEAP platform.

Mobile Enterprise Applications Platform diagram

 

IBM Worklight Mobile Platform

IBM Worklight has the full capacity of MEAP, it allows to create exciting mobile applications by integrating multiple existing web and service applications. Using this approach you can easily deploy one integrated application to multiple platforms and multiple device types.  IBM Worklight provides an open, comprehensive and extensible mobile application platform for smartphones and tablets.

 

 

Apache Cordova

Apache Cordova is an open source mobile development framework that enables the creation of cross-platform mobile apps that can access native device features over a uniform API using web technologies (HTML5, CSS and JavaScript). Apache Cordova is integrated into IBM Worklight Android and iOS projects ( the combined share of mobile market for Android and iOS  is 84%). In this blog we will describe how to leverage Apache Cordova ability for bridging the Javascript interface on the web side with the native interface on the device platform.

PhoneGap

For more information regarding Apache Cordova please refer to http://incubator.apache.org/cordova/

For more information regarding IBM Worklight please refer to http://www-01.ibm.com/software/mobile-solutions/worklight/

 

Why to use Apache Cordova?

Web technologies based on Javascript (JQuery, Ajax, etc.) are the obvious candidates for the web side of a typical mobile application and are platform independent by their nature. Unfortunately their scope is confined within the web part of the application. When dealing with the native functionality running on the device platform (Camera, Internal Contacts List, etc.) Javascript  doesn’t prove to be very helpful. When a need is arises for a web page to obtain/execute native functionality the following alternatives are available:

  1. To implement the scenario in the platform specific manner (using Android or iOS, for example).
  2. To use a bridge between web pages and native page, when requests and responses to and from web and native pages are translated by both sides of the bridge.

Choosing the first option, we find ourselves creating platform depending applications. This is a poor choice for Enterprise Mobile solutions, as the need to implement a mobile applications on different platforms leads to cost ineffective solutions, which are also poorly extensible for the future needs. Using the second option, we benefit from overall control on the web-native communication flow, while keeping the solution platform independent (if not entirely platform independent, but with minimal effort required to shift between platform).

Additional benefits of using Apache Cordova

As an open, standard based framework, Apache Cordova comes with extensible architecture of plugins, that simplifies integration with native device code. In this case a developer can create a custom plugin, with functionality not yet available in Apache Cordova, and after wrapping it, to use it from Javascript code. Examples of out-of-the-box Cordova plugins :

  • Geolocation –  provides location information for the device, such as latitude and longitude.
  • Camera  – takes a photo using the camera or retrieves a photo from the device’s album.
  • Accelerometer – is a motion sensor that detects the change  in movement relative to the current device orientation.

If a need arises for a functionality not available within the out-of-the-box plugins, we can implement it using our custom plugin.

 

Brief description of  the process for implementing Android Apache Cordova plugin in Worklight 

A detailed description can be found at Module 9.03 ( Android Development Using the Apache Cordova Plugin) under https://www.ibm.com/developerworks/mobile/worklight/getting-started/

Android Apache Cordova plugin consists of two parts:

  • Java code which runs natively within the Android OS.
  • Javascript wrapper (an interface to Java code above).

Java code part of the plugin

  • Java code, implementing the plugin, has to extend org.apache.cordova.api.Plugin.
  • The plugin is implemented by overriding the  execute method of org.apache.cordova.api.Plugin.
  • Each plugin has to be registered in the res/xml/plugins.xml file :
  • While dealing with secure requests to the external domain, those domain can be white-listed in the res/xml/cordova.xml file, for example:

 

 

<cordova>

<!–
access elements control the Android whitelist.
Domains are assumed blocked unless set otherwise
–>

<!– allow any secure requests to example.com –>

<access origin=”https://example.com” />

</cordova>

 

Javascript wrapper of the plugin

Javascript wrapper to the Cordova plugin has the following structure:

CordovaCustomPlugin.prototype.executeNativeFunction = function(onSuccessCallback, onFailureCallback, param){..}

there

onSuccessCallback – callback function for successful call

onFailureCallback – callback function for failed call

param                     – parameter passed to the plugin from the calling web page

the plugin is added to the windows.plugin object.

cordova.addConstructor(function() {

cordova.addPlugin(“cordovaCustomPlugin”, new CordovaCustomPlugin());
});

and then it can be called from the Javascript by :

window.plugins.cordovaCustomPlugin.executeNativeFunction (onSuccessCallback, onFailureCallback, $(“#SomeInput”).val());

 

Leveraging Cordova Unified Interface

In case the application is to be run on different platform (say iOS), the following holds:

  • Javascript interface need not be changed (as Cordova provides unified interface along all the platforms)
  • The functionality implemented in Java inside the Android plugin, has to be implemented in Objective-C inside the iOS plugin
  • The definition of the plugin is put into Cordova.plist file (as opposed to plugins.xml in Android)