Blog | Mike Abdullah

Another Base64 encoding option on the Mac

Tue, 24 Apr 2012 10:47:45 +0100

Here's a handy technical tidbit, something that Dan discovered when trying to simplify some of the code we built back when we were getting Sandvox ready for the Mac App Store.

We needed an implementation of Base64 encoding and decoding. Foundation still doesn't have a public API after all these years (you should of course file a radar, duping Cédric Luthi's). We had been using an implementation in one of the libraries that we were trying to avoid linking to. So Dan did some grepping through various libraries, and found that SASL has an implementation of Base64!

So we just wrapped some simple implementations around these C-based functions:

gist: 2481732

Of course, your project will need to link to libsasl2.dylib. Note that this probably isn't doable on iOS.

Alternatives

Since publicising this on Twitter, a variety of people have mentioned their own preferences. So here's a quick list:

The first post I remember reading on the subject: Matt Gallagher's self-contained code
Dave Dribin created dedicated encoder and decoder classes; here are the tests
Simon Thulbourn went to the trouble of porting PHP's methods
Peter Hosey points out that Lion provides this functionality via the SecTransform APIs
Daniel Jalkut is using Dave Winer's old code
Cédric Luthi is coercing property list serialisation into doing it for him

Know any others? @message me or use my contact form

Inequality in equality testing

Mon, 23 Apr 2012 23:41:11 +0100

Do this:

gist: 2480081

and you’ll get back NO as the answer. So far, so sensible.

Now do this:

gist: 2480093

Congratulations! You just earnt yourself an exception.

This inconsistency between classes seems rather weird. Why don’t they behave the same? I’d argue that nil should be accepted by both, so that phrasing the test the other way round performs the same:

gist: 2480126

Both of the above cheerfully return you NO, since that’s what sending a (BOOL-returning) message to nil always gives. Wouldn’t it be nice if all four of these examples worked the same way?

Sadly, I think the chances of Apple changing Foundation’s behaviour after all this time are rather slim — let alone the headaches of remembering not to use it when targeting existing OSs. Particularly when I combed the docs and found this nugget:

In all isEqualToType: methods of the Cocoa frameworks, nil is not a valid parameter and implementations of these methods may raise an exception upon receiving a nil. However, for backward compatibility, isEqual: methods of the Cocoa frameworks do accept nil, returning NO.

So it seems that NSString is the one at fault here. Time to start replacing your calls to ‑isEqualToString: with ‑isEqual: instead? Well, probably not worth it, as, again, Apple are unlikely to pull the rug out from under you on this. But if you decide to, it fortunately seems that ‑isEqual: is basically as fast anyway.

Use non-breaking hyphens when writing about Objective-C methods

Fri, 20 Apr 2012 13:58:05 +0100

As you may have noticed, I blog about code rather a lot, often including method names inline, ‑justLikeThis. An annoynance with doing that is the risk that a web browser might split the method straight after the hyphen, making it awkward to read. Many of you will be thinking the solution is dead obvious, and indeed it is if you know it exists: use non-breaking hyphens instead of regular ones.

On OS X, this can be easily found from the Characters Palette (Edit > Special Characters… in most apps). I've added the non-breaking hyphen to my favourites for good measure.

Understanding -[NSArrayController add:]

Wed, 18 Apr 2012 08:30:35 +0100

A fairly common question on the Cocoa-dev mailing list, is how to know when ‑[NSArrayController add:] has finished doing its work. The simple is answer is: you can’t. The docs state:

Special Considerations
Beginning with Mac OS X v10.4 the result of this method is deferred until the next iteration of the runloop so that the error presentation mechanism (see Error Responders and Error Recovery) can provide feedback as a sheet.

Talk of “the result of this method” kinda implies there’s some sort of callback available, but there isn’t. To my understanding, if you really want to deal with this, your only choice is to effectively re-implement -add: yourself. Fortunately I’ve done this for you:

gist: 2367295

