iPhone (iOS) app using local sqlite and desire to

问题:

I have an iPhone (iOS) app that keeps data in a local SQLite database on each device. The app is used to manage a virtual bank account for kids to track their allowance, spending, savings, etc. (KidsBank and KidsBank Free). I am getting a lot of requests from parents to provide a sync capability between parents and possibly even their children's iOS devices.

I have considered several options, but all are tedious and non-trivial since this basically requires database replication or a new architecture. Any transaction on any device ideally should appear (sync) to all devices in the family (as immediately as possible).

Ideally, I would like the sync to be automatic & hands off

Options include (1) Use of iCloud (2) Use a direct network connection between devices (wifi) (3) Use of a server side database and web service (JSON/RESTFul)

(1) iCloud PRO: iCloud provides distributed file sync CON: iOS 5 required, SQLite database files can not be synced via iCloud, classic database replication (and non-trivial)

Using iCloud is a strong consideration. Devices can write a custom transaction log to an iCloud file where there is one file for each device identified by a unique device ID. Global unique ids (GIDs) and last change timestamps are added to each table. All participating devices will write a unique device ID to a separate file in iCloud. Upon app launch or upon log file change, the app running on a specific device will load all transactions but not those generated on their own device from the files via iCloud. The last participating device to load the transaction will remove the transaction from the file. If the device is not the last participating device, it simply signs off on the transaction and allows the file to sync via iCloud. There may be better algorithms, but the basic idea is the same - using iCloud to push around change logs.

(2) A direct wifi connection will allow two devices to manually sych. PRO: Not as complicated to manage the sync process CON: Users must both select to sync from their apps while connected on wifi

(3) Move the entire database or manage transactions on a server. PRO: Sync is no longer required CON: Typical issues for a web-driven app. Would need to rewrite the database service layer (currently in SQL) to use a remote web service. Cost of running a server (I would use AWS).

Can anyone offer some experience in syncing SQLite between multiple devices? I'm leaning in the direction of using iCloud to push around transaction logs. I'm trying to minimize cost and complexity.

回答1:

Moving to iCloud is probably the best solution, as it is proven and made by Apple. You don't need to worry to much about the iOS 5 requirement, as according to most stats over 90% use it. iOS 5 is free to upgrade to. You could then rename your old version as Lite, and continue without syncing.

Syncing is probably one of the hardest things you do.

One solution I made is that all changes to a database leave a log, with timestamp, uniqueid and couple of other things to make sure the transaction is totally anonymous and totally unique. I have made an extremely simple web service that has two operations, you can add transaction to it, so I sync whenever the user is on wifi, so I push all changes, receive a result from the server, then delete the transaction records as they are synced.

The other action is to fetch the records, send the timestamp of last sync, userid and other.

All data is sent using JSON and received as such. It can easily handle tens of thousands of users, running on a small Amazon EC2 server.

This is pretty much how iCloud works, but I made this solution before iCloud. Now I am going to iCloud, but probably need to keep the server running for 1 more year or so, depends on usage.

Hope this helps you.

回答2:

After finding time to get back to working on the app and also with time passing and Core Data iCloud replication maturing, I converted my app to Core Data (NSSQLiteStoreType) and monitor notifications such as persistentStoreDidImportUbiquitousContentChanges. Using lightweight migrations too. Working well.