Hi everyone, let’s continue.
In order to use SODataOfflineStore, we need to understand how the offline store works.
During initialization, the offline store communicates with the server to collect the data from that OData Endpoint and stores it locally on the device. In the last blog, we learned how to do it with the defining request in the code snippet.
A formal description about the defining request is:
A defining request is an OData read request that targets the OData Endpoint associated with the offline store and retrieves a subset of the OData Endpoint data. Before a store is opened, it is initialized with a set of defining requests. The set of data that is made available while disconnected on the device corresponds to the union of data received by executing all of the defining requests. During initialization, the offline store communicates with the server to collect the data from that OData Endpoint and stores it locally on the device.
Once you obtained an offline store successfully, you can do the Read operation just like you do with an online store. One thing we have to keep in mind is the fact that the offline store is the locally stored data. This means if you try to read the OData collection, which is not defined during the initialization (via the defining request), you will get an empty result.
Okie, so what we have learned is once the creation of an offline store is done, we can read the store. But we can expect that over time, the locally stored data may grow out of date compared to the OData Endpoint.
It’s time to learn another new cool thing – MobiLink, introduced with SMP3 SP4.
SODataOfflineStore is running with MobiLink behind the scenes. MobiLink is responsible to synchronize the local database in the mobile device and the database in the SMP server.
When the developer works with the SODataOfflineStore, it refers the local data in an offline store. And MobiLink handles the data communication in the most efficient way. If the OData service supports Delta Query mechanism, the transferred data can be optimized too.
It has two key tasks:
Refresh is to asynchronously communicate with the server to download any new changes to the OData content. During a refresh, the offline store communicates with the server to re-collect the data from the OData Endpoint and reconciles it with the locally stored data.
An offline store enables the application to modify data (that is, CUD operation) while disconnected. As a result, modification requests made to the offline store are stored locally in a request queue until connectivity can be re-established. When connectivity is available, 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.
…that’s all about MobiLink 101 with SMP3 SP4. Hope you have gained a quick idea how SODataOfflineStore works – so what we haven’t done yet is how we implement it with the API. We’ll talk about it in the next blog!
See you in the next blog,