Tuesday Sep 29, 2015

MAF and OS X El Capitan and Xcode 6

UPDATE - It's official.  The Apple Developer page Submit your apps to the App Store states "OS X El Capitan requires Xcode 7. If your app still depends on Xcode 6, you'll need to keep a partition or external hard drive with OS X Yosemite installed in order to submit from Xcode 6."  That sounds like too much effort to me, so I recommend you simply stay put on OS X Yosemite for now while the current version of MAF requires Xcode 6.

Apple today announced that OS X El Capitan will be available on Wednesday, September 30 as a free update for Mac users.

There have been reports of incompatibility between beta releases of OS X El Capitan and Xcode, with Apple suggesting a workaround on the Apple Developer Forums here. Whilst that post makes it clear that Xcode 7 will be fully supported on OS X El Capitan, it remains unclear whether Xcode 6 will be fully supported.

MAF 2.1.3 requires Xcode 6. 

As soon as OS X El Capitan is released, the MAF development team will commence certification of MAF 2.1.3 using Xcode 6 on OS X El Capitan.  Until this certification has been completed, you may wish to remain on your current OS X release.

Sunday Sep 27, 2015

Samsung is in the house!

When it comes to making a presence, Samsung knows how to go big. In addition a sizable dedicated booth presence, we're excited to announce that Samsung will be the lead sponsor for the Oracle Mobile Showcase in Moscone South!

Welcome Samsung!  We're looking forward to checking out all the cool mobile phones and tablets - and dare I wonder, will they also bring their recently announced Gear VR (virtual reality headset recently announced, using Oculus software ala Facebook)?  I know it's not out until November, but given how close we are, maybe some early models perhaps?  OpenWorld is an ideal techie community and offers up a perfect audience.

A quick link for mobile - check out the Focus on Mobile list which will help guide you to some key mobile related sessions and events at Oracle OpenWorld 2015.

Follow us @OracleMobile

Monday Sep 21, 2015

Mobile @ Oracle OpenWorld 2015

About a month to go and we're set for another ginormous event - Oracle OpenWorld 2015!

At the center of the tech universe is mobile of course. I mean, what else is transforming our lives more than mobile? What is the one thing you can't leave home without? The first thing you look at in the morning? Do you still use an old fashioned alarm clock to wake you up? Do you check the news, stocks, email, weather, traffic in when you wake up? The last thing you look at in the evening? Did you know the mobile screen has overtaken television? 

We've got a lot of Mobile going on at OpenWorld 2015.  In particular, a few highlights from our Focus on Mobile page

You may notice that last one is with Benedict Evans from Andreessen Horowitz. (Andreessen as in Marc Andreessen, the Mozilla, Netscape, World Wide Web - yeah, that guy).  Benedict is a partner with Andreessen Horowitz covering mobile tech in particular. I've been following the A16Z podcasts and his ideas are pretty insightful. Check out Benedict's Mobile Eating the World presentation and his recent blog asserting that the smartphone is the new sun

Anywhoo - lot's interesting mobile sessions, labs and expert meetings going on.  Definitely checkout the Focus on Mobile and Mobile Central pages.  Oh, and stop by the Mobile Showcase at Moscone South to see mobile demos from Oracle and Partners.

Follow us @OracleMobile

Monday Aug 24, 2015

Using Oracle MAF Authentication To Access Secure Services From Oracle MCS

Oracle MAF 2.1.3 release makes it easy to authenticate against Oracle Mobile Cloud Service (MCS) and access secure data from services hosted on MCS.  Below are the steps to configure MAF application to authenticate against MCS:

1. Create Login Connection : In maf-application.xml go to security tab and create a login server connection. Select authentication type as "HTTP Basic" as shown below 

create login connection

create login connection

The login server URI is of the form https://<host>:<port>/mobile/platform/users/login . You can obtain the host & port from a Mobile Backend(MBE) settings page in you MCS instance. The above URI can be used for any MBE in the MCS instance.

2.  Configure Custom Header : During authentication MCS requires a custom header with the MBE id to be injected with the request. Configure the header in the Custom Headers tab  as follows:

configure custom header

You can get the MBE Id from the MBE settings page in MCS. The header name should be "Oracle-Mobile-Backend-Id"

3. Configure Security Policy : Now that we have the login connection created, the next step is to create a connection to API end point on MCS.  In the Web Service Security Policies section :

  1. Create a REST/HTTP Connection to an API end point in connections.xml, in the example below it's named "fiftechnician".  
  2. Associate the "fiftechnician" connection with the login connection created in steps 1 & 2. This allows the framework to inject the user identity obtained during authentication for any service calls to the connection.    
  3. In the "Policy" column, double click on the pencil icon to launch a dialog to select the security policy to be used for the connection. Select "oracle/wss_http_token_client_policy". This policy can be used for Basic-Auth protected connections with either HTTP and HTTPS. 
