1 Introduction to Oracle Mobile Application Framework

1.1 Introduction to Mobile Application Framework

Oracle Mobile Application Framework is a hybrid mobile architecture, one that uses HTML5 and CSS to render the user interface, Java for the application business logic, and Apache Cordova to access device features such as GPS activities and e-mail. Because MAF uses these cross-platform technologies, you can build the same application for both Android and iOS devices without having to use any platform-specific tools. After they are deployed to a device, MAF applications behave as applications created using such platform-specific tools as Objective C or the Android SDK. Further, MAF enables you to build the same application for smartphones or for tablets, thereby allowing you to reuse the business logic in the same application and target various types of devices, screen sizes, and capabilities.

The content of a MAF application is comprised of one or more embedded applications known as application features, which are represented as icons within the application's springboard or navigation bar, as shown in Figure 1-1.

Application features are essentially the building blocks of a mobile application. Each application feature that is integrated into a MAF application performs a specific set of tasks, and application features can be grouped together to complement each other's functionality. For example, you can pair an application feature that provides customer contacts together with one for product inventory. Because each application feature has its own class loader and web view (essentially a native UI component that behaves as a browser), features are independent of one another; a single MAF application can be assembled from application features created by several different development teams. Application features can also be reused in other MAF applications. The MAF application itself can be reused as the base for another application, allowing ISVs (independent software vendors) to create applications that can be configured by specific customers.

In addition to hybrid mobile applications that run locally on the device, you can implement application features as any of the following mobile application types, depending on the requirements of a mobile application and available resources:

• Mobile web applications—These applications are hosted on a server. Although the code can be portable between platforms, their access to device features and local storage can be limited, as these applications are governed by the device's browser.

• Native applications—These applications are authored in either Xcode or through the Android SDK and are therefore limited in terms of serving both platforms. Reuse of code is likewise limited.

1.2 About the Mobile Application Framework Runtime Architecture

As illustrated in Figure 1-2, Mobile Application Framework is a thin native container which is deployed to a device. It follows the model-view-controller (MVC) development approach, which separates the presentation from the model layer and the controller logic. The thin native container allows the MAF application to function as a native application on both platforms (iOS, Android). It also enables push notifications.

• Web View—Uses a mobile device's web engine to display and process web-based content. In a MAF application, the web view delivers the user interface by rendering the application markup as HTML 5. You can create the user interface for a mobile application feature by implementing any of the following content types. Application features implemented from various content types can coexist within the same mobile application and can also interact with one another.

  • MAF AMX Views—Like an application authored in the language specific to the device's platform, applications whose contents are implemented as MAF Application Mobile XML (AMX) views reside on the device and provide the most authentic device-native user experience. MAF provides a set of code editors that enable you to declaratively create a user interface from components that are tailored to the form factors of mobile devices. You can use these components to create the page layout, such as such as List View, as well as input components, such as such as Input Text. When you develop MAF AMX views, you can leverage data controls. These components enable you to declaratively create data-bound user interface components, access a web service, and the services of a mobile device (such as camera, GPS, or e-mail). At runtime, the JavaScript engine in the web view renders MAF AMX view definitions into HTML5 and JavaScript. For more information, see Part IV, "Creating the MAF AMX Application Feature."

    Task Flow—The Controller governs the flow between pages in the mobile application, enabling you to break your application's flow into smaller, reusable task flows and include non-visual components, such as method calls and decision points. For more information, see Section 5.2, "Creating Task Flows."

  • Server HTML— The user interface is delivered from server-generated web pages that can open within the application feature's web view. Within the context of Mobile Application Framework, this content type is referred to as remote URL. The resources for these browser-based applications do not reside on the device. Instead, the user interface, page flow logic, and business logic are delivered from a remote server. When one of these remotely hosted web applications is allowed to open within the web view, it can use the Cordova JavaScript APIs to access any designated device-native feature or service, such as the camera or GPS capabilities. When implementing an application using the remote URL content, you can leverage an existing browser-based application that has been optimized for mobile use, or use one that has been written specifically for a specific type of mobile device. For applications that can run within the browsers on either desktops or tablets, you can implement the remote URL content using applications created through Oracle ADF Faces rich client-based components. For applications specifically targeted to mobile phones, the remote URL content can be delivered from web pages created using ADF Mobile browser. Not only can applications authored with ADF Mobile browser render on a variety of smartphones, but they can gracefully degrade to the reduced capabilities available on feature phones through user interfaces constructed with Apache Trinidad JavaServer Faces (JSF) components and dynamically selected style sheets. For more information, see Chapter 13, "Implementing Application Feature Content Using Remote URLs."

    Note:

    Because the content is served remotely, the application is available only as long as the server connection remains active.

  • Local HTML—HTML pages that run on the device as a part of the MAF application. Local HTML files can access device-native features services through the Cordova and JavaScript APIs.

• Cordova—The Apache Cordova JavaScript APIs that integrate the device's native features and services into a mobile application. Although you can access these APIs programmatically from Java code (or using JavaScript when implementing a MAF mobile application as local HTML), you can add device integration declaratively when you create MAF AMX pages because MAF packages these APIs as data controls.

