Hopeless Geek

The problem I had when I was starting out with Cocoa so many years ago was finding the answer to “Why?” rather than “How?” questions. There’s a lot of code out there these days and a lot of people writing code on educated guessed gleaned from reading that code.

So I’m going to make a long read a short one and explain the perfect Cocoa object. Once you have this down, memory management just comes along for free, as does KVC/KVO and mnemonic code.

A great number of Mac applications today start up and produce a very similar-looking dialog that asks if the user wants to check for updates on startup or not. Some offer to send anonymized system information and others don’t, but both are versions of Sparkle, a software update framework for Mac developers that Andy Matuschak created for Pixen and released to the world shortly thereafter. It’s remarkable because it’s small, simple, and works well.

When it first came out I wrote about it on my blog and on Mac Geekery before implementing it in Notae. It’s a really nice idea and it does its job well. Well enough that I contributed a little code to it as well so that I could keep using Finder zip archives for Notae rather than move to the more pointless and cumbersome dmg files or Terminal-generated tgz archives. I see no reason why I shouldn’t be able to use simple tools for simple problems.

So it was a little disconcerting, given my use and love of the simple idea that is Sparkle that I discovered that Andy wants to take Sparkle into a completely different direction with 2.0, and it’s not a direction that I think I can really get behind.

Take note, Core Data programmers, something stupid is afoot, and it’s even documented.

If you pass object URIs around like candy within your program for things like drag-and-drop or token fields or any other representation of your objects and then have to get the object back, use objectRegisteredForID instead of objectWithID.

When you use objectWithID you should note that it will never return nil to you on failure. It will create an invalid object and leave it astray in your managed object context preventing your users from saving their document unless you track it down and delete it. What they get instead is the following in the console.log:

Okay, I understand that you want to use brushed metal for your program. It has some nice qualities, such as quick moving of the window and those nice rounded corners at the bottom. I get it.

But, please, pretty up the window before you inflict it upon me.

That is to say, with one method call you can make the window behave like brushed metal but look like Unified with that wonderful non-distracting flat gray color.

[yourWindow setBackgroundColor:[NSColor colorWithCalibratedWhite:0.8 alpha:1.0]];

It’s ridiculously simple. A lot of the solutions I’ve seen have people trying to get the menubar via Carbon calls and using hidden functions to convert the menu reference into a Cocoa object and then monkey with it this and that way, but, really, they’re missing the point of Cocoa if they’re doing this.

The menubar is just an NSMenu, folks.

Just add an item to your application delegate:

In Interface Builder, connect the two up and save. Done.

Inserting a New Menu

For a menu to be shown, it must have a submenu.

Dragging and dropping a Core Data object between documents is a little bit of hell. The reason for this is that they aren’t NSCoding compliant and there’s no easy way to do it because initWithCoder: doesn’t let you set the managed object context to whatever the current one is. So the solution for copying, and thus for drag and drop, has been to gather a list of properties for the object and then send that over in the drag and then decode that on the other end.

Well, I found a rather quick way of doing this, and one that’s really quite easy and keeps maintenance of the data types to copy and set completely in the model (always good). Implement a method on your model object called dictionaryRepresentation and return an NSDictionary with property list types for all your data. Ensure that the keys used in the dictionary correspond to the KVC properties of your model object. To recreate the object at the other end, insert an object of the proper type into the MOC and then use the really freaking handy NSObject method setValuesForKeysWithDictionary: and pass it that dictionary. It will then iterate over it using your KVC methods and add everything back in.