configure security policy

select the correct policy :

configure security policy

The above steps would allow mobile app developers using MAF to securely access data from API hosted on MCS through simple configuration without writing any code and be assured that you are following security best practices.

Wednesday Jul 01, 2015

From the Cloud Launch - Focusing on Mobile, the Other Side of the Proverbial Coin

No doubt you tuned into the big Oracle Cloud Platform as a Service (PaaS) launch last week. Lots of new and exciting cloud based offerings including:

  • Oracle Database Cloud - Exadata Service
  • Oracle Archive Storage Cloud Service
  • Oracle Big Data Cloud Service and Big Data SQL Cloud Service
  • Oracle Integration Cloud Service
  • Oracle Process Cloud Service

And last but certainly not least Oracle Mobile Cloud Service! The Cloud is touching every facet of IT infrastructure - and the other side of the coin, that's Mobile, which is changing the interfaces to all those systems.  Mobile is the new first screen, overtaking television and growing. The web browser reached hundreds of millions of people, but yet somehow, Mobile has taken it 10X, a magnitude greater than before, reaching billions of people. It's predicted that by 2020, 80% of the world, will have a smartphone.

Get a quick intro into Oracle Mobile Cloud Service in the following easy on the eyes, mind sharpening assets:

  1. Watch the overview video here (< 3min), it's the main video on the page
  2. Watch the subsequent videos (< 1 min each) in the Learn More tab
  3. Read the eBook, the big eBook button on the page ;-)

Then get down to business in strengthening your mobile strategy by simplifying mobility.

Follow @OracleMobile 

Thursday Feb 12, 2015

Introduction to custom Cordova plugin development

Oracle Mobile Application Framework (MAF) v2.1.0 uses Cordova version 3.6.3 on Android and 3.7.0 on iOS to provide access to native device functionality.  The MAF 2.1.0 extension to JDeveloper 12.1.3 enables you to easily include any of the hundreds of published 3rd party Cordova plugins into your MAF app.

But what if you can’t find a suitable 3rd party plugin? You could elect to write your own, which, depending on the functionality required, may not be as difficult as you think.

In this post I’ll provide an introduction to developing a Cordova plugin by creating a very simple plugin for each of Android and iOS.

How does a Cordova plugin work?

In a nutshell, Cordova provides a bridge between JavaScript and native code, enabling you to write native code that gets exposed to your app via a common JavaScript interface.

Each method exposed by a plugin’s JavaScript interface is mapped to a method in the plugin’s native code via the Cordova bridge, which also enables you to pass parameters back and forth between the JavaScript and native methods.

What comprises a Cordova plugin?

A Cordova plugin typically consists of:

  • Native code for each supported platform
  • A common JavaScript interface
  • A manifest file called plugin.xml

The conventional structure for a Cordova plugin supporting both Android and iOS is:

  - Plugin top-level folder
     - plugin.xml
     - src/
        - android/
           - <Java source code>
        - ios/
           - <Objective-C source code>
     - www/
        - <JavaScript interface>

Ideally, community-published plugins also include release notes, author and license information, and a README file.  

A plugin may also include additional native resources and these are identified in the plugin.xml manifest file. This manifest file is read by the plugman command-line tool, which is used by the Cordova command-line interface and also by the MAF extension for JDeveloper.

In some rare cases, a plugin may be created that simply executes some native code on initialization and requires no JavaScript interface.

For more detailed information about the plugin.xml manifest file, refer to the Cordova Plugin Specification.

How do I create my own custom Cordova plugin?

To create your own custom Cordova plugin, you must write:

  • JavaScript that provides the interface for calling your plugin from within a Cordova-based app, such as a MAF app.
  • Native code that provides the functionality you need.  Since MAF supports both Android and iOS, you should write native code for both platforms.
  • A plugin.xml manifest file that defines your plugin and how plugman should incorporate it into a MAF app (or any Cordova-based app).

What tools do I need to create my own custom Cordova plugin?

You really only need a text editor to create your own custom Cordova plugin, which is all I’ve used to create the custom plugin described in this post.

For more complex plugins, you may wish to develop and test the plugin’s native code in each platform’s native IDE, which means downloading and installing the Android Studio and/or Apple’s Xcode.

You don’t need Cordova installed to develop a Cordova plugin.  Once you have developed your Cordova plugin, you can incorporate it directly into your MAF app for testing. However, if you wish to test your plugin within a Cordova app, you must download and install Cordova using the Cordova Command-Line Interface.

