Question

We have a mobile(Android and iPhone) application which need to perform offline access. I want to get an idea on what is the best way to update SqLite database on the app side in more streamlined manner.

1. One way I found is to send all the objects in JSON format via web service and there is a timestamp check to see if there is an update. if there is an update all the tables are truncated and insert again in the app side. I feel it’s very inefficient.

2. Another way is to send sql statements over web services (wrapped with JSON). first time it sends all the insert records, hereafter insert records and update records if there are new records or updates. I feel this method is very insecure.

What is the best way to perform that using Restful Web service

Answer 1

There are a few options, hardly an exhaustive list but more of examples to start your thinking around;

• To optimize version 1, you can create a trigger on the server side that updates a version field on rows that are changed. That way, if the client knows that it has version 47 and the server has version 52, you know you’ll only need to send rows with version numbers between 48 and 52 to get the client up to date. This works best if updates are mostly line by line, not ‘update all green rows to puce’ which would still send a lot of data.

• To make version 2 a little more secure, you can send all SQL except the table name and thereby lock down the changes to a particular operations (for example UPDATE/INSERT/DELETE, no SELECT) and to a particular table (ie no updates to other tables in the same database). This may be somewhat trickier to maintain, but works better if large parts of the database may be affected by a single UPDATE for example.

• Break down the operations to the database into business operations and send those instead. For example, a business operation may be “Payment made: User2, $47”, the operation itself is sent to the client and then you’d map “Payment made” to an update in the database. This would require the number of operations to be fairly small and defined (seldom a bad idea to try to define them anyway though), but works well with both line by line and sweeping updates and would probably use the least amount of data to get things up to sync (if you number the operations so that you only send them once if the client has not already received them) It also gives you an audit log for free, the users balance did not just change, you know what made it change.

Personally I’d go for option 3 if I had a choice since I like to know what the database updates actually mean and when they were done, but for existing systems it may be way too much work.