• Java Virtual Machine—Provides a Java runtime environment for a MAF application. This Java Virtual Machine (JVM) is implemented in device-native code, and is embedded (or compiled) into each instance of the MAF application as part of the native application binary. The JVM is based on the JavaME Connected Device Configuration (CDC) specification.

  • Business Logic—Business logic in MAF application may be written in Java. Managed Beans are Java classes that can be created to extend the capabilities of Mobile Application Framework, such as providing additional business logic for processing data returned from the server. Managed beans are executed by the embedded Java support, and conform to the JavaME CDC specifications. For more information, see Chapter 7, "Using Bindings and Creating Data Controls."

  • Model—Contains the binding layer that connects the business logic components with the user interface. In addition, the binding layer provides the execution logic to invoke REST or SOAP-based web services. For more information, see Section 1.3.1, "About Connected and Disconnected Applications."

  • JDBC— The JDBC API enables access to the data in the encrypted SQLite database through CRUD (Create, Read, Update and Delete) operations.

• Application Configuration refers to services that allow application configurations to be downloaded and refreshed, such as URL endpoints for a web service or a remote URL connection. Application configuration services download the configuration information from a WebDav-based server-side service. For more information, see Chapter 9, "Configuring End Points Used in MAF Applications."

• Credential Management, Single Sign-on (SSO), and Access Control—Mobile Application Framework handles user authentication and credential management through the Oracle Access Management Mobile and Social (OAMMS) IDM SDKs. MAF applications perform offline authentication, meaning that when users log in to the application while connected, MAF maintains the username and password locally on the device, allowing users to continue access to the application even if the connection to the authentication server becomes unavailable. MAF encrypts the locally stored user information as well as the data stored in the local SQLite database. After authenticating against the login server, a user can access all of the application features secured by that connection. MAF also supports the concept of access control by restricting access to application features (or specific functions of application features) by applying user roles and privileges. For remotely served web content, MAF uses whitelists to ensure that only the intended URIs can open within the application feature's web view (and access the device features). For more information, see Chapter 21, "Securing Mobile Applications."

• Push Handler—Enables the MAF application to receive events from the iOS or Android notification servers. The Java layer handles the notification processing.

Resources that interact with the native container include:

• Encrypted SQLite Database—The embedded SQLite database is a lightweight, cross-platform relational database that protects locally stored data and is called using JDBC. Because this database is encrypted, it secures data if the device is lost or stolen. Only users who enter the correct user name and password can access the data in the local database. For more information, see Chapter 10, "Using the Local Database."

• Device Services—The services and features that are native to the device and integrated into application features through the Cordova APIs.

The device native container enables access to the following server-side resources:

• Configuration Server —A WebDav-based server that hosts configuration files used by the application configuration services. The configuration server is delivered as a reference implementation. Any common WebDav services hosted on a J2EE server can be used for this purpose. For more information, see Chapter 9, "Configuring End Points Used in MAF Applications."

• Server-Generated HTML—Web content hosted on remote servers used for browser-based application features. For more information, see Chapter 13, "Implementing Application Feature Content Using Remote URLs."

• APNs and GCM Push Services—Apple Push Notification Service (APNs) and Google Cloud Messaging (GCM) are the notification providers that send notification events to MAF applications.

• SOAP and REST Services—Remotely hosted SOAP- or REST-based web services, which can be accessed through the Java layer or through data controls.

  Note:

  Application features authored in MAF AMX can access REST-XML and SOAP-based data services through data controls. If using the REST service adapter, then data controls are unnecessary.

1.3 About Developing Applications with Oracle Mobile Application Framework

Although the components of a mobile application may be created by a single developer, an application may typically be built from resources provided by different development roles. An application developer builds the application data and the user interface logic either as an application or as a reusable program that can be used in an application feature. An application assembler gathers different application features into a single application and puts them in a user-friendly, navigable order. An application deployer ensures a controlled application deployment. For example, deployment of MAF applications may require certificates and uploads to public vendor sites such as the Apple App Store or GooglePlay.

Typically, you perform the following activities when building a MAF application:

• Gathering requirements

• Designing

• Developing

• Deploying

• Testing and debugging

• Securing

• Enabling access to the server-side data

• Redeploying

• Retesting and debugging

• Publishing

The steps you take to build a MAF application may be similar to the following:

1. Gathering requirements: Create a mobile use case (or user scenario) by gathering user data that describes who the users are, their essential tasks, and the location or context in which they perform them. Consider such factors as the type of information required to complete a task, the information that is available to the user, and how it is accessed or delivered.

