Tuesday Dec 22, 2015

Android 9-patch splash screen images

A very handy, but little advertised feature introduced in MAF 2.2.0 is the ability to use 9-patch splash screen images for Android.

By using 9-patch splash screen images, you are able to define how your splash screen images will stretch to fit all Android device screens.

You define which area(s) of the image can be stretched, whilst ensuring that other areas such as those containing a logo or text will remain a constant size.

What is a 9-patch image?

A 9-patch image is a standard PNG image that includes an extra 1-pixel wide border and is saved with a .9.png extension.

The border is used to indicate which area(s) of the image can be stretched and optionally which area(s) of the image are fillable (i.e. can be overlaid with text when the image is used as a background image for an Android View object, such as a Button).

To start with, all border pixels must be completely transparent. You then indicate the stretchable and fillable areas by adding black pixels to the corresponding border areas.

For the purpose of a splash screen image, you only need to define the stretchable areas of the image. The top and left borders are used for this purpose. A black pixel in the top border row indicates that the image pixels in that column may be stretched horizontally. A black pixel in the left border column indicates that the image pixels in that row may be stretched vertically.

The following example 9-patch image has a blue background, white log and red box.  I've doubled its size here so you can more easily see the black pixels in the top and left borders.

The black pixels in the top and left borders ensure that only the blue background portion of the image will be stretched when the available display area is larger than the image size.  The center logo and the outer red box will remain static.

For more information, the official Android documentation on 9-patch can be found here and a really good tutorial can be found here.

Creating a 9-patch splash screen image

The best place to start is with your existing set of PNG splash screen images.

Since 9-patch images can only stretch, not shrink, ensure that you start with an image size equal to or smaller than the size of the smallest area in which you expect your app to be launched (remember that some Android versions support launching apps into a window that does not fill device’s entire screen).

For best results with images that contain logos and text, create a separate 9-patch image for each screen density. You may find that a single 9-patch image works in both portrait and landscape mode for the specified density, which will reduce the number of splash screen images you need to create and maintain.

The Android SDK provides a WYSIWYG editor called draw9patch that enables you to create a 9-patch image from an existing PNG image. It is very easy to use and dynamically shows you how your image will stretch. More information on this tool can be found here.

If for some reason you would rather use your favorite image editor, remember the following 9-patch image constraints:

  • The border must be only 1-pixel wide and must surround the entire image, even if you don't wish to define the fillable area.  Thus a 100x100 pixel image becomes a 102x102 pixel 9-patch image.
  • The border must consist entirely of only fully transparent or solid black pixels.  A slight difference in color or alpha level will fail silently at runtime.
  • The image file must have a .9.png extension.  

Using 9-patch splash screen images in your MAF app

Having created 9-patch versions of your splash screen images for each Android screen density and orientation, copy them into your MAF project and reference them in your Android deployment profile.

Conclusion

By using 9-patch splash screen images, you are able to define how your splash screen images will stretch to fit all Android device screens or windows in which your app is launched.

Creating 9-patch splash screen images from your existing PNG splash screen images is simple using the draw9patch tool available in the Android SDK.

The above information is only relevant to Android, since iOS does not support 9-patch.

Wednesday Oct 14, 2015

Oracle MAF 2.2 New Features

V2.2 is the new release of Oracle Mobile Application Framework (Oracle MAF). This blog provides an overview of several new features added in this release.

 1. UI Components

This release introduces several new components and enhancements to help developers support latest mobile patterns

Swipe To Reveal :

Allows user to swipe on a row in a list to reveal contextual actions. This functionality can be added to an AMX page using <amx:accessoryLayout/> component.

Example usage:

Swipe To Reveal Sample


Pull To Refresh :

Allows developers to swipe down and refresh the contents of a page. This capability can be added to a page using <amx:refreshContainer/> component.  

Example usage:

Pull to refresh

New Layout Components 

Allow developers to easily build flexible Dashboard and Grid layouts.  

MasonaryLayout :  Typically used for building Dashboard style pages involving tiles laid out in the form of a grid. The size of each tile can be adjusted using css. It provides the following key capabilities

  1. Adjusts layout based on the available width
  2. Allows drag and drop of tiles in the layout 

Example usage:

Pull to refresh

FlexLayout: A layout component that displays its children in a group. It supports horizontal and vertical orientations, with automatic changes based on the device orientation. By default, the layout creates even space for each child, and stretches these children within its boundaries.

