Sci-Fi Hi-Fi

Since I’m at home sick today, and I’ve been a little bored just laying in bed, I decided to look into a small project I’ve been meaning to tackle for awhile: integrating Andy Matuschak’s excellent Sparkle software update framework into Cocoalicious.

If you’re a small developer looking for an easy way to add a software update mechanism to your application, I can’t recommend Sparkle to you in glowing enough terms. I tend to have a lot of admiration for no fuss, minimal-yet-powerful Cocoa code (think NSString+Templating), and Andy’s framework is a true marvel in that department. I wrote literally no code to integrate Sparkle into Cocoalicious–including an application menu item that manually checks for updates and a preferences window checkbox that controls whether or not Sparkle should check for updates on startup. Once Sparkle discovers that there is an update, it even handles all the details of downloading it for the user, decompressing it, and quitting and relaunching the app! The whole package makes good on the promise of Fraser’s appcasting idea in a very, very slick way.

And, what’s more, now that Cocoalicious 1.0b40 has automatic updates, you officially have no more reason to read my weblog! Perhaps I’ll have to actually come up with something interesting to say rather than simply blathering on about Cocoalicious updates…

Since Jonathan Deutsch finally got around to writing about the experimental tag UI he implemented for Cocoalicious, I thought I’d do a quick post of my own to point everyone to his write-up and mention that I’m curious to hear peoples’ feedback about the design.

As Jonathan mentions, he, Andrew Wooster, and I demoed this UI at TagCamp back in October to what I would characterize as a mixed reaction. Many people loved it, but others were concerned that the effect of the tags constantly re-ordering themselves was too disorienting. I, on the other hand, would argue that when you reach something like 900 tags (as I have on del.icio.us) spatial orientation is practically useless for navigation, and what you really need is something to help you quickly explore the relationships between your tags. And besides, the only alternative approach anyone suggested at TagCamp was the Treemap, which I think is a lot more confusing than what we came up with.

One of the things I personally love about this interface is the way it helps me discover unexpected connections in my accumulated del.icio.us knowledge. When you have 2000+ bookmarks, as I do, it’s very likely that you only remember a tenth of what you’ve actually bookmarked, and, while it may be a given that my related tags for, say, “intellectualproperty” would include “music,” it might be less obvious that they would also include “ireland” or “cooking.” It’s certainly possible to uncover such unexpected connections using the normal del.icio.us “related tags” interface, but Jonathan’s UI makes this process of drilling down almost as fast as thought itself.

Tagging (at least del.icio.us-scale tagging) presents what is almost certainly one of the most difficult UI challenges I can imagine. I’ll be interested to see how useful people find our solution once it makes it into a released build.

I’ve been slowly hacking away at one of the holy grails of Cocoalicious development–local caching of posts–for quite sometime now, and I think I finally have a build ready for public consumption. That is to say, it’s very far from perfect, but I’ve been living on it for about a week now, and it seems usable and unlikely to do much harm. And, really, what more can we ask from our software?

As a del.icio.us user, I’m thrilled to finally have local persistence going, because it means:

• I now have an automatic local backup of my del.icio.us bookmarks.
• I can actually access my bookmarks during del.icio.us’ occasional hiccups. Now, if you start Cocoalicious while del.icio.us is down (or your computer is off the network), it will fall back on its local post cache (and display “[Offline]” in the window title to let you know you’re actually looking at the cache).
• I no longer have to wait for Cocoalicious to download my entire post list unless there has actually been a change on the server side. Cocoalicious now stores its last refresh time locally and consults the del.icio.us API’s last modified time to make sure a refresh is actually needed.

That’s the good news. The bad news is that local persistence still has a lot of rough edges. Here’s some caveats to be aware of:

• Currently, if you do a post, it will cause the API’s last modified time to get updated, meaning that the next time you refresh or restart Cocoalicious, it will think it needs to do a full download (since the API’s last modified time is after the local last refresh time) even though that may not be necessary.
• You will only be able to log in in offline mode if you have the preferences set to automatically log in with a certain account. This sucks big time, but I’m going to need to overhaul the authentication code to fix it.
• If you try to post while del.icio.us is down, your post will get written to the local cache but not del.icio.us, meaning that the next time you do a refresh, it will disappear. I plan to eventually fix this by giving Cocoalicious the ability to queue posts for later submission to del.icio.us.
• I really should add a way to force a full download in case of weirdness (for example, I have occasionally seen the API last modified date be off in strange ways). Perhaps holding down shift while launching the app or refreshing?
• Syncing is currently quite dumb. In fact, what Cocoalicious does right now isn’t really syncing, since the del.icio.us API makes true syncing nearly impossibly to do. It can only tell you when a user’s bookmarks were last modified, not how (e.g. what was modified, what was added, what was deleted), so it’s essentially impossible to get away from always downloading the user’s entire collection of posts. Not sure I’m going to be able to solve that one without some help from the del.iciol.us side, although I’m open to creative suggestions.
• The local cache is in the form of an XML plist, which actually gets completely rewritten every time you post. Ideally, Cocoalicious would be able to simply insert new posts to the cache without rewriting the entire thing. Perhaps someday we’ll move to Core Data (or simply SQLite)…
• One of the obvious killer features of a local cache would be the ability to maintain private bookmarks. I’d eventually like to provide a facility for this in Cocoalicious, although this build doesn’t have it.

All of that aside, though, I think this release greatly bolsters Cocoalicious’ utility by adding a feature that almost certainly could only be done on the client side, and it hopefully paves the way for some more interesting features in the future. Be sure to give it a whirl!