1 Introduction to Oracle Mobile Application Framework

This chapter introduces Oracle Mobile Application Framework (MAF), a solution that enables you to create mobile applications that run natively on both iOS and Android phones and tablets.

This chapter includes the following sections:

• Section 1.1, "Introduction to Mobile Application Framework"
• Section 1.2, "About the MAF Runtime Architecture"
• Section 1.3, "About Developing Applications with MAF"
• Section 1.4, "Sample Applications"

1.1 Introduction to Mobile Application Framework

MAF 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 an application that runs on both Android and iOS devices without having to use any platform-specific tools. After deploying a MAF application to a device, the application behaves similarly to applications that are created using platform-specific tools, such as Objective C or 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. For information on setting up, configuring, and migrating your development environment, see Installing Oracle Mobile Application Framework.

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

Figure 1-1 The MAF Application Springboard

An application feature is a reusable, self-contained module of application functionality. Each application feature 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 MAF Runtime Architecture

As illustrated in Figure 1-2, MAF is a thin native container that is deployed to a device. MAF 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.

Figure 1-2 The MAF Runtime Architecture

• 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 MAF application feature by implementing any of the following content types. Application features implemented from various content types can coexist within the same MAF 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 List View, as well as input components, 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 the following:
    • Chapter 12, "Creating MAF AMX Pages"
    • Chapter 13, "Creating the MAF AMX User Interface"
    • Chapter 14, "Using Bindings and Creating Data Controls in MAF AMX"
    • Chapter 15, "Using Web Services in MAF AMX"
    • Chapter 16, "Configuring End Points Used in MAF Applications"
    • Chapter 17, "Using the Local Database in MAF AMX"
    • Chapter 18, "Customizing MAF AMX Application Feature Artifacts"
    • Chapter 19, "Creating Custom MAF AMX UI Components"

    Task Flow —The Controller governs the flow between pages in the MAF 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 12.2, "Creating Task Flows."

    Note: Because the content is served remotely, a feature that uses a remote URL is available only as long as the server connection remains active.

    • Cordova —The Apache Cordova JavaScript APIs that integrate the device's native features and services into a MAF application. Although you can access these APIs programmatically from Java code (or using JavaScript when implementing a MAF 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 MAF, 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 14, "Using Bindings and Creating Data Controls in MAF AMX."
      • 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 16, "Configuring End Points Used in MAF Applications."
      • Credential Management, Single Sign-on (SSO), and Access Control —MAF 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 29, "Securing MAF 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 17, "Using the Local Database in MAF AMX."
      • 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 16, "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 20, "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. For more information, see Chapter 15, "Using Web Services in MAF AMX."

      1.3 About Developing Applications with MAF

      Although the components of a MAF 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.

      Depending on the application development team size and your organization, one person may fill many different roles.

      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 MAF 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 (DVT) 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 MAF 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 2, "Getting Started with MAF Application Development"
         • Chapter 3, "Configuring the Content of a MAF Application"
         • Chapter 12, "Creating MAF AMX Pages"
         • Chapter 13, "Creating the MAF AMX User Interface"
      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 27, "Deploying MAF 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 30, "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 29, "Securing MAF Applications."

      1.3.1 About Connected and Disconnected Applications

      A MAF application can run while connected to a network, but can also work in a disconnected mode, such as when there is no cellular signal. Examples include:

      • A basic connected application that includes a user interface backed directly by a web service data control that, in turn, invokes a web service hosted on a server.
      • A connected application that uses moderate (or complex) data services. For this type of application, Java classes (POJOs) exposed through data controls can dispatch data queries between the user interface and the service data source.
      • A disconnected application that manipulates data stored in the SQLite database, enabling application users to work offline. The application may need to get data from a web service, but if connectivity is lost, the data is stored locally and synchronized when connectivity is restored.

      1.4 Sample Applications

      After setting up your development environment (see Installing Oracle Mobile Application Framework ), 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

      Figure 1-3 The WorkBetter Sample Application