Composite Development Scenario
Mobile Applications for Handhelds in the Composite Development Scenario are based on a set of components that are composed into a mobile application:
· Mobile Service Component
A Mobile Service Component contains a coherent set of Data Objects as well as business logic for these Data Objects. One or more Mobile Service Components expose their business logic to one or more Mobile UI Components.
● Mobile UI Component
A Mobile UI Component consumes business logic and data supplied by one or more Mobile Service Components and provides the user interface for these. A Mobile UI Component contains standard Web Dynpro (WD) development objects, such as the WD model, WD applications, and WD components. Mobile UI Components operate on top of service components and can be consumed by other UI components. One or more Mobile UI Components comprise the application's user interface.
· Mobile Application
A Mobile Application serves as an explicit bundling entity that groups the Mobile Service and UI Components into a single entity.
These three entities are technically represented as standard NWDI development components of type Mobile Applications for Handhelds. Each such component comes with its own meta-model of objects that it can contain. The tools in the Mobile Applications for Handhelds perspective of the NetWeaver Development Studio allow you to model (and code) the respective objects and then to automatically generate the runtime code of the component, and then to build, deploy, and run the component locally.
Any of these three entities can also be uploaded to the Data Orchestration Engine (DOE) for later deployment to mobile devices. All three are Mobile Components in the DOE-sense and are thus entities that can be deployed by means of the DOE. Their interdependencies as Development Components (DCs) are reflected as mobile component dependencies on the DOE. The dependencies that Mobile Service Components have towards Data Objects on the DOE are also captured as data object dependencies of the resulting mobile component. This chain of dependencies is reflected in the mobile component descriptor file mcd.xml)of each component (you can inspect this file in the NWDS).
The Mobile Application, however, plays a special role in this: on upload to the DOE, it is turned into a Software Package – the DOE equivalent of a mobile component-bundling entity.
Mobile Service Component
Mobile Service Components are standard NWDI Development Components (DCs) of type Mobile Applications for Handhelds and contain the business logic of a mobile application. This logic is represented as a set of model entities that are developed using specialized modeling tools in the Service Explorer.
Client Data Objects are obtained by importing Data Objects from the Data Orchestration Engine (DOE) and deselecting nodes or node attributes that are not required in the context of the Mobile Service Component. Thus, Client Data Objects are projections of their DOE equivalents.
On top of Client Data Objects, the developer can place so-called services which serve as bundling entities for all business logic, such as for queries, validation logic, and so on. A service has service operations which themselves can be of two types:
· Queries
Queries are service operations representing a query against the local data store. It is modeled in a dedicated editor and allows for complex operations, such as joins, filters, input parameters, and so forth.
More information: Creating a Query
· Custom Operations
Custom operations are hand-coded operations of a service. In the implementation of a custom operation, the developer can access the NetWeaver Mobile client’s runtime API or standard Java 2 Micro Edition (J2ME) APIs.
More information: Creating a Custom Method
Both service operations return either Java simple types (such as string, Boolean, and so forth), client data object nodes, or data structures. A data structure is an ordered list of Java simple types and client data object node attributes and is also modeled in a dedicated view.
Custom operations can throw Java Exceptions that must previously be declared in the Mobile Service Component.
Mobile Service Components can also contain messages. These are typically added as error message texts when exceptions are thrown.
The complete business logic modeled in the Mobile Service Component is consumed by the Mobile UI Component. If business logic is very complex, it can be broken up into several Mobile Service Components and Development Component dependencies can be defined as needed.
Mobile UI Component
Mobile UI Components are standard NWDI Development Components (DCs) of type Mobile Applications for Handhelds and contain the user interface (UI) of a mobile application. The UI is developed using Web Dynpro (WD) technology. This means that concepts, tools, meta-model, and many of the WD APIs are available to developers, making mobile UI development an easy task for an experienced Web Dynpro developer.
Some WD features are not supported in Mobile Applications for Handhelds and are deliberately hidden in the development tools.
More information: Supported UI Elements in the Developer Studio
Web Dynpro (WD) is based on the model-driven development paradigm Model – View – Controller (MVC):
● The model is used as an application object of the application data administration. It responds to information requests about its status, which usually originate from the view, as well as to statements on status changes, which are usually sent by the controller. In this way, only the model is used to process data internally, without referencing the application or its user interface.
A model can have different views, which can be implemented using different view pages.
In the Composite Development Scenario, the WD model is generated from the Mobile Service Component.
● The view handles the graphical and textual output at the interface and therefore represents the input and output data in each interface element, such as pushbuttons, menus, dialog boxes, and so forth. To visualize the status, the view queries the model or the model informs the view about possible status changes.
● The controller interprets and monitors the data that is input by the user (using the mouse and the keyboard), causing the model or the view to change if necessary. Input data is forwarded and changes to the model data are initiated. The controller uses the model methods to change the internal status and then informs the view about this. This is how the controller determines reactions to the user input and how it controls processing.
Mobile Applications for Handhelds provide a WD template for generating the controller from the Mobile Service Component.
Using the declarative programming techniques of WD, developers specify, which UI elements they want to have on the client devices and from where those elements get their data. UI views must be created and service-component exception handling as well as the sharing of data among views needs to be defined. The code required to create the UI is then generated automatically. The generated code is optimized to run on mobile handheld devices.
Views and UI Elements
A Mobile UI Component comprises views and UI elements.
· Views:
A UI component typically contains several views, each of which describes the layout of a visible part of the component.
The layout of a view is defined by placing UI elements on the view. The UI elements are provided in UI libraries. As a UI developer, you declare the view layout using these UI elements without making any assumptions about the rendering technology or the client.
In Mobile Applications for Handhelds, rendering is performed by using the embedded Software Widget Toolkit (eSWT), which ensures that mobile applications have the same look and feel as native applications.
· UI Elements:
¡ Are the smallest UI building blocks
¡ Are available in UI element libraries
¡ Have properties which steer their behavior
¡ Can be nested within container UI elements
¡ Are positioned in a hierarchical structure
More information: Supported UI Elements in the Developer Studio
Controllers and Contexts
Controllers are programs that store their runtime data in a hierarchical data-storage area known as the context.
· Controllers
There are two types of controller in a Web Dynpro (WD) component:
¡ Component controller
Custom controllers are not supported in Mobile Applications for Handhelds.
○ View controller
Custom or component controllers have no visual interface, whereas view controllers do.
All controllers are independent programs, yet none function in isolation from the other controllers in the component. They:
○ Contain the logic of the UI layer
○ Implement event handlers
○ Read and write context-node content
Each view has its own view controller.
· Contexts
All controller contexts are constructed from a hierarchical arrangement of entities known as nodes and attributes. A context always has a parent node known as the root node. The root node is created automatically when the controller is initialized and always has the same properties.
If the WD template for generating the controller from the Mobile Service Component is applied, the context structure exactly reflects the structure of the service operations of the Mobile Service Component.
Controller contexts:
¡ Have a hierarchy of nodes and attributes
¡ Contain the data of the UI
¡ Possess nodes and attributes, which can be bound to UI elements
Unless an explicit controller usage is declared, all the data in a controller’s context is private.
A context node is the main abstraction class used for runtime data storage within the WD framework. Context nodes are arranged hierarchically and are permitted to have children. The node may have attributes or other nodes as children.
All the child entities of a node are aggregated into a unit known as an element. A node can then be thought of as a collection of such elements in the same way that a table is a collection of rows. The maximum and minimum number of elements permitted in a node collection is controlled by the cardinality property.
All nodes contain an element collection, even if the maximum number of elements within the collection is limited to one.
An attribute is a hierarchical entity within the context that is not permitted to have children. A context attribute cannot exist without being the child of some parent node – be it the context root node itself, or some other node.
Mobile Application
A Mobile Application serves as an explicit bundling entity that joins the Mobile Service and UI Components to form a complete Mobile Application, which can then be deployed and run.
Apart from bundling mobile components, Mobile Applications also specify certain properties of the mobile application. At present, the only application-level property is the start-up application: It is defined by selecting one of the Web Dynpro (WD) applications in the project's UI components. This application will be listed on the application launcher of the Mobile Client for Handhelds.
The bundling is essentially an optional step, since mobile UI components can also be deployed directly and all dependent components are automatically be deployed with it.