In a recent project we had to implement caching to allow an iOS mobile app to work offline, while keeping all contents up-to-date with the WordPress back-end through its REST JSON API.

Since the dataset was limited and updated once or twice a week, we decided to create a caching workflow that would allow the app to query the local database for searches and only tap into the server to update the local contents.

This requires some of the business logic (i.e. to search) to be built on the client app rather then the server, which in turn means that if you are building a native app you will need a custom cahce controller and a data manager that knows your business logic to be implemented twice (Anroid and iOS). In our experience though, most of that code is easily portable between Swift and Java, as long as it’s kept in its own class and well commented.

Let’s take a look at the Cache Controller Workflow:

• At first run, the app calls all API endpoints requred to download data from the website:
  • Use “Get All” endpoints for each entity, or use paged calls for large datasets
  • Get and parse JSON, save into local DB
  • Use 1 DB table per entity with all its field
• Store [last update date & time] to local app settings
• On App launch and on app resume, check if last update time is older than X days.
• If it is, call API endpoints “Get All” with ?after=[last update date & time]
• Get and parse JSON, update local DB with new/changed records

Note: the taxonomies (secondary entities such as post tags) only provide a unique string as ID in the standard responses. They lack the nice name and the unique integer ID. So you’ll need an endpoint to retrieve the taxonomies table too.

At this point you can use the local database to get data and search for data, by using a database manager controller that will take care of building your queries and get all necessary related data for you. You can build dictionaries or arrays for your lists to be fed to the view controllers.