Looking at this, I think it becomes understandable why -add:’s result is deferred. If committing editing happens to fail, then Cocoa will present that error as a sheet. The delegate is only called once that alert has been dismissed. This does raise the question (rdar://11270645) though of how Apple’s implementation handles such failures. Does it go ahead and add a new object anyway? Are the pending changes discarded? Or perhaps it bails out, hopefully at least beeping to indicate the failure.

Cocoa has a rather odd design for sheet-handling whereby you cannot immediately present one after another without calling -orderOut: on the first. Alternatively, you can put off presenting the sheet until the next spin of the runloop. It seems from the docs that NSArrayController anticipates such a scenario by delaying its call to commit editing, just in case a sheet does need to be presented. I’ve assumed that you’re in control of your code enough to order out a previous sheet manually if needed, and so left it out of the code.

I think the only other thing worth noting is that you can’t quite apply this same code as an extension to NSTreeController, since its -newObject method doesn’t have the smarts to deal with creating managed objects. You’d need to override -newObject yourself too, or provide equivalent logic inside of -addWithCompletionHandler:

New template

Tue, 17 Apr 2012 18:28:36 +0100

I fancied a change. So there.

An -awakeFromInsert gotcha

Tue, 27 Mar 2012 16:40:02 +0100

Imagine you’ve got a Core Data model where an entity has a one-to-one relationship with another. Say, “ObjectA” and its “Partner”. You expect a pair of these objects to be hooked up at all times. So you make life easy for yourself and create the partner automatically:

gist: 2217400

Well, don’t do this!

If you’re looking at using the new parent/child contexts feature in Core Data, the shortcut above will seriously trip you up. What the docs don’t mention is that when saving a child context, the process goes something like this:

Copies of any new objects from the child context are inserted into the parent context. They share the same ID, but are two different objects (as you’d expect!), one for each context
The insertion calls -awakeFromInsert to be called on the new objects in the parent context
Attributes and relationships are applied to the objects in the parent context so that they match the child context

If your custom -awakeFromInsert method happens to insert objects of its own, as in the example above, that code is going to run for a second time and create an extra object that is about to be orphaned by step 3. Depending on your model’s validation rules, you’ll then see this show up as either the parent context failing to save, or mysterious extra objects appearing!

The docs do state:

If you want to set attribute values in an implementation of this method, you should typically use primitive accessor methods

I’m inclined to read between the lines and reason thusly:

Setting up a relationship using the primitive setter method is no good since Core Data won’t maintain the inverse of the relationship
So I should use the proper setter method instead
But the docs tell me to use primitive setters in -awakeFromInsert (albeit for attributes)
So maybe I better just not do anything involving relationships there

On the other hand, the Core Data Programming Guide does have this to say:

Change processing is explicitly disabled around awakeFromFetch so that you can conveniently use public set accessor methods without dirtying the object or its context. This does mean, however, that you should not manipulate relationships, as changes will not be properly propagated to the destination object or objects. Instead, you can override awakeFromInsert

So that does seem to suggest that working with relationships from -awakeFromInsert is OK! Who to trust? I don’t know. Just make sure my example doesn’t bite you. And yes, I filed rdar://11119484 asking for the docs to mention this.

An NSError error

Mon, 26 Mar 2012 20:46:46 +0100

I was originally going to remind people to check their error handling code is doing the right thing (I recently found some problems in our iMedia framework of this nature), but Big Nerd Ranch saved me the effort. So instead you got “Passing errors across threads using blocks”. Hey, two articles for the price of one. Awesome!

Passing errors across threads using blocks

Mon, 26 Mar 2012 18:09:06 +0100

In these strange times of blocks and concurrency-patterned managed-object-contexts (I swear I saw one once, but it flew off before I could grab my camera), it’s not uncommon to be calling methods across thread boundaries and needing to return an error object as a result. Here’s a simple example:

gist: 2206650

So what’s wrong here? If saving fails, it will return by reference an NSError object encapsulating why, stored into the error pointer. In all likelihood, that error is autoreleased, due to be deallocated when the current pool drains. When will it drain? Well, potentially, -performBlockAndWait: runs on a different thread to the caller. And if so, that will likely drain the autorelease pool when that chunk of work completes. Quite possibly before the caller of our code is finished dealing with the error!

Normally blocks retain objects as needed for you, but because the error is passed around by reference, we have no such luxury. Instead, here’s the solution:

gist: 2209110

This ensures that the error object is kept alive for as long as the calling thread needs it.

Migrating from alias handles to bookmark data

Tue, 21 Feb 2012 16:11:32 +0000

OS X 10.6 Snow Leopard introduced a wealth of new APIs on NSURL. In particular, a set of methods for dealing with bookmark data.

A great many developers, Karelia included, have a need to keep references to files that might be moved to a new location by the user. Prior to 10.6, the best way to accomplish this was by using the old Carbon Alias Manager to create alias records, and then store the record’s data.

Snowy supersedes those APIs with native Cocoa methods on NSURL. They’re pretty straightforward and match up pretty closely to the old alias record concepts:

The bookmarkData… methods take a URL or alias file and create bookmark data from it. You can then persist that data as your app sees fit
+URLByResolvingBookmarkData:… performs the reverse, locating the best match for the file on disk (there’s an equivalent -init method too)

Various options enums can be passed in to adjust quite how these methods operate. As well as the API reference, Apple have a guide document.

Do you have existing alias record data that needs bringing into the new world? (This includes the popular NDAlias and BDAlias wrappers). You might imagine “bookmark data” is just Cocoa’s terminology for a wrapper around the old APIs, but that’s not the case.

Bookmarks use their own custom format (I assume Apple has good reason for this) that’s incompatible with the alias manager. Conversion is one-way and you have to drop down to CoreFoundation: CFURLCreateBookmarkDataFromAliasRecord.

Now is the time to look at adopting these APIs, since OS X 10.7.3 introduces an extension to the bookmark format: security-scoped bookmarks. NSURL has new options and methods to accommodate this. There’s a good chance your app will want to adopt these for when/if sandboxing rules come into effect for the app store.

Why I worry that demanding permission before accessing contact data is too crude

Thu, 16 Feb 2012 23:58:39 +0000

Apple have said that they will soon be updating iOS to check for explicit permission before an app can have access to contact data.

Consider an app like Sandvox. Yes, it doesn’t ship on iOS, and Apple haven’t announced if the Mac will be receiving the same treatment, but there are plenty of legitimate reasons like ours to use the address book API on iOS. So:

When you create a new document/site in Sandvox, we look up your “Me” card in order to pre-populate the site’s title and footer. It’s a nice touch that makes the new site instantly feel more yours. Under the scheme Apple is proposing, this access would first require you to grant Sandvox permission to access your address book. It seems to me that at this point there’s then a variety of possible reactions:

Annoyance/fear: “Why I am I being bugged for this? What is the app going to do with my info?” — made even worse if the info turns out to be irrelevant to the site!
“I have no idea what this is for; I’ll just say OK like I do to all alerts” — pretty common (if bad) behaviour that we’d be serving to reinforce
“I have no idea what this is for; I don’t want to grant access” — we’ve now bugged the user to no gain
“Hopefully this is for something smart and innocuous, I’ll say yes”

Consider me sceptical, but I think the last of these is going to be fairly rare! It seems at this point the tiny gain of this Sandvox nicety would be outweighed by all the possible ways to annoy/confuse/upset customers.

Of course I suppose Apple could add some new API that lets us tell the user why access is requested. That seems a potential trojan nightmare though; the alert could be a complete lie! In theory the app store reviewers should be able to catch such behaviour — perhaps this API would only be available to app store apps?

When sandboxing starts being widely adopted, we have the beginnings of a solution to this for app store apps. Without the address book entitlement, apps are unable to use the entire API. It becomes a lot harder to sneak through an app that access the data in an inconspicuous way. But that won’t stop apps with a legitimate use for the data from abusing it, such as uploading to a server to keep.

Perhaps there could be two or more tiers of entitlement? This Sandvox feature only needs access to the “Me” card and a few fields. Apps like Path could have a different entitlement for access to hashed data only.

Who knows really? We’ll just have to wait and see what the future brings.