Example usage: 

Data Visualization Enhancements :

  • Stock Charts : Stock charts are useful for displaying stock data across time. A unique feature of stock charts is the ability to render series data as 'candlesticks' representing open, close, high, and low stock price data.
  • Chart Drill Events : Allows users to tap on series or group or data items to raise drill events to drill in to the chart data
  • Support for overview and vertical orientation for Timeline component

Alta Mobile V1.4 :  

New skin with support for Google Material design for Android L

2. Data binding Enhancements

Support For Nested DataControl Context:

  • Allows developers to build recursive navigation flows using Task Flows
  • Isolate state at the Taskflow level
  • Manage the number of Taskflow/DC instances maintained in the stack 
  • Example: Opportunity List -> Opportunity Detail -> Account Detail (from the account associated with the Opportunity) -> Related Opportunity List -> Opportunity Detail (with a different Opportunity than previous)

3. Navigation Enhancements

  •  Full support for Android back button
    • Support for overriding the default behaviour using <amx:systemActionBehavior> tag or JS API
    • “__back” navigation rule is used by default
  • Support for limiting pageFlowScope variables to TaskFlow boundaries

4. Performance Improvements

  •  30% overall performance improvement compared to previous release
  • Major Performance improvements in the following areas
    • JSON Parsing : New parser based on JSONP
    • New Optimized JVM : 30-40% performance improvement in Java processing
    • UI performance improvements to improve the page rendering time 

Summary  

Oracle MAF 2.2 has many exciting features and we encourage everyone to upgrade and give it a try. Several of the features listed above are used in the sample applications shipped with the release. Please refer to the samples for sample code. Component Gallery, Layout Demo and WorkBetter sample Apps cover most of the features listed above.

Monday Sep 07, 2015

Quick Tip: Multi Line Labels on Command Button

By default, command button labels in MAF AMX display as a single line. But what if you need to reduce the width of a command component while still going with a longer label on it? In this case Cascading Style Sheet (CSS) comes in handy. You can create a quick test case yourself and copy & paste the page code below

<amx:commandButton id="c1" text="one two three four five six seven eight nine ten eleven twelve thirteen"
     inlineStyle="word-break:break-word; white-space: normal; width:100px; 
                  height:150px; max-height:0%; max-width:100px;">
</amx:commandButton>

Note the inlineStyle property setting, which not only determines where and how to break the label string but also sets the max width and height for the component. If you like this CSS setting to be more central, you can add it to a MAF skin file so it is applied to all buttons, or just to buttons that reference a specific style class

Friday Sep 04, 2015

Quick Tip: Changing Button Icon in Response to Button Action

A question on the Oracle MAF forum on the Oracle Technology Network  was about how to change the icon displayed on a command button in response to a button action. The solution to this challenge is to think Java and managed bean. Below is a quick outline to the solution of this problem.

AMX page content

The AMX page content shows a command button with an icon attribute that points to a managed bean in view scope (no need for a larger scope).

  <amx:commandButton text="commandButton1" id="cb3" inlineStyle="height:150px; width:150px;"
                     icon="#{viewScope.sampleBean.imageName}"
                     actionListener="#{viewScope.sampleBean.onButtonPressed}"/>

Managed Bean

The managed bean that you configure either in the adfc-mobile-config.xml file or a task flow specific configuration file contains a property for setting the image ("imageName" in the example) along with its setter/getter methods and two final variables that hold the two image icon names and locations.

import oracle.adfmf.amx.event.ActionEvent;
import oracle.adfmf.java.beans.PropertyChangeListener;
import oracle.adfmf.java.beans.PropertyChangeSupport;

public class SampleBean {
            
  private static final String IMAGE1 = "/img/4.png";
  private static final String IMAGE2 = "/img/5.png";
   
  String imageName = IMAGE1;
    
  private PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);

  public SampleBean() {
      super();
  }

  public void setImageName(String imageName) {
     String oldImageName = this.imageName;
     this.imageName = imageName;
     propertyChangeSupport.firePropertyChange("imageName", oldImageName, imageName);
  }

  public String getImageName() {
     return imageName;
  }

  public void addPropertyChangeListener(PropertyChangeListener l) {
     propertyChangeSupport.addPropertyChangeListener(l);
  }

  public void removePropertyChangeListener(PropertyChangeListener l) {
     propertyChangeSupport.removePropertyChangeListener(l);
  }

  public void onButtonPressed(ActionEvent actionEvent) {
    if (imageName.equalsIgnoreCase(IMAGE1)){
      this.setImageName(IMAGE2);
    }
    else{
      this.setImageName(IMAGE1);
    }
  }
}

Important for this to work is that the property change support is added to the managed bean and the image name setter methods. This can be generated for you by Oracle JDeveloper and also in OEPE (Eclipse). With the property change event fired MAF will be notified about a data change and then refreshes the UI of the component the Java code is bound to.

The "onButtonPressed" method is invoked by the command button's action listener attribute and compares the current icon with the two images names in the bean to determine which one to set.



Friday Aug 28, 2015

MAF MCS Utility: Accessing Oracle MCS from MAF Made Simple

With the recent release of Oracle MAF 2.1.3 a new utility becomes available that simplifies access to Oracle Mobile Cloud Services (MCS) from Oracle MAF applications. Oracle MAF MCS Utility (MAF MCS Utility in short) is a Java library for Oracle MAF applications and exposes  MCS client platform REST API calls as native Java calls. This blog post introduces Oracle MAF MCS Utility, explains what it does, how it works and where to find it.

Oracle Mobile Cloud Service client API

Oracle MCS is all about REST! Any mobile client that is capable of sending REST requests and to handle JSON responses can invoke MCS mobile platform functionality exposed on a mobile backend (MBE). This includes calls to Analytics, Notification, Storage, User Information and Custom API.

About MCS client SDK

REST is a good choice for Oracle MCS and ensures an understandable and very easy to use application development interface.

From the perspective of mobile application developers however, accessing REST interfaces from mobile applications is a mental mismatch. To access REST APIs from a mobile application developers need to "think REST" though their comfort zone is within their favorite programming language, which for mobile usually means Objective-C, Java or scripting.

To address this lack of developer comfort and to improve developer productivity, Oracle MCS provides development language specific client SDKs. The MCS client SDK provides a native language abstraction to the underlying REST calls (for Android and Objective-C at current, as well as Xamarin), plus handy infrastructure functionality like offline synchronization and support for push notification registration and handling.

The image below shows the basic architecture pattern implemented by all Oracle MCS SDKs. All in all, using the MCS SDK makes developers more productive, requiring them to write less code.

MCS SDK Architecture

A MBE Manager object, a singleton, is configured with information required to access mobile backend(s) exposed on an Oracle Mobile Cloud Service instance. Mobile applications access the MBE Manager to obtain an instance of an MBE object representing a specific mobile backend in MCS.

The MBE object itself exposes Service Proxy objects that abstract the MCS platform API access. When using the service proxy objects to read and write to the remote mobile backend on the remote MCS instance, the MCS SDK takes care for all required request headers to be added (e.g. Oracle-Mobile-Backend-Id, Authorization, etc.), thus reducing the error surface for application developers. 

You can tell from the above description and image that the MCS client SDK is a simple but effective solution for mobile application developers to stay in their comfort zone.

About MAF MCS Utility

Oracle MAF is a Java based framework that uses Apache Cordova to deploy mobile applications to the Android and iOS platform (and Windows in a future release). MAF uses Java as a shared language across mobile platforms. The use of Java and the cross platform nature of MAF don't allow the use of one of the existing MCS client SDKs. This is where MAF MCS Utility comes in.

MAF MCS Utility provides functionality similar to those of the Oracle MCS client SDKs with some minor differences explained in the following with the help of the image below.

MAF MCS Utility Architecture

MAF MCS Utility needs to be added as a JAR file to MAF applications and is deployed to the mobile device as part of the application.  For this, MAF application developers add the mafmcsutility.jar file to the ApplicationController and/or ViewController project.

The MBE Manager, a singleton, manages MBE object instances that are created from a MBE configuration object. A copy of the MBE configuration object is stored and updated within the MBE instance. MAF application developers can access the MBE configuration object at runtime to e.g. dynamically enable or disable MBE specific logging or to enable or disable collecting analytic events. Service Proxy objects in MAF MCS Utility expose MCS platform REST API calls as typed native Java method calls.

To issue REST requests and handle JSON reponses, MAF MCS Utility wraps the MAF framework RestServiceAdapter class to benefits from MAF features like the security framework and the declarative REST connection framework.

MAF MCS Utility example

The code snippet below creates a MBE configuration object to then obtain a MBE instance from the MBE Manager to showcase how easy MCS integration becomes with MAF MCS Utility
MBEConfiguration mbeConfiguration = 
    new MBEConfiguration(
          <mbe rest connection>,<mobileBackendId>,
          <anonymous key string>,<application key string>, 
          MBEConfiguration.AuthenticationType.BASIC_AUTH);
mbeConfiguration.setEnableAnalytics(true);
mbeConfiguration.setLoggingEnabled(false)
mbeConfiguration.setMobileDeviceId(
         DeviceManagerFactory.getDeviceManager().getName());
MBE mobileBackend = MBEManager.getManager().
         createOrRenewMobileBackend(<mobile backend Id>, mbeConfiguration);

As you can see, the majority of the code lines above are to define the mobile backend specific information like the MCS MBE id, its base URL, as well as the anonymous key (for public access) and the application client key, which allows MAF MCS Utility to register a MAF application with MCS to receive push notifications from MCS. Once you have a handle to the MBE object you call service proxy objects for a specific MCS platform interface as shown below.

UserInfo userInfo = mobileBackend.getServiceProxyUserInfo();
Analytics analyticsProxy = mobileBackend.getServiceProxyAnalytics();
Storage storageProxy = mobileBackend.getServiceProxyStorage();
CustomAPI customApiProxy = mbe.getServiceProxyCustomApi();

Where to get MAF MCS Utility

MAF MCS Utility ships as part of the MAF 2.1.3 public samples. The sample contains the MAF MCS Utility source code, a compiled ready-to-use mafmcsutility.jar library file and a MAF application that demonstrate how to use MAF MCS Utility.

The MAF MCS Utility sample application (shown in the image below) is a generic Oracle MCS tester that can be configured to run against any MCS public cloud instance.

MAF MCS Utility public sample application

MAF MCS Utility Positioning

MAF MCS Utility provides MCS SDK functionality for Oracle MAF application developers to easily integrate calls to Oracle Mobile Cloud Services in their mobile applications. It improves developer productivity by shifting the "think REST" development style to "think Java" when accessing Oracle MCS platform APIs from MAF applications, which also means less code to write.

Because MAF MCS Utility implements the same architecture access pattern as the existing (and future) MCS SDK there is no extra learning curve to it. If you can do it in Android and iOS, you can do it in MAF as well (and vice versa).

MAF MCS Utility in the SDK Architecture

MAF MCS Utility Developer Guide

MAF MCS Utility is further explained in a developer guide, which also covers the MAF MCS Utility public sample application. For each service proxy, the developer guide points you to where in the public sample you find sample code to study and reuse.

http://download.oracle.com/otn_hosted_doc/maf/mafmcsutility-api-doc-082015.pdf

MAF MCS Utility Support

As other samples that are distributed with the Oracle MAF public samples, we do our best to provide end user support on the MCS forum on OTN and the MAF forum on OTN.

Thursday Feb 19, 2015

Integrating a custom Cordova plugin into a MAF app

In this earlier post, I demonstrated how to create a simple Cordova plugin for each of Android and iOS.  In this post, I’ll describe how to include that plugin into a MAF 2.1.0 app and how to invoke it from Java, from AMX and from local HTML.

You can follow these same instructions to integrate any 3rd party or custom Cordova plugin into your MAF app.

How do I include a custom Cordova plugin into my MAF app?

To include a custom Cordova plugin into a MAF app, you specify the location of the plugin’s top-level folder (on your local hard drive) in the app’s maf-application.xml > Plugins UI in JDeveloper, as described in the MAF 2.1.0 Documentation.

The path to the plugin will be stored in maf-plugins.xml and will be relative to that file’s location. To avoid any deploy-time issues, make sure the plugin’s top-level folder is on the same drive as your app and that there are no spaces in its path. If your plugin is specific to your MAF app, you probably want to include it within the app’s source tree.

The plugin will appear in the maf-application.xml > Plugins UI as follows:

Note: If you want to use a 3rd party plugin, you must first download it (as a zip file) and extract it to your local hard drive as described in Step 7 of this blog post.

How do I invoke the plugin’s methods?

As described in the earlier post, a Cordova plugin includes a JavaScript interface that defines its available functions. You must write your own JavaScript in your MAF application to call the plugin’s JavaScript interface so your MAF application can interact with the plugin.

In the example “Alert” plugin created in the earlier post, we defined the following JavaScript interface in the alert.js file:

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