2. Designing: After you construct a use case, create a wireframe that illustrates all of the steps (and associated user views) in the application's task flow. When creating a task flow, consider how, and when, different users may interact. Does viewing data (such as a push notification) suffice to complete a task? If not, how much data entry does the task require? To frame these tasks within a mobile context, compare completing tasks using a desktop application to a mobile application. A single desktop application may enable multiple functions that might be partitioned into several different mobile applications (or in the context of MAF, several different application features embedded in a mobile application). Because mobile applications are generally used in short bursts (about two minutes at a time), they must be easily navigable and accommodate the limited data entry of a mobile device.

   During the design and development phases, keep in mind that mobile applications may require a set of mobile-specific server-side resources, because the applications may not be able to consume large amounts of data delivered through complex web services. In addition, a mobile application may require extensive client side logic to process data returned by services. It's usually best to shape the data coming into a mobile application on the server side to avoid forcing the client to process too much data.

3. Developing: Select the technology that is best suited for application. While the MAF web view supports remote content which may be authored using Apache Trinidad (ADF Mobile browser) or ADF Faces Rich Client components, these applications do not support offline use. Applications authored in MAF AMX, which runs on the client, however, integrate with device services, enabling end users to not only view files and utilize GPS services, but also collaborate with one another by tapping a phone number to call or text. The MAF AMX component set includes data visualization tools (DVTs) that enable you to add analytics that render appropriately on mobile screens. A MAF AMX application supports offline use by transferring data from remote source and storing it locally, enabling end users to view information when they are not connected.

   MAF provides a set of wizards and editors that build not only the basic application itself, but also the application features that are implemented from MAF AMX and local HTML content. Using these tools provides such artifacts as descriptor files for configuring the mobile application and incorporating its application features, a set of default images for splash screens, springboards, navigation bar items that are appropriate to the form-factors of the supported platforms.

   For more information, see the following:

   • Chapter 3, "Getting Started with Mobile Application Development"

   • Chapter 4, "Defining a Mobile Application"

   • Part IV, "Creating the MAF AMX Application Feature"

4. Deploying: You deploy the MAF application not only in the context of publishing it to end users, but also for testing and debugging, because MAF applications cannot run until they have been deployed to a device or simulator. Depending on the phase of development, you designate the credential signing options (debug or release). For testing, you deploy the application to a mobile device or simulator. For production, you package it for distribution to application markets such as the Apple App Store or Google Play.

   To deploy an application you first create a deployment profile that describes the target platform and its devices and simulators. Creating a deployment profile includes selecting the splash screen and launch icons used for the application in different orientations (landscape or portrait) and on different devices (phone or tablets). For more information, see Chapter 19, "Deploying Mobile Applications."

5. Testing and debugging: During the testing and debugging stage, you optimize the application by deploying it in debug mode to various simulators and devices and then review the debugging output provided through JDeveloper and platform-specific tools. For more information, see Chapter 22, "Testing and Debugging MAF Applications."

6. Securing: Evaluate security risks throughout the application development process. While mobile applications have unique security concerns, they share the same vulnerabilities as any application that accesses remotely served data. To ensure client-side security, MAF provides such features as:

   • Whitelists that prevent such injection attacks as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

   • APIs that generate a strong password to secure access to the SQLite database and encrypt and decrypt its data.

   • A set of web service policies that support SSL.

   • A cacerts file of trusted Certificate Authorities to enforce deployment in SSL

   MAF's security configuration includes selecting a login server, such as the Oracle Access Mobile and Social server, or any web page protected by the basic HTTP authentication mechanism, configuring the session management (session and idle timeouts) and also setting the endpoint to the access control service web service, which hosts the application's user roles. For more information, see Chapter 21, "Securing Mobile Applications."

7. Enabling access to the server-side data: After ensuring that your application functions as expected at a basic level, you can implement the Java code or use data controls to access the server-side data. For more information, see Section 1.3.1, "About Connected and Disconnected Applications."

8. Redeploying: During subsequent rounds of deployment, ensure that after adding security to your application and enabling access to the server-side data, the application deployment runs as expected and the application is ready for the final testing and debugging.

9. Retesting and debugging: During the final round of testing and debugging, focus on the security and the server-side data access functionality, ensuring that their integration into the application did not result in errors and unexpected behavior.

10. Publishing: Deploying the application to the production environment typically involves publishing to an enterprise server, the Apple App Store, or Google Play. After you publish the MAF application, end users can download it to their mobile devices and access it by touching the designated icon (see Appendix D, "MAF Application Usage"). The application features bear the designated display icons and display as appropriate to the end user and the user's device.

1.4 Sample Applications

After setting up your development environment (see Chapter 2, "Setting Up the Development Environment"), you can examine the MAF sample applications located in the PublicSamples.zip file within the jdev_install/jdeveloper/jdev/extensions/oracle.maf/Samples directory.

The sample applications, such as the WorkBetter application shown in Figure 1-3, illustrate the span of MAF application capabilities, including how applications can interface with remote data using web services and interact with the SQLite database. The sample applications demonstrate the following:

• How to create a basic Hello World application

• How to enable the application to react to lifecycle events

• How to use skinning

• How to develop MAF AMX application features, including the user interface, navigation, managed beans, and data change events

For more information, see Appendix F, "Mobile Application Framework Sample Applications."