Adf mobile overview

Editor's Notes

• #21: In the view layer, for ADF Mobile, you have the option of using locally rendered or server rendered views to present the user interface. For the most native user experience, you would use the new AMX component. For the server based ADF, the user interface is rendered on the server only. User interface support is primarily provided through ADF Faces Rich Client components or Trinidad components. Both of these component types are based on JavaServer Faces technology. While the underlying technologies are different, it is worth emphasizing that development paradigms are the same between the two technology stacks. You do not need to learn new development skills to develop for mobile, if you already know how to develop an ADF application.In the controller layer, when ADF Mobile AMX contents are used in an application, you can use a simplified version of ADF Task Flow for the mobile application. ADF Mobile task flow supports a subset of components when compared with server-based ADF task flows. ADF Mobile task flow supports views, control flow case, wild card control flow case, method calls, and routers. It does not support regions. However, the page flow logic resides entire on the device, enabling page navigation without any 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. ADF Mobile also supports JDBC connection and APIs to the local database. It does not support, for example, ADF Business Components. Furthermore, ADF Mobile does not implement all of the java methods supported by the server-based ADF. For example, you cannot programmatic access binding context. You would need to get to the binding data by invoking EL Expressions instead. There is also no Java proxy support for web services. Therefore, to access web services programmatically, you must invoke through data control, using the web services invocation helper classes.Lastly, for Java support, ADF Mobile’s embedded Java virtual machine follows the JAvaME CDC spec, which is based on Java version 1.4. Therefore, when writing Java code, please note that you cannot leverage any Java 1.5 and above features.
• #27: Device Native Container: An application container or template compiled as device native application binary. This provides the runtime environment for an ADF Mobile application to run as an on-device, native application in the mobile device’s operation system (for example Apple iOS). Beyond hosting all of the client-side components for an ADF Mobile application, it also provides a couple of user interface navigation features: the Spring Board and the Tab Bar that allows user to navigate to a particular feature.Web View: Web View is a part of the Device Native container that leverages device’s web engine to display and process web-based content. In an ADF Mobile application, Web View is the primary mechanism to render and deliver the application user interface. Server HTML: Server HTML represents web-based user interface that are generated on the server and delivered as a web page to the ADF Mobile application. Generation of the HTML code occurs entirely on a remote server, as well as business and page flow logic. Server HTML can access device native services such as camera through the JavaScript API supported by Phone Gap, as long as it is running inside an ADF Mobile application. Common options for server HTML-based pages are ADF Mobile browser and ADF Faces Rich Client-based pages. Local HTML: Local HTML are web pages developed using JDeveloper or third-party tools/frameworks that are directly embedded within an ADF Mobile application. These pages are delivered as a part of the ADF Mobile application. Local HTML files can access device native features through the JavaScript APIs supported by the Phone Gap.ADF Mobile AMX Views: AMX views are based on the new AMX component that delivers JavaServer Faces-like development experience to developing HTML5-based user interface. Developers define AMX views using UI and code editors in the JDeveloper, and these views are embedded into the ADF Mobile applications and deployed to the device. During runtime, JavaScript Engine in the Web View renders AMX view definitions into HTML5 controls. AMX components are built to deliver mobile optimized user experiences out of box, and supports device native user experience through extensive animation and touch gesture support. ADF Controller: A mobile version of the ADF Controller that supports a subset of ADF Task Flow components available to a server-based ADF application. It supports both bounded and unbounded ADF Task Flows, and a subset of events/scopes that are supported by the server-based ADF. Java: Provides a Java Runtime environment for the ADF Mobile application. This Java Virtual Machine is implemented in device-native code, and is embedded/compiled into each instance of the ADF Mobile application as part of the native application binary. This JVM is based on the JavaME Connected Device Configuration (CDC) specification.Managed Beans: Managed Beans are Java classes that an ADF Mobile developer can write to extend the capabilities of the framework. This allows any ADF/Java developers to leverage existing development skills to program, for example, additional business logic necessary to process data returned from the server. Managed Beans are executed by the embedded Java support, and therefore must conform to the JavaME CDC specifications.ADF Model: ADF Model in an ADF Mobile application supports a subset of Business Logic components available to server-based ADF application. It contains the binding layer that provides an interface between the business logic components and user interface, as well as the execution logic to invoke REST or SOAP-based web services.Application Configuration: Refers to services that allows key application configurations to be downloaded and refreshed. For example, URL end points for a Web Services or Remote URL connection. Application configuration services downloads configuration information from WebDav-based server-side service. Credential Management, SSO, and Access Control: Refers to client-side services that provides security-related services for an ADF Mobile application. For example, a local credential store that securely caches user credentials to support offline authentication. Another example would be access control services that would show/hide application features based on user access.Phone Gap: Phone Gap is an open-sourced code library that provides a common JavaScript API/interface to access different device services such as the camera. Phone Gap provides majority of the device-services integration for an ADF Mobile application. Phone Gap JavaScript APIs are further abstracted as Device Data Controls in the JDeveloper Design Time for AMX-based views, allowing developers to integrate device services by simply dragging and dropping Data Controls to their AMX Views.Device Native Views: These are views written in device native language (for example Objective C for iOS), compiled as native libraries, and then incorporated into an ADF Mobile application. Device native views are to be used as rare exceptions when AMX or other web-based UI are not sufficient to fully support certain application functionality that only native code can deliver. For example, a view that requires intensive graphical processing support. Local Data: Refers to data stores that reside on the device – in ADF Mobile, these are implemented as encrypted SQLite databases. Full CRUD operations are supported to this local data store through the Java layer, using JDBC-based APIs.On the server side, the Configuration Server refers to a WebDav-based server that hosts configuration files used by the Applicaction Configuration services. The Configuration Server is delivered as a reference implementation/sample – developers and IT administrators can leverage any common WebDav services hosted on common J2EE server for this purpose.
• #28: Well, after looking at the different features of the framework, let’s look at the ADF Mobile client side architecture. ADF Mobile-based applications would have a thin native layer targeted for each platform. This basically allows the application to install as a native application, as well as host device-native modules such as PhoneGap and Java Virtual Machine. For device services integration, PhoneGap is added to the framework to provide a common interface to a variety of device services.User interface is based on HTML5 and JavaScript. These are running inside a webview in the native container.ADF Mobile also embed a lightweight and headless JVM. This JVM is embedded into each instance of the application, and provides Java support.Lastly, application contents are packaged as features. A feature is a group of functionality within an ADF Mobile application. An example of the artifacts within a feature maybe a taskflow and a few AMX based screens, or may simply point to a local HTML or Remote HTML page. It contains icons, images, and names that are used when application renders the features. Whether a particular content within a feature shows up is governed by constraint. For example, you may have one feature that has two content types or taskflows – one content for the smartphone, and one for the tablet. You can set up constraint so the appropriate content is delivered for the intended target.The features are packaged into feature archive, or FAR files. An application may be composed of one or more of these application archives.This is a great feature to support modularity. For example, you may implement a feature and feature archive for account management for a sales app, and then an employee gallery for a HR app. If you need to create a mobile app that contains both account management and employee gallery, you can simply import the two feature archives from these apps, and create a new application that delivers both functionality.
• #29: ADF Mobile has a very flexible hybrid architecture, and you have a variety of options to deliver the user interface.The primary mechanism to deliver your user interface is through the new ADF Mobile AMX components. These components are similar to JavaServer Faces components, and the AMX file is similar to the jspx file for ADF Faces based applications. This means you can set its attribute to change its behavior, and use EL Expressions to, for example, bind the component to backend data. The AMX components are optimized to deliver device native user experiences, and are rendered locally on device. The AMX files are generated into HTML5 controls during runtime. The screen you see on the right is built using the AMX components. If you are creating a new mobile application from scratch and data can be accessed through web services, you would want to use the AMX components.You can also dramatically enhance your server-based web applications by adding them into ADF Mobile as Remote URL. For example, you may have an ADF Faces based application on the server. The user interface can be delivered into the webview of the ADF Mobile application, giving it a more native application user experience. Furthermore, when running inside the ADF Mobile container, these server-based web application can access device services through the JavaScript APIs provided by PhoneGap. This means you can enable, for example, camera integration even for your ADF Faces or ADF Mobile browser based applications.Lastly, you can use your favorite HTML5 framework to create local HTML page, and include these into the ADF Mobile application. You can of course leverage the PhoneGap device integrations through the JavaScript interface.The best part of all these content support is, well, you can mix a combination of these contents within the same application, or even within the same feature. This brings complete flexibility to developing your user interface.
• #31: EL: Expression Language is a syntax that defines the linkage in an AMX page to another source. This is resolved during rendering of the page and ties data to the UI. EL expressions are typically “active” connections and when the underlying data that the EL expression points to changes, the corresponding UI is updated.Bindings: Each AMX page has a backing page that holds its bindings called a Page Definition File. There is a file called the datacontrols.cpx file that tells the framework the names of each backing page def for each AMX page.Data Controls: A data control is a wrapper that allows the framework to bind to data in an abstract way regardless of it’s source. The data can be a java class, a web service or any other source. The datacontrols.dcx file contains the listing of all datacontrols defined for the project. Data controls are visualized in the Data Controls palette which allows the developer to drag and drop from there to the source/structurePane in order to create data-bound components.Managed Beans: A managed bean is simply a Java class defined on a taskflow with an identifier and a scope. You can define managed beans in the top level unbounded taskflow (adfc-mobile-config.xml) or in individual bounded taskflows. The scope of the managed beans comprise of: Application (the entire application can access this instance), pageFlow (any other page in the same taskflow can access this instance), or view (only the page that created it can access this instance). Data Object: A java class that is defined to be a data holder for the object. It represents a single “row” of data and defines the attributes with appropriate getters/setters for the data. It does not, itself, do the retrieval of data from another store.ServiceObject: A java class that is used to define the CRUD operations on an object. It returns other data objects from a store based on functions provided by the developer. There is no specific interface for this object and it’s definition is left for the developer but we define its definition here. It is typical for a Service Object to use JDBC to access a local store or use web services to get it’s data and then fill arrays of Data Objects to be returned. A Service Object is also the class that a developer would create a data control wrapper on to expose it’s methods in the Data Control palette.
• #47: Service Object: A java class that returns collections of data objects. The actual implementation of the data retrieval can be JDBC to a SQLite database, access to REST-JSON objects via the restServiceAdapter class, or by invoking other data controls like a Web Service Data Control or URL Data Control to invoke SOAP or REST-XML web services. Service objects can also use another other java methods like file I/O to retrieve data as well.