Data Caching Implementation for ADF Mobile MAF Application

If you are building mobile application with web service call integration, you must take into account data caching strategy. Without data caching, mobile application will try to establish too many connections with the server - this will use a lot of bandwidth and slow down mobile application performance. This post will be focused around the scenario of implementing simple data caching strategy. In my next post, I'm planning to review MAF persistence framework from Steven Davelaar - this framework is powerful and flexible. Simple data caching strategy makes sense for smaller use cases, when we don't need to use additional framework for persistence.

Data caching implementation in the sample application - MAFMobileLocalApp_v3.zip, is based on SQLite database local to the mobile application. The whole idea is pretty straightforward, there is a database and Web Service publishing data. Mobile application is reading and synchronising data through Web Service. Once data is fetched from the Web Service, it is stored in local cache, implemented by SQLite DB. For the subsequent requests, mobile application is going to use a cache, until user will decide when he wants to synchronise data from Web Service:

Sample application implements a Web Service, based on ADF BC module. This Web Service returns Tasks data (SQL script is included with the sample application):

Besides fetching the data, Web Service implements Task update method:

On the mobile application side, use case is implemented with a single Task Flow. Task list displays a list of tasks, user can edit a task and submit changes through Web Service. This change is immediately synchronised with local cache storage. User is able to refresh a list of tasks and synchronise it with a Web Service. During synchronisation it will clear local cache and populate again with the data returned from Web Service:

Data caching logic is handle in TaskDC class, Data Control is generated on top of this class, this makes it available through the bindings layer. Initially we check if cache is empty and load data from the Web Service, for the subsequent requests data is loaded from cache. Unless user wants to synchronise with Web Service and invokes refresh:

There is a method responsible for fetching data from Web Service and translating it to the Task list structure:

Data from cache retrieval is implemented in the separate method, we are querying data from local SQLite database:

When request hits TaskDC Data Control, we are checking if there are any rows in cache. If there are rows, call to Web Service is not made and rows are fetched from cache:

When user is synchronising with the Web Service, cache is cleared up and re-populated with the rows fetched from Web Service:

Update is synchronised with local cache, so there is no need to re-fetch entire data collection from Web Service:

If the local cache is empty and Web Service is invoked to fetch data, we can see this is Web Service log - it executes SQL. Later call to Web Service is not made, data loaded locally from SQLite database:

We can track update operation on the server side as well, Task details are updated using Task Id:

Initial load for the task list, this is what you should see if Web Service and MAF mobile applications runs correctly:

User could open specific task and edit task properties - changing status:

Task description could be modified:

All changes are saved through Web Service call and immediately synchronised with local SQLite database:

Selected task is updated, user is returned back to the list of tasks:

We could simulate data update on the server, lets change status for one of the tasks:

With refresh option invoked, data is synchronised on the mobile application side and local cache gets refreshed: