This chapter includes the following sections:
By configuring the content type for an application feature as Remote URL in the overview editor for the maf-feature.xml
file, as shown in Figure 20-1 , you create a browser-based application that is served from the specified URL. Such server-hosted applications differ from client applications written in MAF AMX, local HTML, or a platform-specific language such as Objective-C in that they are intended for occasional use and cannot directly access the device's memory or services (such as the camera, contacts, or GPS). These interactions are instead contingent upon the capabilities of the device's browser. For details about configuring Remote URL content, see Defining the Application Feature Content as Remote URL or Local HTML.
Figure 20-1 Configuring Remote URL Content
To ensure security for remotely served content, MAF supports the concept of whitelists, a registry of URLs that opens within the application web view to access various device services, such as GPS, a camera, or a file system. If a web page is not included on a whitelist (that is, it is not whitelisted), then MAF's Apache Cordova implementation opens a web page in the device browser (such as Safari) instead. Without whitelisting, a remote web page cannot open within the MAF web view, thereby limiting its access to the embedded device capabilities. As illustrated in Figure 20-2 , a URL that opens within the MAF web view is presented as an application feature.
Figure 20-2 URLs in the Device Browser and MAF Web View
Remote URL applications that open within the MAF web view use Apache Cordova JavaScript APIs to access device features and MAF JavaScript APIs to access the MAF container services. You use a JavaScript <script>
tag that references the base.js
libraries to enable this access.
To access MAF or Cordova JavaScript APIs from within a server-rendered web application (for example, getting and setting EL expressions, getting information about the application, taking a photo, or accessing contacts), you must use the virtual path /~maf.device~/
when including base.js
so that the browser will identify the request as being for a MAF resource and not for the remote server. This approach works in both remote as well as local HTML pages and is the best way to include base.js
in an HTML feature (regardless of where it is being served from).The following example shows how to include base.js
from a device HTML page or from a remote HTML page:
<html> <head> <script src="/~maf.device~/www/js/base.js"></script> ...
When the container code reads /~maf.device~/
in the requested URL it then resolves the URL locally, as shown in the following example, and treats it as a native request.
<script src="http://your.domain.ip/~maf.device~/www/js/base.js"></script>
where your.domain.ip
is the domain from the remote URL. To make sure that the remote application feature and the request succeeds, add the domain URL to your MAF application’s whitelist, as described in How to Create a Whitelist (or Restrict a Domain).
MAF then reads the file from the file system in the container code and sends the local file content to the web view.
In addition to using the virtual path /~maf.device~/
, as already described, verify that the Allow Native Access property (allowNativeAccess
) is set to the default value of true
in the maf-application.xml
file for the application feature that specifies the remote URL application as its content type. The following example shows this property in a maf-application.xml
source file:
<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="true"/>
If this property is false
, the remote URL application feature cannot access the container services.
By default, the domains defined in the connections.xml
file (the repository for all of the connections defined in the mobile application) are whitelisted automatically. These domains for remote URL content are created using the Create URL Connection dialog, shown in Figure 20-3 . MAF parses the domain from each of the connection strings and adds these domains to the whitelist.
Figure 20-3 Creating the Connection to Retrieve the Content of the Remote URL Application Feature
JDeveloper then populates the connections.xml
file, located in the Application Resources panel, with the connections information and also creates the connection resources.
In addition to the domains that MAF includes from the connections.xml
file, you can enable (or restrict) remote URL content to open with the MAF web view by configuring whitelisted domains in the maf-application.xml
file.
You configure the whitelist in the Security page of maf-application.xml
, as shown in Figure 20-4 .
Figure 20-4 Configuring a Whitelist
Before you begin:
Be aware that some URLs configured in the mobile application may open to other domains.
To create whitelists:
When you add a domain, JDeveloper updates the <adfmf:remoteURLWhiteList>
element as illustrated in the following example.
... <adfmf:remoteURLWhiteList> <adfmf:domain id="domain_1">*.oracle.com</adfmf:domain> <adfmf:domain id="domain_2">http://*.example.com</adfmf:domain> </adfmf:remoteURLWhiteList> ...
Some URLs are redirected to a URL that may not be part of the whitelist domain. These URLs may open in the device browser rather than the application web view. For example, if you whitelist www.oracle.com
(<adfmf:domain>www.oracle.com<adfmf:domain>
), MAF opens the mobile version of this site (www.m.oracle.com
) in the device browser, because it does not pass the whitelist. Figure 20-5 shows a web page that has not been whitelisted and has opened within the device browser.
Figure 20-5 A Web Page Opening in the Device Browser, Not the MAF Web View
To enable www.oracle.com
to open within the application web view, you must specify *.oracle.com
or www.oracle.com
as shown in What Happens When You Add Domains to a Whitelist.
Because the MAF whitelist is at the domain-level, you cannot restrict an individual page within a whitelisted domain from opening with an application feature web view; all pages are allowed.
Use a whitelist for pages that contain links to URLs that point to another domain. Such pages would otherwise open in the device browser instead of the MAF web view. In such a case, you can create an anchor tag or an <amx:goLink>
component with a url
attribute for the <amx:goLink>
component that points outside of the application, such as the url
attribute in <goLink2>
in the following example.
<?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:panelGroupLayout id="panelGroupLayout1"> <amx:goLink text="This opens in the device browser" id="golink1" url="http://www.example.com" shortDesc="Opens in device browser"/> <amx:goLink text="This opens in the web view" id="golink2" url="http://www.example2.com" shortDesc="Accesses device services"/> </amx:panelGroupLayout> </amx:panelPage> </amx:view>
See also Creating and Using UI Components.
MAF enables you to add a navigation bar with buttons for back, forward, and refresh actions for application features implemented as remotely served web content that open within the MAF web view, as shown in Figure 20-6 . The forward and back buttons are disabled when either navigation forward or back is not possible.
Note:
The back button is disabled on Android-powered devices.
Figure 20-6 A Remote Web Page Displaying the Navigation and Refresh Buttons
You enable users to navigate through, or refresh remote content through the Content tab of the overview editor for the maf-feature.xml
file.
Before you begin:
Designate an application feature's content be delivered from a remotely hosted application by first selecting Remote URL and then by creating the connection to the host server, as described in Defining the Application Feature Content as Remote URL or Local HTML.
Ensure that the domain is whitelisted.
To enable a navigation bar:
JDeveloper updates the adfmf:remoteURL
element with an attribute called showNavButtons
, which is set to true
, as shown in the following example.
<?xml version="1.0" encoding="UTF-8" ?> <adfmf:features xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adfmf="http://xmlns.oracle.com/adf/mf"> <adfmf:feature id="oraclemobile" name="oraclemobile"> <adfmf:content id="oraclemobile.1"> <adfmf:remoteURL connection="connection1" showNavButtons="true"/> </adfmf:content> </adfmf:feature> </adfmf:features>
After you deploy the application, MAF applies the forward, back, and refresh buttons to the web pages that are traversed from the home page of the Remote URL application feature, as shown in Figure 20-8 .
Figure 20-8 Traversing Through a Remote URL Application Feature
A custom URL scheme can be used to invoke a native application from other applications.
To invoke a MAF mobile application from another application, perform the following steps:
A MAF application can invoke another native application in the following ways:
Using an amx:goLink
on a MAF AMX page whose URL begins with the custom URL scheme registered by the native application. For example:
<amx:goLink text="Open App" id="gl1" url="mycustomurlscheme://somedata"/>
Using an HTML link element on an HTML page whose href
attribute value begins with the custom URL scheme registered by the native application. For example:
<a href="mycustomurlscheme://somedata">Open App</a>
Add any custom URL schemes that your MAF application uses to invoke a native application to the Allowed Scheme list in the Security page of the maf-application.xml
file’s overview editor. This change addresses iOS 9’s requirement that applications declare any URL schemes they use to invoke other applications. Click the Add icon in the Allow Schemes section of the Security page to add the custom URL scheme, as shown in Figure 20-9 .
Figure 20-9 Registering a Custom URL Scheme that a MAF Applications Use to Invoke Another Application