What is Offline OData Client SDK ?
As of releases 2.x.x, the SUP OData Client SDK was purely for applications transacting online with live back-end data. Having said this, there was an option given to temporarily cache or persist small amounts of data for the application to continue to work seamlessly in case there is a drop in connectivity for a short while. With SUP rechristened as SAP Mobile Platform (SMP) and starting from SMP 3.0, the OData Client SDK takes these offline capabilities to a new level where the same application working online 99% of its running time, can work like a seamless offline/online application. The most important difference here being the fact that the application can make changes to data when it is off connectivity which later get propagated to the back-end, order respected.
Hence, for the client SDK to function like a typical offline enabled library, changes were made not only to incorporate a persistent cache but also have a request queue to store the change requests (HTTP(s), since OData SDK still deals with REST over HTTPs) in that order in which they were made when the application was not in a state to connected to the desired server. This was not supported in SUP versions 2.x.x.
The most important fact to be noted here is that all the offline capabilities are incorporated as a part of the client SDK itself and no additional effort is needed from the server side. The server continues to behave like the proxy it did in the previous versions of SUP.
What are its features ?
Some of the new features included in the new SMP 3.0 client SDK to support offline includes:-
Queuing of Requests
- Queuing of change HTTP(s) requests in the request queue on the client when the application is unable to reach the desired end-point or no connectivity [ Ex: Create (POST)/ Modify (PUT)/ Delete (DELETE) ]. All Fetch requests are fired as if the application is working online. It works if the back-end server is reachable, else it fails.
- Automatically detecting changes in connectivity with the desired backend so that the requests are either queued (when switched to offline) or they are fired from the queue (when online).
- Option to clear this request queue in case of catastrophic situations.
Caching of Data
- Working with a persistent or in-memory cache, based on the choice of application developer, defaulted to persistent.
- Working with a server copy of the data (which has data exactly as obtained from the server) and a local copy (data manipulated by the client application when offline). The server cache is maintained per URL used to fetch the data as against the local cache which contains data stored according to the Entry ID (OData way identifying a unique instance).
- Merging of subsequent delta data from the back-end with the already existing initial data in the server cache. This saves bandwidth which will be used to get all the data repeatedly as in case of a pure online application.
- Create new data or modify/delete existing data on cache. These change operations DO NOT modify the server cache, they create a corresponding local copy and flag it as created/modified/deleted. Now that there can be 2 versions of the same data present in the cache, the onus is on the application developer to display the latest data (either got from the server or modified on the client based on the timestamp).
- Clearing of server cache entries per URL and local cache entries per Entry ID
- Registering for notification listeners for changes to the server cache entries of a particular URL. More than 1 listeners can be registered if the notification is needed across views/intents in the client application.
- Providing an option to cache and retrieve Service document and Meta Document. This can be extended to store generic documents like PDFs, images etc.
What segment of applications does it target ?
The cache on the SDK resembles closely the cache on a web browser. Each page is cached as it is and chances are that the same content across pages are stored as duplicates. Same goes with the Offline Client SDK.
This Offline Client SDK target exactly the next level of applications after the pure online applications. They are simple applications running light to medium-heavy amount of data which need offline capabilities.
For instance, an application like Leave request approval is a simple application but when running against an enterprise with a large number of employees per approving authority, it requires the data be cached on the client application of the approver so that he could approve/reject a few of them even when is he is offline.
This SDK is NOT targeted at very complex applications that deal with millions of records and GBs of data that require a lot of realignment that needs to be done on the client side.
For instance, local filtering based on fields of the OData Entry is not supported with the current implementation. So the filtered data has to be already fetched from the backend with the filter criteria being mentioned in the URL parameters. Subsequent requests with the same filter can be fetched from the cache by passing the same URL
What next ?
The current Offline SDK is just a baby step towards making the offline experience a smooth and successful one. Based on feedback already received, there are many enhancements and improvements planned for the future releases to make the developer experience seamless for offline and online applications.