How do I write the plugin’s JavaScript interface?

We start with the JavaScript interface since it provides a common interface to both the Android and iOS native code.  This interface effectively defines what is required in the native code.

The JavaScript interface must call the cordova.exec method to invoke a native plugin method, as follows: 

cordova.exec(successCallback, failureCallback, service, action, [args]);

This call invokes the action method on the service class on the native side, passing the arguments in the optional args array.  If the native code completes successfully, the successCallback function is executed, along with any return parameters.  If the native code fails, the failureCallback function is executed, with an optional error parameter.  For more information on JavaScript callback functions, refer to this helpful blog post by Michael Vollmer.

Let’s create a very simple plugin that displays a native popup dialog.  Thus plugin shall present one method that takes 3 parameters – title, message and button label – and shall return the result in the ‘success’ callback. No ‘failure’ callback will be implemented. The service class shall be named “Alert” and we shall call the sole method “alert”. 

The following JavaScript defines the interface:

module.exports = {
  alert: function(title, message, buttonLabel, successCallback) {
                 null, // No failure callback
                 [title, message, buttonLabel]);

The call to module.exports exports the JavaScript function alert as part of the JavaScript module that will be defined in the plugin manifest file, plugin.xml

Your app will call this alert JavaScript function, which will invoke the alert method on the Alert class in the plugin’s native code.

Save this JavaScript into a file called alert.js, within a www subfolder of your plugin’s top-level folder.

How do I write the plugin’s native code?


Based on the JavaScript interface, we must define a class called Alert in a Java source file called Alert.java.  Let’s take a look at the Alert.java source file:

package com.acme.plugin.alert;

import android.app.AlertDialog;
import android.app.AlertDialog.Builder;
import android.content.DialogInterface;
import org.apache.cordova.CallbackContext;
import org.apache.cordova.CordovaInterface;
import org.apache.cordova.CordovaPlugin;
import org.apache.cordova.CordovaWebView;
import org.apache.cordova.PluginResult;
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;

public class Alert extends CordovaPlugin {
  protected void pluginInitialize() {

  public boolean execute(String action, JSONArray args, CallbackContext callbackContext)
      throws JSONException {
    if (action.equals("alert")) {
0), args.getString(1), args.getString(2), callbackContext);
      return true;
    return false;

  private synchronized void alert(final String title,
                                  final String message,
                                  final String buttonLabel,
                                  final CallbackContext callbackContext) {
    new AlertDialog.Builder(cordova.getActivity())
new AlertDialog.OnClickListener() {
      public void onClick(DialogInterface dialogInterface, int which) {
new PluginResult(PluginResult.Status.OK, 0));

The Alert class should be part of a package that will be referenced in the manifest file, plugin.xml.

The Alert class must extend the CordovaPlugin class, the definition of which you can find here.

The Alert class must override the execute method, since this will be called each time the JavaScript cordova.exec method is called, providing the name of the plugin method, the input parameters and a callback context.  The execute method should return true if a valid action was passed in, otherwise false.

Once the code has completed, it should return a result and optional return parameters to the calling JavaScript by invoking the sendPluginResult method on the callbackContext object.   Returning a result of PluginResult.Status.OK will cause the JavaScript ‘success’ callback to be executed.  Any other result (apart from PluginResult.Status.NO_RESULT) will cause the JavaScript ‘failure’ callback to be executed.

In our plugin, a ‘success’ result is returned when the user taps the button on the popup dialog and a value of 0 is returned.

The Alert class may override the pluginInitialize method if any initialization logic is required when the plugin is first constructed.

Save this code into a file called Alert.java, within a src/android subfolder of your plugin’s top-level folder.

For more detailed information on aspects such a threading and event handling, refer to the Cordova page Android Plugins.


For our example, we must define a class called Alert in an Objective-C source file called Alert.m and corresponding header file Alert.h

Let’s take a look at the Alert.h header file:

#import <Cordova/CDV.h>

@interface Alert : CDVPlugin <UIAlertViewDelegate> {}
- (void)alert:(CDVInvokedUrlCommand*)command;

MyAlertView : UIAlertView {}
@property (nonatomic, copy) NSString* callbackId;

The Alert class must be a sub-class of CDVPlugin, the definition of which you can find here.

The Alert class must provide an alert method, since this will be called each time the plugin’s JavaScript alert method executes the cordova.exec method.

Save this code into a file called Alert.h, within a src/ios subfolder of your plugin’s top-level folder.

Let’s take a look at the Alert.m source file:

#import "Alert.h"

@implementation Alert
- (void)pluginInitialize

- (void)alert:(CDVInvokedUrlCommand*)command
  NSString* callbackId = command.callbackId;
  NSString* title = [command argumentAtIndex:
  NSString* message = [command argumentAtIndex:
  NSString* button = [command argumentAtIndex:

  MyAlertView *alert = [[MyAlertView alloc]
                        alert.callbackId = callbackId;
  [alert show];

- (void)alertView:(UIAlertView*)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
  MyAlertView* myAlertView = (MyAlertView*)alertView;
  CDVPluginResult* result = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK
self.commandDelegate sendPluginResult:result callbackId:myAlertView.callbackId];

@synthesize callbackId;

The alert method receives the input parameters and a callback id.

Once the code has completed, it should return a result and optional return parameters to the calling JavaScript by invoking the sendPluginResult method on the commandDelegate object. Returning a result of CDVCommandStatus_OK will cause the JavaScript ‘success’ callback to be executed. Any other result will cause the JavaScript ‘failure’ callback to be executed.

In our plugin, a ‘success’ result is returned when the user taps the button on the popup dialog and a value of 0 is returned.

The Alert class may implement the pluginInitialize method if any initialization logic is required when the plugin is first constructed.

Save this code into a file called Alert.m, within a src/ios subfolder of your plugin’s top-level folder.

For more detailed information on aspects such a threading and event handling, refer to the Cordova page iOS Plugins.

How do I write the plugin’s manifest file (plugin.xml)?

The manifest file, called plugin.xml, is an XML document that defines the plugin and tells plugman how to incorporate the plugin into your MAF app (or any Cordova-based app) for each platform it supports.

The Cordova Plugin Specification is comprehensive, but we will focus on the manifest file used for our “Alert” plugin:

<?xml version="1.0" encoding="UTF-8"?>

A Cordova plugin that displays an alert popup dialog</description>

name="cordova" version=">=3.6.0" />

src="www/alert.js" name="Alert">
target="Alert" />

  <!-- android -->
  <platform name="android">
      <feature name="Alert">
        <param name="android-package" value="com.acme.plugin.alert.Alert" />
    <source-file src="src/android/Alert.java" target-dir="src/com/acme/plugin/alert" />

  <!-- ios -->
  <platform name="ios">
    <config-file target="config.xml" parent="/*">
      <feature name="Alert">
        <param name="ios-package" value="Alert" />
    <header-file src="src/ios/Alert.h" />
    <source-file src="src/ios/Alert.m" />


The plugin element must contain the plugin’s XML namespace (xmlns), id and version.

The name and description elements should always be defined.  If you intend to publish your plugin for public use, you should include additional elements such as those identifying the author, license, keywords and repository.

The child elements of the engines element define which version(s) of the Cordova framework the plugin supports.  Since this plugin has been developed based on Cordova 3.6.0 documentation and will be tested within a MAF 2.1.0 app, we should set the minimum required Cordova version to 3.6.0.

The JavaScript interface is defined by including a js-module tag for each JavaScript file.  Any file defined here is automatically copied into your MAF app and injected into any HTML using a <script> tag so that you don’t have to specifically add this tag yourself, or include the JavaScript as content in your AMX features.  The clobbers tag indicates that the module shall be inserted into the window object as Alert, so your MAF app code should call the JavaScript method Alert.alert to execute the plugin’s alert method.

If your plugin has a dependency on another Cordova plugin, you can define this using a dependency tag.  Since our plugin does not have any dependencies, there is no such tag defined.

The platform tag is used to define the platforms that are supported by the plugin.  Within each platform tag, you specify the native source files, changes required to configuration files, any additional native resources or frameworks and any platform-specific JavaScript files.

For Android, it is important to specify the full package name of the plugin as the value for the android-package parameter, for example “com.acme.plugin.alert.Alert”, and to specify the target-dir for any source files (since this indicates the location to which the source file should be copied and it must match the package name), for example “src/com/acme/plugin/alert”.

Save this XML into a file called plugin.xml, within your plugin’s top-level folder.


We have now developed a custom Cordova plugin that can be incorporated into a MAF 2.1.0 app, or any app based on Cordova 3.6.0 or above.  In a follow-up post [Edit: here], I’ll describe how to integrate this plugin into a MAF app.

For developers looking for more detailed information about how to create a Cordova plugin, refer to the Cordova Plugin Development Guide, which contains specific guides for each native platform.


This blog is is dedicated to announcements,tips and tricks and other items related to developing, integrating, securing, and managing mobile applications using Oracle's Mobile Platform. It is created and maintained by the Oracle Mobile product development team.

Archive of past entries

Even More Mobile Development Blogs

Oracle A-Team Site - Mobile Related Entries

Code samples from the Community

Fusion Middleware Blogs


« December 2015