Subscribe
Sign in
One of the challenges about building apps that can work offline is syncing data between devices, servers, etc. While there are entire books written about the topics of distributed systems like this, I'll share how it works in Cook More.
Cook More is a personal digital cookbook. You can sync your grocery list and recipes with anyone else running the app, this way you can share all your recipes instantly within the app. You don't even need to have an account. This all happens over bluetooth. While I think that's a really cool feature, I really designed the sharing so that partners can have a shared grocery list without compromising their data. To that end, everything must sync seamlessly, additions, deletions, and modifications. Cook More has live-sync and a deferred-sync built in.
Live Sync:
Live sync is easy, once the devices already have a connection to each other, every time something is sent to the database, it is also encoded and sent to the other device. The receiving device just reads the packet and inserts it into its database.
Deferred Sync:
Deferred sync is more complicated, but implementing this will allow your app to be extremely robust and you won't need a server. And if you do have a server, you can still use this design to sync across connected devices.
Deferred Sync Design:
Timestamp everything. Rows in your database should have a timestamp of when the object was last modified.
Never delete, but mark deleted. Use a boolean field to mark whether something was deleted or not. This way you can save it for when you need to delete it on the remote device.
Store the time of last sync with the target device, so you don't have to send all the data every time.
Deferred Sync Algorithm:
Once the devices are paired, do this:
Pick a side to go first. Things can get weird if both sides are trying to update each other's database at the same time.
Build a list of all items that have been modified since the last sync.
Send all these items to the receiving end (similar to live sync)
Compare the incoming item to any matching item in the local database.
If it's not there, add it.
If the incoming item is newer, update/delete it (if the incoming packet says the item was deleted).
Alternatively, implement a more robust conflict resolution plan.
That's it, it's a relatively simple way to sync, but it works great so far. I've iterated several times over making everything sync properly, and this is the solution I've come up with. Each device can operate independently, and when you sync everything is reflected on the other device.
I hope my description above is clear, feel free to ask me any questions!
