This is one of the common requirements which we come across in many customer scenarios where the request is to integrate an external device or device-specific features with the SAP Fiori Application. But is this at all possible with Fiori being a web application framework? Don’t we need to create native applications in order to achieve this? Hold on, I know there are plugins provided by SAP, can we not use them to achieve this?
But what if the plugin itself doesn’t exist. How do we go about implementing this?
the custom plugin is the answer?
SAP does come with a number of plugins with which we can implement some of the standard device integration features. But not every scenario can be met with the SAP plugins. Well, to take care of this problem scenario, we need to develop a custom plugin using Cordova.
Cordova is a set of command-line tools and a plugin bridge for building native apps for the app stores that let us build our app in a web view, and call native code from JavaScript.
Building Cordova plugins means we are writing some JavaScript to call down to some Native (Obj-c/Swift, Java, etc.) code we also write and returning the result to our JavaScript.
To sum it up: we build a Cordova plugin when we want to do something natively that doesn’t yet have a Web API analogue, like accessing HealthKit data on iOS or using the Fingerprint scanner on Android.
Let’s take a deeper look at it:
Getting started: scaffolding our first plugin
Plugins: plugins everywhere, but how do we start our own? There are two ways to do this: we can use the plugman tool to create one quickly, or we can get all mitosis on an existing plugin by cloning it.
Basic steps are as below:
- Install Node JS
- Install Plugman
- After installing plugman, use it to create a new plugin project.
- Create a .json package
- Add a platform for which the plugin needs to work.
Configuring our Plugin
Now comes the favourite part: writing XML!!!
Okay, it’s not glamorous but the plugin.xml file is where everything happens and it’s where we should start. First, we need to give our plugin a unique name and id.
Next, we’ll set a reference to our JavaScript code. At a glance, js-module specifies the JS code that will run, and <clobbers> sets what window variable the plugin will be exported under. So, in this case, our script file is www/plugin.js, and when our app runs, we’ll be able to access the plugin at window.MyCordovaPlugin.
Once the above is done, we specify the platforms we are going to support, along with references to the corresponding native code for each, starting with Android. Inside <config-file> we can specify our Android package name and also the symbol Cordova will use to identify our plugin, in this case, it’s MyCordovaPlugin. Finally, we have a reference to our main Java code inside of <source-file> which is where our native code lives.
Building our plugin: JavaScript
Let’s start with the JavaScript API we’d like to expose to the developer. In this case, our JavaScript code lives in www/plugin.js. As an example, the developer can call this plugin by writing the following piece of code
window.MyCordovaPlugin.echo(‘Hello!’, function() { //callback })
The code that does the magic here is the exec function we’ve imported from Cordova/exec. When called, this plugin tells Cordova’s plugin layer to find the plugin identified by PLUGIN_NAME and send the action passed into either a function call (iOS) or a switching function (android). It’s a good practice to make sure the Cordova symbol name we give our plugin (in this case MyCordovaPlugin) matches the <clobbers target> setting from our plugin.xml, as that, will be the window variable we access.
Building our Android plugin
Building the Android part of our plugin is exactly the same conceptually, but Android plugins have slightly different semantics. For Android, we have one single execute method that Cordova calls with the action we put into exec() on the JS side, along with the arguments and callback context. Thus, instead of having Cordova call our method directly, we have to check the action string against each action name we support, in this case, “echo” and “getDate”.
Testing plugins
Smashing our keyboard and producing code is the easy part. Challenging part is to test and verify if our plugin actually works.
To test a Cordova plugin, we need to have a Cordova/PhoneGap/Ionic app to run. Cordova plugins are not runnable on their own.
Assuming we have an existing Cordova app, we can add our plugin locally:
Cordova plugin add <your plugin folder path>
To test the plugin, we just run our app like normal, using our standard Cordova debugging techniques (attach browser dev tools, use IDE console, etc.).
If something ever gets wonky or out of sync, just try removing the plugin and adding it back. If that doesn’t work, remove your platform directory and make sure all references to your plugin are gone from the plugins directory. This tends to happen if you change things like the plugin id or name.
@Team ROITech – Your SAP Fiori Factory,
Hope you found this blog interesting and useful. Thanks to @Suman Dey for his yet another geeky adventure story. Incase if you come across any problems with SAP Fiori, we would be happy to help you with a solution.