To Sync or not to Syncurl Tuesday, February 22, 2011
To Sync or not to Sync
Extracted Page: http://spielhaus-ftw.com/blog/2011/01/to-sync-or-not-to-sync/To Sync or not to Sync
This post describes the decision-making process about choosing a proper synchronisation system for our todo management tool Today Todo.
Today Todo was released in october 2009. The idea for a small tool that captures the today’s todos was born on a sunday afternoon and after only a few hours Trung had the first prototype ready. Time has passed and Today (as we call it) has evolved. After 22 updates, beeing featured by Apple, a ton of feedback and the usual iOS carousel – we came to the conclusion that Today needs to sync its data into the cloud. This is especially important since the iPad version is nearly done and screams for an unified data source. Our requirements are simple. The sync should be flexible, simple and involve the least user intervention possible.
There are quite a few frameworks and systems to choose from. All have their pros and cons.
Since I wanted to see how competing apps did fare with cloud syncing, I evaluated the most important ones. Here is what I have found out so far.
Do it yourself
Among other sync options Appigo’s Todo outsourced their sync affairs to Moki Mobility. They have built a web app that runs on top of Google Engine. The business model involves a 14 day trial account. After that it costs 19$ per year. The web app is not exceptionally pretty but functional and sports a clean look.
The internal data structure of the iOS app is kept simple. Appigo uses a handcrafted SQLite db.
The sync process blocks the entire app although it is rather quick. However this was done with a limited data set and with a very fast internet connection. It could be a problem later on.
Overall syncing went smoothly and was very easy to set up.
From the business perspective the advantage is clear. Only those users who are really interested into cloud syncing will pay for its usage. Although the fee is low, given Appigo’s large user base I expect it to yield a respectable profit.
Another bonus is the simple setup process for the user.
The only notable disadwantage with this approach is the constant availability of the service. Since the user has to pay for it, the zero tolerance of many users will ceartainly make life hard for Appigo should the web app become unavailable at some point.
Another app that uses a similar approach is Wunderlist. This new contender made by 6wunderkinder uses its own service for syncing. Instead of a web app they have built a cross platform client based on the Titanium Framework. Upsides and downsides are the same here except that using the Titanium framework 6wunderkinder cut off their way into the Mac App Store.
As with Appigo, Guided Ways’s 2do offers several syncing options. For cloud syncing they decided to use the MobileMe calender. This option is available via in-app purchase. Since the feature set of the calender does not suffice, Guided Ways had to make some compromises. Attachments are not synced and projects and checklists appear as flat lists.
Syncing is done either manually or when the app starts and quits. Conflicts are not handled very well and may lead to confusion. Again the data structure is kept clean and simple. 2do uses a handcrafted SQLite db.
The big advantage with this approach is offloading the availability issue to Apple/MobileMe. And since MobileMe is tightly integrated with Mac OS X the synced data can be accessed easily.
Guided Ways had to force their data into the MobileMe Calendar structure. The compromises they made may not seem that bad but I suspect that the implementation was far from easy.
Another downside arises from the fact that MobileMe is a payed service. I guess this alone will drive many users away.
TouchTodo from Chen’s Photography & Software uses the Google Calender for synching. The same issues apply here.
Awesome Note from BRID went for two options. They support Evernote’s service and Google Docs. Syncing is done manually and turned out to provide the weakest experience from all test candidates. At one point I managed to unintentionally loose all my notes because it was not clear that restoring data from Google is only functional if it was previously backedup. However, Awesome Note has its own backup system that works via wifi. I still don’t know how to backup the data to Google (I thought that this was one of the benefits of syncing…)
As with the other tools, offloading the aviability issue to another provider is a big bonus.
Although Google has a large user base, putting the data into Google Docs does not really fit the purpose of a todo manager. This problem originates from the fact that Awesome Note tries to be both – a todo manager and a notes utility. Google Docs works great with notes but not so great with todos.
Another problem is that Google and Evernote limits the size of uploads. However, this does not weigh-in that much since these are extreme situations that are rarely met.
File based sync
Omnifocus from the respectable Omni Group went for a file based sync approach. They support syncing to MobileMe or any custom WebDAV folder. They do provide a Mac client that can be set to sync to these services too. Syncing happens automatically and proved to be stable and smooth. Omnifocus uses compressed xml chunks to transfer data to MobileMe. This time MobileMe is used as a mere online disk for storage.
The file based sync provides the most flexible approach for advanced users. They can use their own WebDAV folders and have the certainty that they own their data.
Another plus is the small amount of data that needs to be moved around. This results in a fast sync process.
Syncing is considered a hard problem, especially when it is done on such a basic level. The whole sync logic needs to reside inside the app and was ceartainly not easy to implement.
As with 2do MobileMe is a paid service and may not appeal to everyone.
CoreData on Dropbox
TL Quantum Inc. implemented with Todo Queue syncing via Dropbox. Dropbox is a popular online storage service. For unknown reasons syncing in Today Queue involves moving the CoreData db around on every sync! This is crazy by any means. It is not only dangerous because it may easily lead to corruption but quite wasteful since TL Quantum Inc. has chosen to keep a copy of the db for every sync.
I have chosen this app because they use Dropbox and this is the service we are most inclined towards right now. All the advantages apply with the added bonus that Dropbox is free (2gb storage). This is more than enough for syncing.
I don’t see a notable downside here (if you don’t put the db directly on Dropbox…). After a short glance at Dropbox’s API, their philosophy “keep it simple” seems to carry on here.
Conclusion and opinions needed
There really are many approaches to choose from. Right now Dropbox seams to offer the most advantages. It is free, popular and has a nice API. Their usage limits are fairly high too.
I would be very interested in your opinions. Is there something we didn’t take into account? Any gotchas?
Mat Smith was very kind to provide his view on this topic here (thanks Mat). He votes for a personal web app that can be run on the own server. Sadly this would exclude too many users and it is not feasible. His second best choice would be Google Tasks (where Google doesn’t provide an API at all…).
But one thing is certain. Regardless of the choice we make, there will be someone who will complain…
That’s it for this week. I have not decided yet on the next post, but one thing is for sure. It will be more on the teaching side than this one