The OData Component¶
The SAP Business Technology Platform SDKs for Android and iOS include APIs that allow your mobile applications to access data services on the SAP Business Technology Platform. The OData library lets you interact with an OData endpoint to parse OData payloads, produce OData requests, and handle responses for OData versions 2 and 4.
Online and Offline Applications¶
You can use the OData module to create apps that require an online connection as well as apps that can be used when a user is offline. An app designed for offline use retrieves data from back-end OData services when it's online to create an offline OData store in a process known as "initial download." The store is initialized and populated using a list of defining queries. The app accesses and manipulates local data, then synchronizes with the back-end OData service when appropriate. During this synchronization, offline changes are uploaded and new data from the back end is downloaded. When the app is running in offline mode, a local OData provider responds to OData requests against local data.
If your app requires up-to-date back-end data and operates in area with reliable connectivity, you may not need to cache data locally and may opt to create an app that operates only in online mode.
The OData module consists of the following layers of code:
- Proxy classes
- Dynamic API
- Metadata API
Proxy classes offer convenient methods for retrieving collections and invoking service operations. The full query capability offered by the OData module is accessed through the Dynamic API. Generated proxy classes leverage the Dynamic API and simplify its use by providing quick access to entity sets, entity types, and all their properties. It is possible to use the Dynamic API without any generated proxy classes, however, doing so requires a prior knowledge of the OData data model and the semantics of the relationship between entity types.
The generated proxy classes consist of the following components:
A metadata class that represents the service metadata document. The service metadata is preserved within an internal class and is loaded on instantiation. The metadata class contains class variables for all entity sets, entity types, and service operations. These can be used directly as parameters for the Dynamic API.
A service class that supports retrieval of entity sets with or without a
DataQueryobject, count with and without a
DataQueryobject, and the invocation of service operations or function imports. The generated service class is a subclass of the Dynamic API
The service class is the main class for getting entity set data and invoking service operations. There is no need to load metadata with the generated proxy class. The service class constructor automatically loads and parses from an internal metadata file created during code generation. Additional
loadMetadatacalls will be ignored.
Strongly typed entity classes for each entity type within the service metadata document. These classes simplify the use of Dynamic API for complex query and CUD operation. In addition, there is a strongly typed getter and setter for each property.
The Dynamic API enables complex queries, create/update/delete (CUD) operations, and service operations against the OData provider. The API interacts directly with the OData service, using the entity data model definition in the service metadata document of the OData provider. Classes for this layer are in the
Using the Dynamic API without generated proxy classes requires additional code. Without generated proxy classes, developers will need to use methods from the
DataService class to look up entity sets, entity types, properties, and data methods.
Proxy classes and Dynamic API both rely on the Metadata API to obtain metadata from the service metadata document of the OData provider. The developer can use the metadata API directly for use cases where prior knowledge of the entity data model is unavailable or not embedded in the application. Usually, a developer would use this API in very special circumstances when the application needs to discover the data model at runtime.