It’s been a very long time (a few months, if I remember correctly) since I released a new Cocoalicious beta, but I think fans and critics alike will agree that Beta 33 was well worth the wait. I’ve been using builds of it for weeks now and I can’t get over just how significantly the changes I’ve made have improved the user experience. What are these wonderful changes you ask? Well, I’m thrilled to report that the internals of b33 have been significantly overhauled to minimize interaction with the del.icio.us API, and make all interaction with the del.icio.us server asynchronous.
You see, previous versions of Cocoalicious were heavily dependent on the del.icio.us API. Rather than maintaining its own post and tag lists, Cocoalicious always simply asked the del.icio.us server for updated data. This meant that the updated post and tag lists had to be re-downloaded every time a new post was added, or an existing post was modified. Constantly re-downloading the XML list of a user’s post gets to be pretty painful–particularly once the user has 1000+ posts and a 328 Kb XML download (as I do)!
Another major way the old Cocoalicious sucked was that, with the exception of the XML post list download, all of its HTTP requests were done synchronously. This meant that when the user posted a new link, deleted a link, tagged a link by dragging it to the tag list, or renamed a tag, the call to the del.icio.us API was done on the main thread. This blocked the UI (and brought up the dreaded spinning color wheel) until the del.icio.us server responded. Believe me: the lousy user experience this provided, as well as the irony of a “rich desktop client” that was less asynchronous and responsive than some of the new “Ajax” web apps, was not lost on me.
Fortunately, I put in a lot of work to fix these problems, and I think the experience of using Cocoalicious is improved massively by it. In b33, Cocoalicious does most of the work it used to rely on del.icio.us for internally. Cocoalicious now constructs and maintains its own tag list based on the current tags used in posts. When the user posts a new link, Cocoalicious simply adds it to its in-memory list, rather than re-downloading the entire post list every time. All of the server API requests necessary to relay these changes to del.icio.us are done in the background. The net effect is that Cocoalicious now truly feels as responsive as a desktop client should.
These are also important changes in that they pave the way for one of my biggest goals for Cocoalicious: implementing local persistence. The changes in b33 put Cocoalicious on the road to being an independent app that happens to sync with del.icio.us, rather than simply a rich front-end for it.
The only problem with this “async-ification” is that there is now no UI feedback to let the user know when (or if) the submission of a change to del.icio.us completes. I have some interesting ideas about how to address that I will try to post for critique and then implement in a future release.
In the meantime, enjoy the asychronicity! I know I have for the past few weeks.
(Update: Damn, I already noticed a regression: the post list is now unsorted when filtered by a full-text search. I guess b34 will probably involve fixing that…)