The SODataStore model, with the Offline and Online variants, was designed so that MobileSDK developers could program their application's model in a consistent fashion, regardless of the specific online or offline requirements of the application. Developers will still need to set-up and configure the store(s) in their application correctly for their use case. But, the CRUD operations against an OData service provider can all be made using the <SODataStoreAsync> protocol methods.
We recently rolled out a feature in the SODataOnlineStore named 'Technical Cache', and I've heard a bit of confusion about how/if this cache storage relates to the SODataOfflineStore. Here are some notes on how the two are different, and how you can think about use cases for the Technical Cache.
SODataOfflineStore
- Supports CRUD operations, with OData query and $filter methods, with SODataStoreAsync protocol
- Uses Ultralite relational database, but does not expose SQL interface
- Database is filled according to 'defining requests' queries during setup
- Database is synchronized with OData service provider using flush: and refresh: methods on SODataOfflineStore
The SODataOfflineStore is an API layer, that wraps the Ultralite database that is synchronized with the back end, using the flush: and refresh: methods. The SODataOfflineStore wrapper essentially allows you to treat the Ultralite database like an OData backend. You use the same SODataStoreAsync methods to CRUD against the Ultralite database, as you do against the OData backend, with the SODataOnlineStore. (I.e.: both the Offline and Online stores implement the SODataStoreAsync protocol).
Direct SQL access to the Ultralite db is not provided. To query or modify the database, use standard OData query and $filter methods, as if you were sending requests to the backend service provider directly.
SODataOnlineStore Technical Cache
- Supports READ operations, with OData query and $filter methods, with SODataStoreAsync protocol using the 'cacheResponse:' delegate methods
- Stored like a dictionary, where 'key' : <OData query string>, 'value' : <last server response payload>
- Cache is filled and over-written for a particular OData query when server response is returned
- Does NOT support CUD operations
- Can be configured to only return from cache, without making request to server, by switching mode from 'active' to 'passive'
The Technical Cache described here is ONLY relevant for the SODataOnlineStore. It is designed to optimize the response time for frequently used GET queries. By enabling the feature, an additional callback is activated when making the request, which returns the previous copy of the response from the service provider. This can be immediately displayed to the end user, so that the UI is very responsive. When the server response arrives over the network, a second callback is activated, so that the UI can be updated with the current data.
You can think of the Technical Cache like a dictionary: the query string is the key, and the response payload is the value. To retrieve content of Technical Cache, simply make a regular READ request on the SODataOnlineStore, in either active or passive mode.
You should not attempt to 'query' or 'filter' against a payload in the Technical Cache, or to modify the content. It will be over-written by a successful server request. It does NOT support CUD operations!
Use Case Example
To take an example use case: let's say we have a Table View in our UI that is always visible to the end user. We want the UI to be filled with data as quickly as possible, even though we are making a request to the server. The Facebook newsfeed or other social feeds are good use cases for this type of behavior.
Let's say we were implementing Facebook's newsfeed, with a hypothetical OData service. You would have a query for the main Table View with something like:
/odata/Articles('myuserid')?$top=30&$orderby=Date
We want to get the server updates ASAP, and we don't have requirements for local CUD with synchronization. So, it makes sense to use the SODataOnlineStore.
This exact query is repeated, every time that the application comes to the foreground. We can improve the refresh time for the Table View UI, by enabling the Technical Cache on SODataOnlineStore, so that the the SODataOnlineStore delegate:
- First, returns the cached response from the last successful server request
- Later, returns the response from the server, when that comes over the network
- The cached value for the query in the Technical Cache is overwritten by this server response
With this pattern, we implement a handler in the cacheResponse: delegate method to refresh the UI after step (1). Then, we implement a similar hander in the serverResponse: delegate method to refresh the UI after step (2). Step (3) is done automatically by the SODataOnlineStore, without developer intervention.
Variants
You can alter this sequence by switching from 'active' mode to 'passive mode': in 'passive' mode, step (2) does not happen, and the SODataOnlineStore only returns the content of the Technical Cache; a server request is never made when in passive mode. This behavior may be correct for Master Data queries, where the data is not expected to change on the server. You may switch from 'active' to 'passive' mode, and back, at any time.