Our plugin’s manifest file, plugin.xml, defined the JavaScript module as follows:

  <js-module src="www/alert.js" name="Alert">
    <clobbers
target="Alert" />
  </js-module>

This means that the alert function will be exported as part of the Alert JavaScript module within the consuming MAF application, which enables you to call this function from JavaScript as follows:

  Alert.alert(“My title”, “My message”, “My button label”, myCallbackFunction);

As per the plugin design, this code would cause a native popup dialog to be displayed with “My title” as the title, “My message” as the message and a single button with the label “My button label”. When the user taps the button to dismiss the dialog, the JavaScript callback function myCallbackFunction will be executed with an input parameter of 0.

For more information on using JavaScript callback functions, refer to this helpful blog post by Michael Vollmer.

Note: If you want to use a 3rd party plugin, the JavaScript interface and how to call it should be described in the plugin’s README.md file, typically found in the plugin’s top-level folder.

How do I invoke the plugin from a Local HTML page?

You could invoke the plugin’s JavaScript interface methods directly from your HTML code, but it’s more common to provide a wrapper function that simplifies your code and abstracts you from possible changes to the plugin’s interface.

Let’s take a look at a local HTML page that calls our “Alert” plugin:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport"

          content="width=device-width, initial-scale=1, maximum-scale=1"/>
    <title>Plugin Demo</title>
    <script type="text/javascript">if (!window.adf) window.adf = {};
                                   adf.wwwPath = 
"../../../../www/";</script>
    <script type="text/javascript" src="../../../../www/js/base.js"></script>
    <script type="text/javascript">
      function showAlert(frm) {
        Alert.alert(frm.title.value,
                    frm.message.value,
                    frm.buttonLabel.value,
                    function(button) {
                      console.log("User tapped button:" + button);
                    });
      }
    </script>
  </head>
  <body>
    <form>
      <br>Title: <input type="text" name="title" value="Title">
      <br>Message: <input type="text" name="message" value="Message">
      <br>Button Label: <input type="text" name="buttonLabel" value="Button">
      <br><input type="button" value="Alert" onclick="showAlert(this.form);">
    </form>
  </body>
</html>

The <meta> tag is included here to avoid the user seeing the components on the page increase or decrease in size as she interacts with it.

You must include the two lines of JavaScript that define the window.adf object and include base.js. There is no need to explicitly include the plugin’s JavaScript file here, since at deploy-time it will be injected into base.js.

A simple showAlert function has been defined to wrap the call to Alert.alert, which in turn simplifies the calling code within the HTML form.

The showAlert function is called when the user taps on the “Alert” button. The “title”, “message” and “button label” input text values are read from the form and passed to Alert.alert, along with an anonymous callback function that will be called when the user taps on the dialog’s button. This callback function will be passed a value for the input parameter button, which we know will be 0, since that was hard-coded in our plugin’s native code.

How do I invoke the plugin from an AMX page?

AMX components cannot call JavaScript methods directly, so you must implement a Java method that is called from an AMX component, which in turn executes some JavaScript that calls the plugin’s JavaScript interface.

Let’s take a look at an AMX page that is similar to the local HTML page described above:

<?xml version="1.0" encoding="UTF-8" ?>
<amx:view xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:amx="http://xmlns.oracle.com/adf/mf/amx"
          xmlns:dvtm="http://xmlns.oracle.com/adf/mf/amx/dvt">
  <amx:panelPage id="pp1">
    <amx:facet name="header">
      <amx:outputText value="Plugin Demo" id="ot1"/>
    </amx:facet>
    <amx:inputText label="Title" id="it1"
                   value="#{applicationScope.PluginBean.alertTitle}"/>
    <amx:inputText label="Message" id="it2"
                   value="#{applicationScope.PluginBean.alertMessage}"/>
    <amx:inputText label="Button Label" id="it3"
                   value="#{applicationScope.PluginBean.alertButtonLabel}"/>
    <amx:commandButton text="Alert" id="cb1"
                       actionListener="#{PluginBean.popupAlertDialog}"/>
  </amx:panelPage>
</amx:view>

The three inputText components store their values in three attributes of an bean called PluginBean. When the user taps the commandButton component, it calls the popupAlertDialog method of PluginBean.

Let’s take a look at the PluginBean:

package mobile;

