This chapter includes the following sections:
To ensure the best design for your ADF Mobile application, Oracle recommends that you follow an iterative, step-by-step development process.
Although you can develop the application features in addition to the ADF Mobile application itself, this workflow is not necessarily the standard case; application development involves creating the ADF Mobile application and embedding the application features that can be created by other developers. In other words, you create an ADF Mobile application by combining content that you create yourself with the content that was developed separately by someone else and then integrated into the ADF Mobile application. Knowing Xcode or Android application development is not a prerequisite for creating either the ADF Mobile application itself or the specific content for an application feature.
For more information, see Chapter 4, "Getting Started with ADF Mobile Application Development."
Although development needs vary depending on the target platform, the minimum requirements for creating, building, and testing an ADF Mobile application are as follows:
Oracle JDeveloper extension for ADF Mobile
Platform-specific tools (such as Xcode, Android SDK, and so on)
A mobile device or its simulator
For more information on prerequisites, see Section 3.2, "Prerequisites for Developing ADF Mobile Applications."
ADF Mobile supports the following platforms:
iOS 5 or later
Android 2.2 or later
The following mobile devices are supported:
The supported database is SQLite (see Chapter 11, "Using the Local Database").
The following are potential architectures for your ADF Mobile application:
A basic connected application: this type of application includes a user interface that is backed directly by a web service data control that, in turn, invokes a web service hosted on a server. Note that only REST-XML and SOAP-based data services can be accessed exclusively through data controls.
A connected application that uses moderate or complex data services: this type of application includes a user interface backed by Java bean data controls. In addition, Java classes (POJOs) are used to perform the following:
To retrieve and persist data from more complex data sources.
To work with data retrieved from a server before the data is passed to the user interface: if the data source is based on REST-XML or SOAP formats, then the application is backed by Java bean data controls, which, in turn, are backed by POJOs that persist data and retrieve data from a web services data control. A typical implementation case would include a Java class that backs the user interface, and another class that hosts the data retrieval logic.
A disconnected application: this type of application requires a local database populated with data. Typically, two modules of code are needed:
The first code module allows the user interface to retrieve data from the local database. This module is responsible for creating Java beans and Java bean data controls to serve data to the user interface; CRUD operations on the local database are performed using the JDBC code.
The second code module contains implementation of the Java classes that retrieve data from the server and populates the local database through JDBC code. This module can even run a background thread if you choose to implement a background data synchronization. These Java classes are responsible for data retrieval either through data controls (if REST-XML or SOAP data is consumed), or directly from JSON data sources.
For more information, see the following:
Typically, you perform the following activities when building an ADF Mobile application:
Enable access to the server-side data (optional)
Retest and debug
The steps you take to build your ADF Mobile application will generally occur as follows:
During the design stage, consider the tasks a mobile user will be performing, keeping in mind that hand-held usage is different from that of a laptop or desktop computer. How will your ADF Mobile application help users get their jobs done? How will the users interact with the device? The more streamlined the application, the more they will use it.
The next steps are to determine whether the application is required to work in a connected or disconnected mode; understand the device services integration requirements; determine the server-side data source and protocol.
When designing server-side services, it is critical to provide for optimization for the mobile access: if server-side web services are very complex, it would be difficult for the mobile application to consume them. This is not only due to the amount of data that needs to be passed, but also the amount of the client-side logic that must be written to process the results. It is preferable to expose a set of server-side interfaces provided specifically for mobile. You also need to understand the client business services that must be developed, such as all Java modules and data controls that need to be created. In addition, you should create wireframes for the views and task flow in the application, which can help you to visualize the application functionality and assist in the development process.
As a final design step, you should consider how to partition the application functionality into separate application features that represent a group of functionality and associated views. Then you can start designing the client user interface and task flows by creating wireframes.
When setting up your work environment, download and install the ADF Mobile extension, and then install the necessary components and complete the required setup for development and deployment. For more information, see Chapter 3, "Setting Up the ADF Mobile Environment."
When creating your ADF Mobile application using JDeveloper, you use the ADF Mobile application creation wizard. The artifacts that result from creating the application include descriptor files for the ADF Mobile application and for the application features, default images for icons and tabs for all supported platforms, and a set of data controls used for accessing the services of a mobile device (such as camera, GPS, or email).
For more information, see the following:
When implementing the application features, you perform a thorough evaluation of the business need to determine which application features should be included within the ADF Mobile application. Using the overview editors provided by ADF Mobile, your tasks for implementing an application feature include identifying its type (HTML, remote URL, or ADF Mobile AMX, or native UI), its display properties (display name, navigation bar and springboard icon), and its display behavior as dictated by both the mobile device capabilities and the user role.
For more information, see the following:
During the application deployment stage, you start with creating a deployment profile that will support devices and simulators for its respective platform. Creating a deployment profile may include selecting the display icon used for the ADF Mobile application itself in various orientations (such as landscape or portrait) and setting the application's signing options (such as debug or release).
You then proceed to deploying your application to the mobile device or simulator.
With ADF Mobile applications, it is required that you deploy to the device or simulator before attempting any testing and debugging (see Chapter 18, "Testing and Debugging ADF Mobile Applications"). The application cannot be run until you deploy it.
For more information, see Chapter 16, "Deploying ADF Mobile Applications."
During the testing and debugging stage, you test, debug, and optimize your application. For more information, see Chapter 18, "Testing and Debugging ADF Mobile Applications."
Enabling and configuring security for the application typically requires configuring the login server, such as the Oracle Identity Connect server, or it can be any web page protected by the basic HTTP authentication mechanism. In addition, you may have to configure the access control server.
For more information, see Chapter 17, "ADF Mobile Application Security."
After ensuring that your application functions as expected at a basic level, you can implement the Java code to access the server-side data:
For connected applications, these Java classes should invoke web services directly. If your application uses SOAP or REST XML-based data sources, you invoke web services through data controls, with the assistance of a set of helper classes that you can invoke from your code to invoke the data controls and return data. If your application uses JSON-based data sources, your code should directly invoke the JSON service and return data, after which you need to parse the JSON data from the server and populate the objects holding data collections accordingly.
For disconnected applications, your code should populate the local SQLite database. Then, the code that backs the user interface can retrieve data from the SQLite database instead of directly invoking web services.
For more information, see the following:
During the second round of deployment, you 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.
During the final round of testing and debugging, you 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.
Deploying the application to the production environment typically involves publishing to an enterprise server, the Apple App Store, or an application marketplace, such as Google Play. After you publish the ADF Mobile application, end users can download it to their mobile devices and access it by clicking the designated icon (see Appendix C, "ADF Mobile Application Usage"). The application features bear the designated display icons and display as appropriate to the end user and the user's device.
The lifecycle of an ADF Mobile application is driven by events that occur at the levels of the mobile device operating system, the JVM, and ADF Mobile. The application's reaction to these events is enabled through the use of the
LifeCycleListener's methods. For more information, see Section 5.6, "About Lifecycle Event Listeners."
After setting up your development environment (see Chapter 3, "Setting Up the ADF Mobile Environment"), you can examine ADF Mobile sample applications located in the
PublicSamples.zip file within the
/jdeveloper/jdev/extensions/oracle.adf.mobile/Samples directory on your development computer.
The sample applications demonstrate the following:
How to create a basic HelloWorld ADF Mobile application.
How to enable the application to react to life cycle events.
How to use skinning.
How to develop the ADF Mobile AMX application feature, including the user interface, navigation from page to page, managed beans, data change events, and so on.
For more information, see Appendix E, "ADF Mobile Sample Applications."
ADF Mobile AMX is basically a subframework within ADF Mobile and provides a set of layout, field, and data components that enable you to create an application feature that behaves appropriately for both the iOS and Android user experience. ADF Mobile AMX supports some of Oracle ADF components, data controls, bindings, and the Expression Language that belong to the following layers:
Model layer. See Chapter 9, "Using Bindings and Creating Data Controls."
User interface (UI) layer. See the following:
Expression Language. See Section 9.2, "Understanding EL Support."
Differences in every layer exist due to the inherent differences between a mobile application and a web application. For more information, see Section 2.9, "Comparison of ADF Mobile and Server-Based Oracle ADF."
Table 2-1 summarizes the functionality, components, and technologies supported by ADF Mobile and compares them to those supported by a server-based Oracle ADF application.
|Layer||Supported by ADF Mobile||Supported by Server-Based Oracle ADF|
Full range of data sources and data controls
For ADF Mobile AMX application feature (see Section 2.8, "ADF Mobile AMX Application Feature"):
Full ADF task flow
JavaME CDC and Java 1.4
Java EE with the latest Java
As described in Table 2-1, in the view layer, ADF Mobile provides you with an option of using locally rendered or server-rendered views to present the user interface. ADF Mobile AMX enables the most seamless user experience. For the server-based Oracle ADF, the user interface is rendered on the server and is primarily provided through ADF Faces rich client components or Trinidad components, both of which are based on the JSF technology.
In the controller layer, an abbreviated version of the ADF task flow that supports a subset of components is provided when ADF Mobile AMX contents are used in a mobile application. ADF Mobile task flow supports views, control flow case, wild card control flow case, method calls, and routers, but does not support regions. In ADF Mobile, the page flow logic resides entirely on a mobile device, enabling the page navigation without a round trip to the server.
In the ADF Model layer, ADF Mobile supports SOAP, REST XML, and REST JSON as the server-side data sources. In addition, ADF Mobile supports JDBC connection and APIs to the local database, but it does not support ADF business components. Furthermore, ADF Mobile does not implement all of the Java methods supported by the server-based ADF. For example, you cannot use the programmatic access binding context. Instead, you can access the binding data by invoking the Expression Language (EL) expressions. In addition, since ADF Mobile does not support the Java proxy for web services, to access web services programmatically, you must use data controls in conjunction with the web services invocation helper classes.
For Java support, ADF Mobile's embedded Java virtual machine follows the JavaME CDC specification, which is based on Java 1.4, meaning that you cannot use any Java 1.5 or later features in your Java code.