ConnectionKit updates no.2: Transcripts

Mostly as an extremely helpful debugging aid, ConnectionKit has provision for providing a transcript of its operations. Originally, this operated by the very simple -[CKConnection setTranscript:(NSTextStorage *)] method. This has now been replaced on the branch (and will be on the trunk soonish) with a delegate method:

- (void)connection:(id <CKConnection>)connection appendString:(NSString *)string toTranscript:(CKTranscriptType)transcript

This provides several advantages:

  • The delegate can send this output anywhere it likes; a text view, the console or even a WebView.
  • Filtering can be applied to only add certain output to the final transcript, or split into several distinct logs.
  • Applications can apply their own formatting to the text, or use +[CKAbstractConnection attributedStringForString:transcript:] to use the ConnectionKit defaults.
  • Any custom classes implementing the CKConnection protocol have one less method to implement.

ConnectionKit updates no.1: Connection creation

Update: This has been superseded by ConnectionKit 1.2.

At Karelia, we're hard at work on Sandvox 1.6 which will feature a brand new publishing engine (still built atop ConnectionKit of course). To do this, we're actually working with a branch of ConnectionKit, where work is underway to modernise and simplify some of the API. I'm going to be posting a series of short articles on the changes as work wraps up; first up today is the new connection registry.

The CKConnection protocol has been overhauled to operate a little more like NSURLConnection. There is now a single initializer method, -initWithURL:. If the URL is unsupported, it will return nil. Generally you only need to use this method if you're interacting directly with a single connection type. e.g.

id <CKConnection> connection = [[CKFTPConnection alloc] initWithURL:[NSURL URLWithString:@"ftp://ftp.example.com"]];

For connections like CKFileConnection which require no URL to operate, you can pass in nil, or use the convenience -init method.

Of course, most developers are using ConnectionKit at a higher level where they support a range of connection types across the single CKConnection protocol API. In which case, you will want to interact with the connection registry which handles automatically creating the right kind of connection. e.g.

connection = [[CKConnectionRegistry sharedConnectionRegistry] connectionWithURL:aURL];

This will look at the scheme of the URL to determine the best type of connection available and then attempt to initialize one. As before, if the URL is unsuitable, nil is returned. If you don't know the URL scheme, but do know the connection type's name (for example, an app like Flow or Transmit), these sister methods exist:

- (id <CKConnection>)connectionWithName:(NSString *)name host:(NSString *)host port:(NSNumber *)port;
- (id <CKConnection>)connectionWithName:(NSString *)name host:(NSString *)host port:(NSNumber *)port user:(NSString *)username password:(NSString *)password error:(NSError **)error;

Hopefully this of some help to you. There are some extra supporting methods in CKConnectionRegistry if you need them, and we're slowly increasing the amount of documentation in the header files. As I said at the start, this is all currently taking place a branch (named NSURLConnection-style authentication), but will trickle back to the trunk in due course. If you want to use it now, FTP and WebDAV are basically stable to work with on the branch, but SFTP still has some kinks to iron out.

Dropbox

After coming across Rands' article on Dropbox, I figured I'd give it a whirl. First impressions are definitely good. I chucked a whole bunch of different documents at it, and it really does seem to work like magic. So far (touch wood), it's performed flawlessly, coping well with file packages, variable network conditions and large files.

But of course when something works so well at its core, you quickly start to look around for other deficiencies. So please don't take these points as mere griping; I think Dropbox performs fantastically as a product, but want to help improve all those little details that give the final piece of polish.

Dropbox for the Mac downloads neatly as a DMG file which attaches to reveal the standard drag and drop installation. My personal taste in this sort of situation is generally to fire the application straight up from the disk image to try it out before a proper installation. So I fired up the app and began to walk through their setup workflow. This is pretty slick with in-app account registration. A few items to consider:

  • If possible, use the Address Book API and automatically attempt to fill in the user's name & e-mail address.
  • My main computer is named "Fozzie" (yes, I'm sad enough to name my machines after Muppet Show characters). Dropbox neatly detected this, but oddly suggested I'd like to call my account "Fozzie.local" instead.
  • The installer prompted me for my admin credentials at one point, but didn't give any explanation or warning.

Pretty quickly I had Dropbox ready to go, and tested it with a few documents. So far so good. I figure it's time to take the plunge and copy it into my Applications folder. Ah, turns out Dropbox is already there; the installer has somewhat rudely gone ahead and copied it for me with no warning! Definitely deducting brownie points there.

With a new application, I always like to check out the preferences pane to look for any interesting goodies. Notes of interest here:

  • Why is the preferences pane modal? Almost all modern Mac apps use a non-modal preferences window allowing the user to see their changes in real-time.
  • There's an option to "use Leopard-style menu bar icons." I definitely prefer this choice (less obtrusive), but can't help thinking that the style isn't really specific to Leopard; every release of OS X that I've used had a similar, toned down style for menu extras. I would suggesting defaulting to this style, and even removing any option from the preferences.
  • It would be awesome if we could select multiple folders to synchronise. For example, I have both Documents and Projects directories that would be useful to have "in the Cloud."

I am impressed by the central operation of Dropbox. It really does sit there in the background, practically invisible, before leaping into action the moment I modify or add a file. The queuing algorithm is very clever as well, deftly ensuring small files don't get stuck in limbo, waiting for an earlier, much larger transfer to complete. The system definitely scores points for appearing to recognise the difference between file packages and a standard folder, but on the flip-side appears to disregard whether the filename extension should be visible or not. I haven't come across it in practice yet, but Dropbox also looks to handle conflicts neatly by dumping both file versions on disk and leaving it to you to sort in your own time.

In conclusion, Dropbox appears to be a near-perfect system for anyone needing to synchronise their documents across two computers in a fairly casual manner. My final gripe is that when idle, the menu bar displays the Dropbox icon with a tiny check-mark superimposed over the top. I would suggest this is unnecessary visual clutter - in its base state an application should not need to convey any extra information to the user.

© Mike Abdullah 2007-2012