import oracle.adfmf.amx.event.ActionEvent;
import oracle.adfmf.framework.api.AdfmfContainerUtilities;
import oracle.adfmf.framework.api.AdfmfJavaUtilities;

public class PluginBean {
  private String alertTitle"Title";
  private String alertMessage"Message";
  private String alertButtonLabel"Button";

  public PluginBean() {
  }

  public void popupAlertDialog(ActionEvent actionEvent) {
    AdfContainerUtilities.invokeContainerJavaScriptFunction(
      AdfmfJavaUtilities.getFeatureId(),
      "showAlert",
      new Object[] {
        alertTitle,
        alertMessage,
        alertButtonLabel
      });
  }

  public void setAlertTitle(String alertTitle) {
    this.alertTitle = alertTitle;
  }

  public String getAlertTitle() {
    return alertTitle;
  }

  public void setAlertMessage(String alertMessage) {
    this.alertMessage = alertMessage;
  }

  public String getAlertMessage() {
    return alertMessage;
  }

  public void setAlertButtonLabel(String alertButtonLabel) {
    this.alertButtonLabel = alertButtonLabel;
  }

  public String getAlertButtonLabel() {
    return alertButtonLabel;
  }
}

The popupAlertDialog method calls AdfmfContainerUtilities.invokeContainerJavaScriptFunction to invoke a JavaScript function called showAlert, passing the alertTitle, alertMessage and alertButtonLabel attributes as input parameters to the JavaScript function.

You may wonder why the plugin’s alert JavaScript method is not invoked directly and we call the showAlert function instead. The reason is that the plugin’s alert method requires a JavaScript function callback to be passed as an input parameter and there is no way to do this from Java. Passing a null value may have unwanted side effects, so that is not recommended.

For this reason, we need to write a JavaScript function that wraps the call to the plugin’s alert method. There are two options for this.

One option is to create a JavaScript file and include it into each feature that wishes to invoke the plugin via the app’s maf-feature.xml UI as follows:


The JavaScript file would look similar to the following:

showAlert = function(title, message, buttonLabel) {
  Alert.alert(title,
              message,
              buttonLabel,
              function(button) {
                console.log("User tapped button: " + button);
              });
};

This JavaScript file defines a global function variable called showAlert, which accepts 3 input parameters and calls the plugin’s alert method with those 3 parameters, along with an anonymous callback function that will be executed when the user taps on the dialog’s button. The native code will pass a return value of 0 to the anonymous callback function as the input parameter button.

The other option, if the plugin is to be invoked from a single AMX page, is to include the wrapper function as verbatim JavaScript within the AMX page, similar to the following:

<?xml version="1.0" encoding="UTF-8" ?>
<amx:view xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:amx="http://xmlns.oracle.com/adf/mf/amx"
          xmlns:dvtm="http://xmlns.oracle.com/adf/mf/amx/dvt">
  <amx:panelPage id="pp1">
    <amx:verbatim id="v1">
      <![CDATA[
        <script type="text/javascript">
          function showAlert(title, message, buttonLabel) {
            Alert.alert(title,
                        message,
                        buttonLabel,
                        function(button) {
                          console.log("User tapped button: " + button);
                        });
          }
        </script>
      ]]>
    </amx:verbatim>
    <amx:facet name="header">
      <amx:outputText value="Plugin Demo" id="ot1"/>
    </amx:facet>
    <amx:inputText label="Title" id="it1"
                   value="#{applicationScope.PluginBean.alertTitle}"/>
    <amx:inputText label="Message" id="it2"
                   value="#{applicationScope.PluginBean.alertMessage}"/>
    <amx:inputText label="Button Label" id="it3"
                   value="#{applicationScope.PluginBean.alertButtonLabel}"/>
    <amx:commandButton text="Alert" id="cb1"
                       actionListener="#{PluginBean.popupAlertDialog}"/>
  </amx:panelPage>
</amx:view>

In either case, there is no need to include the plugin’s JavaScript file in the calling feature(s), since at deploy-time it will be injected into base.js.

Conclusion

You now have the knowledge required to create your own custom Cordova plugin and integrate it into your MAF 2.1.0 app, invoking it from local HTML, an AMX page, or from Java code.

Once you’ve tested your code successfully, you might consider publishing the plugin to make it available to the greater Cordova community. This can be achieved by calling plugman as follows:

$ plugman publish path-to-plugin-top-level-folder

About

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

Search

Archives
« April 2016
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
8
9
10
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
       
Today