ADF Mobile – Enterprise Mobility, the Oracle way!

Mobile Enterprise Challenges

It’s a fact. The ubiquity of mobile devices has driven corporate environments towards 24/7 connectivity. The distinction between consumer and business services on mobile devices has become blurred. Employees bring their personal mobile devices to work and demand enterprise application support. This is the “consumerization” of corporate IT.


In response, many enterprises have pursued a browser-only mobile application strategy. This approach offers easier application development, management, deployment, and support across multiple platforms. When application requirements can be met with what browsers support, such a strategy can be very effective. Oracle recommends this approach through the Oracle ADF Faces Rich Client Components.
But what if the application requirements go beyond what browsers support? Despite advances in HTML5, mobile browsers don’t offer deep access to device services (phone, SMS, Camera, and so on) and offer less control over offline application support than installed applications.
Therein lays the dilemma. Enterprises recognize the benefits that installed applications offer. But creating and maintaining a new application for each mobile platform with a different languages and different tools is very costly. And while iOS and Google Android are the dominant mobile platforms today, should another mobile platform or two emerge, then the potential maintenance costs could go through the roof – the overall scope may become too great to address with finite engineering resources.

Oracle ADF Mobile

ADF Mobile is an HTML5 and Java based mobile platform architected from the ground up to enable enterprise developers to create new or extend existing Oracle applications to mobile devices.
Applications developed with ADF Mobile can be designed for phone and/or tablet form factors and can be packaged for either Apple iOS or Google Android – from a single code base, using industry-standard HTML5, CSS and Java technology. Such applications install on-device, render the user interface via local HTML5, and can access device services as well a local SQLite database through JDBC (Java Database Connectivity).
ADF Mobile development is accomplished through declarative development with XML, Java technology, CSS3, and SOAP/REST web services. This minimizes the learning curve, as enterprises tend to have such development skills readily available.

Features and Benefits

Increase Productivity through Visual and Declarative Development

The JDeveloper ADF Mobile Extension design time includes visual tools and pattern consistency with other Oracle development technologies. This consistency can make developers productive as they develop mobile user interfaces and work with data controls to access web services and other data sources.
ADF Mobile makes it easy to create a mobile application that includes an icon, a tab bar, and springboard for navigating between features in the application as well as application preferences. Each of these gets defined once in XML and each works when the application is deployed across multiple mobile platforms.
To build application screens, developers use JDeveloper’s visual editors that provide instant feedback on the look and feel of the application. The user interface is declaratively constructed in XML using a set of mobile-skinned components, which also support accessibility and localization. Developers use visual task flow editors to declaratively define screen navigation logic for the controller layer.

Develop once and Deploy to Apple iOS and Google Android

Once an ADF Mobile application is developed, developers simply create different platform-specific deployment profiles in order to deploy the same application to multiple devices, including those running Apple iOS or Google Android. Developers can deploy the application either directly to a connected mobile device or to a device-native package that can be provisioned through device management services or deployed to an application store such as the Apple App Store or Google Play.

Java Technology

An application developed with ADF Mobile contains a lightweight Java virtual machine (JVM). Think of this JVM as a library that gets used for business logic and data access – the JVM is not a container for the whole application and it does not render the user interface. Rather, the JVM simply passes data to an HTML5 view, which renders the user interface.
Developers can code the application business logic in Java and the compiled byte code can run on either the Apple iOS or Android platforms. The Java technology is optimized and has a minimal on-device footprint (around 10MB). Access to the SQLite database is available through Java Database Connectivity (JDBC) and supports for web service requests are available through SOAP or REST.

Flexible Runtime Architecture

ADF Mobile applications install and run locally on-device and support offline operation. To support a wide variety of mobile scenarios, ADF Mobile uses a flexible runtime architecture enabling developers to construct screens using the technology that best suits their needs:

  • Declarative: ADF Mobile XML packaged with the application renders HTML5. In this case JavaBeans, as well as SOAP/REST web services are invoked through a JVM providing integration with enterprise backend services to show data at runtime. This is the most common approach to developing mobile application screens with ADF Mobile.
  • Local HTML5/JavaScript: Developers have the option to construct screens with HTML5 and JavaScript directly from within an application built with ADF Mobile. This is more complex and potentially less portable than using declarative XML but it offers more flexibility for user interface options. Developers building such applications with ADF Mobile can access device services using JavaScript and can also leverage the JVM for web service requests and offline support including access to SQLite, etc.
  • Remote HTML5/JavaScript: Including pages from a website inside a mobile application is sometimes useful. For example, for a company directory application, it may not make sense to rebuild the whole user interface declaratively in a mobile application but calling out to a separate browser wouldn’t be a good user experience. In this case credentials may be passed to such pages (so the user doesn’t have to login again to the same authentication server) and when such pages are run inside an ADF Mobile based application they can be given access to device services (contacts, camera, and so on).

Mobile Optimized User Experience

An ADF Mobile based application can be developed such that it can work well on either a tablet or a phone. When the application starts the appropriate form factor will load. Tablet views are often fewer in number, but more complex, including patterns such as list-details and so one. Whereas phone views are often greater in number but generally simpler due to screen size constraints. Defining both sets of views within the same application promotes reuse for business logic, data access, web service integration and so on.

From the start, ADF Mobile components were designed for mobile devices. They include support for touch/gestures and they were “skinned” to look great on mobile form factors. The components also allow for additional customization through CSS3 – an industry standard. Where appropriate, native component integration is enabled – for entering date/time on iOS.

Device Services

ADF Mobile gives developers the ability to quickly and declaratively integrate with local device services, such as camera, phone, SMS and GPS, through a common binding layer. Instead of writing multiple lines of device-specific code, developers can simply drag-and-drop device service controls with the JDeveloper design time.

Offline Support

When developing with ADF Mobile, developers define user interface declaratively with XML and define the business logic using the Java language. The application is then packaged for deployment to either Apple iOS or Google Android platforms. ADF Mobile extension accomplishes this by invoking the iOS SDK or Android SDK.
When the application is installed on-device, all of its requisite parts are included with the application. At runtime, the XML is parsed and user interface gets rendered as HTML5 and the Java business logic code can fetch data through SOAP/REST web services and either send that to the components to display or persist to a SQLite database through Java Database Connectivity (JDBC).
While web services require a network connection, interaction with the on-device SQLite database does not. This means offline support can be implemented as part of the application using a consistent set of patterns. JDBC can be used to access the local SQLite database and when a network connection is re-established, web services may be used to perform whatever business operations are required.

Authentication and Security

ADF Mobile includes turnkey support for authentication and access control integration. The developer simply specifies the appropriate login server, for example, a server running Oracle Identity Management and/or WebLogic with Basic Authentication enabled. At runtime users are presented with Login screens and the appropriate tokens are accessible for web service calls. Developers can build single user interfaces that meet the needs of users with different privileges (e.g. show/hide components based on role or privilege).
Security is a priority for mobile application development given that mobile devices have higher risks of loss or theft. ADF Mobile enforces encryption in the following areas:

  • Communication Encryption: Encrypted using SSL/TLS (HTTPS)
  • On-device Encryption: Credentials can be kept in an encrypted key store and used to for validation when supporting offline authentication.
  • SQLite Encryption: The SQLite Encryption Extension is included with ADF Mobile. This means encrypting a SQLite database for an application built with ADF Mobile is simply a configuration option when the application is developed. No additional license for SQLite Encryption Extension is required for deploying the application into production.


2 Comments

Leave a Reply to john archer Cancel reply