Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
claudiapacheco
Product and Topic Expert
Product and Topic Expert
0 Kudos
OverviewBackendApp ConfigurationAndroidiOS
MBO Android AppOData Android App

OData Android Content:

Synchronization

When connectivity is available, the mobile app should synchronize data between the device and the server. The synchronization happens in two stages:

  1. The device sends all the local changes to the server (Flush).
  2. The device receives all changes that have occurred since the last synchronization (Refresh).

Flush

In MBO based mobile apps, the mobile app can submit a single pending MBO, all pending MBOs of a single type, or all pending MBOs in a package. Once those pending changes are submitted to the server, the MBOs enter a replay pending state.

In OData based mobile apps, modify requests executed against the Offline Store are applied to the offline store and are stored in the request queue. the application must flush the request queue in order to propagate the stored requests to the OData Producer. During a flush, the offline store communicates with the server and attempts to execute all of the stored requests against the OData Producer. If a request fails against the OData Producer it will be stored in the Error Archive and trigger a call to the request error listener. Note that the flush operation will report a successful result even if some requests have failed against the backend OData Producer. The following flow diagram explains how the mobile app can propagate the local changes to the OData producer.

The offline store provides synchronous and asynchronous method to propagate the local changes. The EntityCollection class is using store.scheduleFlushQueuedRequest, which receives a flush listener as a parameter. The flush listener implements ODataOfflineStoreFlushListener and can be used to get progress updates of a flush operation.

  • offlineStoreFlushStarted: called when the flush operation starts
  • offlineStoreFlushSucceeded: called when the flush operation is successful
  • offlineStoreFlushFailed: called when the flush operation fails
  • offlineStoreFlushFinished: called when the flush operation finishes

Refresh

In MBO based mobile apps, the mobile app can use synchronization groups in the package or a specified list of groups to synchronize data. The synchronization group defines both the logical unit of synchronization, and generation frequency for data notifications.

In OData based mobile apps, the mobile app can use filters in the defining request to reduce the data that will be available offline. In order to manage the frequency of the synchronization, the mobile app can leverage the native framework (i.e AlarmManager) to schedule the application to update data at some points in the future.

The following flow diagram explains how the mobile app can update local data with changes from the OData producer

Similarly to the flush operation, the offline store provides synchronous and asynchronous method to refresh local data with changes from the OData producers. The EntityCollection class is using the asynchronous method store.scheduleFlushQueuedRequests that receives a refresh listener that implements ODataOfflineStoreRefreshListener and can be used to get progress updates of a refresh operation.

  • offlineStoreRefreshStarted: called when the refresh operation starts
  • offlineStoreRefreshSucceeded: called when the refresh operation is successful
  • offlineStoreRefreshFailed: called when the refresh operation fails
  • offlineStoreRefreshFinished: called when the refresh operation finishes

Please note we have submitted a sample app for publishing and it will be available in a Git repository soon