• Core Data
• Cocoa Bindings
• NSViewController
• Unit testing
• And more!

One of the trends in Mac development in recent years is the prevalence of single window applications such as iPhoto, Aperture and Coda. Single window interfaces can be less complex in terms of user interaction, but it can also lead to a more complex underpinning if you don’t watch yourself where you have a single window controller with everything in it¹. Apple has aimed to address this with the NSViewController class, which lets you manage portions of the user interface in their own separate class. If you have done any work on the iPhone it’s similar to UIViewController in many aspects.

Building your single window app using NSViewController is something any new Cocoa programmer should embrace, but most of the tutorials and walkthroughs I’ve seen online do not make use of it.

As a starting point, I picked the Build A Core Data Application tutorial on CocoaDevCentral. The article walks you through creating a “Blogging” application that stores posts, categories and authors. The tutorial is a great introduction to Core Data’s concepts, but it also shoves all of the logic into a single nib and window controller. This is understandable given it being a tutorial on Core Data rather than general app architecture, but I hit a bit of a stumbling block when trying to wrap my head around how to use my Core Data entities through multiple view controllers.

I’ve uploaded a sample project to my Github account that should be a good starting point. Rather than having everything in a single window, I extracted the table view and the post details into their own view controllers.

The architecture of the application should be fairly straightforward:

• MDVCAppDelegate: This has all the Core Data boilerplate code and NSApplicationDelegate methods. One thing to note is that I am creating default categories and authors in the managedObjectContext method if they don’t exist. I picked up that tip from Marcus Zarra’s Core Data book. I am not really a big fan of having all the Core Data junk stuffed into the AppDelegate, but shifting it off to its own controller can be an exercise for the user.
• MDVCMainWindowController: The main window controller has the base NSArrayController for all the posts. The nut of this class is in the windowDidLoad method.

- (void)windowDidLoad
{
  static NSInteger kSourceListViewIndex = 0;
  static NSInteger kDetailViewIndex = 1;

  self.postsListsViewController = [[MDVCPostsListViewController alloc] initWithArrayController:self.postsArrayController];
  NSView *sourceListSplitViewContentView = [[self.splitView subviews] objectAtIndex:kSourceListViewIndex];
  NSView *sourceListView = [self.postsListsViewController view];
  [sourceListView setFrame:[sourceListSplitViewContentView bounds]];
  [sourceListView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)];
  [sourceListSplitViewContentView addSubview:sourceListView]; 
  
  // And now let's load the detail view.
  self.postDetailViewController = [[MDVCPostDetailViewController alloc] initWithArrayController:self.postsArrayController];
  NSView *detailSplitViewContentView = [[self.splitView subviews] objectAtIndex:kDetailViewIndex];
  NSView *detailView = [self.postDetailViewController view];
  [detailView setFrame:[detailSplitViewContentView bounds]];
  [detailView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)];
  [detailSplitViewContentView addSubview:detailView]; 
}

What I’m doing is allocating an instance of each view controller and passing it a reference to the window controller’s array controller to bind against.

• MDVCPostsListViewController: If you look in the Xib, you’ll see that everything is bound through Files Owner.postsArrayController. This is our reference to the main window controller’s array controller. Do take note that the NSTableView has its content, selectionIndexes and sortDescriptors bound.
• MDVCPostDetailViewController: Like the other view controller, this one binds everything through Files Owner.postsArrayController, but goes through selection rather than arrangedObjects since it displays the details for the currently selected post.
• MDVCCategoriesWindowController: A window controller that lets you adjust the categories the posts can be associated with. Nothing too sexy here.
• MDVCAuthorsWindowController: Same as above, but for authors.

This is how I do it, but I’m sure there’s another (and possibly better way). One idea that comes to mind is using an NSObjectController in MDVCPostDetailViewController and having it observe the selection property of the parent array controller to manually set the controller’s content object property when the selection changes.

I put it up on Github mainly because it makes it a lot easier to update and track the changes. If you find ways to improve the code, please let me know. I am mainly posting all of this for the Google Gods in hopes that someone will someday find this, learn something and have a better application architecture going forward.

• MasterDetailVC Sample

Update: Martin Pilkington has responded with a slightly different approach to the sample app. He extracts the Core Data implementation out of AppDelegate and into its own set of classes as well as relies more on KVO than abusing NSArrayController through Interface Builder. His version also uses Rentzsch’s excellent MOGenerator to generate the Core Data classes.

1. Martin Pilkington wrote a bit about this in his Size Matters post

When Apple releases developer beta tools for the mobile platforms, I don’t install the tools on my main Mac hard drive. Instead, I install the tools in a sparse disk image that is completely separate from any other tools. Does it help? I’m not sure since the /Developer folder is self contained as of a few releases ago, but it’s a practice I continue to do out of habit and safety.

Here’s how to do it:

1. Open /Applications/Utilities/Disk Utility.app
2. File -> New -> Blank Disk Image
3. Set the parameters like so.

The benefit of using a sparse disk image is that it will grow as necessary rather than allocating and taking up a full 8GB or whatever value you set it to.

A few examples they gave me were:

• The Resharper refactoring tool for Visual Studio runs circles around Xcode’s refactoring tools. I rarely use Xcode’s tools for more than renaming ivars and methods, so this seems nice.
• Syntax checking while you type. Much like you type a document and get misspelling underlined as you go, other IDEs apparently will tell you when you mistyped an ivar or method name.
• Automatic header generation based.
• Better autocompletion
• You get the point.

The ideas they offered were appetizing, but nothing I feel are giant voids in Xcode. That being said, I’d love to see Apple improve Xcode into the IDE everyone wants it to be, so I am proposing the following:

1. File bugs on each enhancement you want to Xcode.
2. Post the bug information to OpenRadar.
3. Notify others via a blog post or Twitter so others interested in a similar feature can dupe it.
4. Pray that the Apple Gods add support.

I’ll star the ball rolling:

• Xcode’s documentation viewer should be a separate application
• Xcode should autocomplete calls to “super”
• Xcode should auto-import for any class used

I never implement registration systems thinking they will be immune to crackers and others who are destined to find a way to not pay for my software. Instead, I opt to make a system that is the least amount of work for the user, as well as the least amount of maintenance effort for myself.

Today 1.0 and Check Off 4 both make use of the AquaticPrime framework. AquaticPrime uses RSA encryption and generates license files. I liked it because it was dead simple to setup on my end, but the concept of a license file has proved to be a support nightmare for anyone that is not a well versed computer user. The fact is people expect serial numbers and when you email them a file with a strange extension on it, they aren’t really sure what to do.¹ Cocoa Boutique aims to make the usage of AquaticPrime less painful for the end user by hiding the license file process from the user, but it currently requires using Paypal as your payment processor.

With Today 2.0 I opted to implement a traditional serial number system similar to what you’d find on the back of a shrink wrapped disc. The support load in terms of registration issues for Today has dropped significantly, but I still run into a few users a week who have issues with typing in their serial number due to not being able to differentiate between O and 0 or I and l. Telling the user they can just copy and paste the serial from their email into Today solves the issue, but it’s still frustrating that this is one of the first experiences the user has right after paying for my product.

This all has gotten me thinking about why we are still using things like license files or arbitrary strings of letters and numbers as the way of verifying a user has purchased our software. It seems like there should be a better identifier for a user to validate their software purchase.

This is what I had in mind:

1. User purchases a copy of Product X from the Second Gear store.
2. Upon successful purchase, the user can then enter their email address into a registration dialog.
3. The app will ping home, validate that the user has indeed purchased the software, and mark it as registered.

A single network transaction to validate the user. No per-seat licenses or periodic phoning home a la Adobe or Microsoft. The idea behind this is that a user’s email address is easier to remember and type rather than a string of random characters and numbers.

I chirped up on Twitter about this and got quite a few responses that I wanted to highlight and respond to.

Justin Pennington writes:

@justin I agree but think the reason is because of having to keep that server side process up forever in order for the app to work.

It’s honestly not that much work I wouldn’t think. A PHP script that takes an email address plus a product identifier and returns a pass/fail status is minimal effort both in terms of development and maintenance.

The forever aspect of software is not something I really take too seriously. There is very little software that I was using five years ago that I’m still using today. I’ve purchased upgrades or just found a better workflow. If need be, you could offer unlocked copies of previous releases to users who request them, or if you plan to go out of business or discontinue the product, offer an unlocked copy somewhere.

Alastair Houghton of Coriolis tweets:

@justin That’s what we do here; it causes far fewer problems and very few people mind the minor inconvenience of initial activation

I recently reinstalled iPartition on my Mac mini, and the process Coriolis has in place is seamless. I honestly can’t remember how it worked, which is a testament to how easy it is for honest, paid users. Coriolis goes a step further by having user accounts that are tied to each purchase. It’s a bit more work on the server side, but it seems to be working well for them.

Daniel Jalkut chimes in:

@justin Serial numbers are simple and allow customers to activate their own purchased software at any time under their own control.

This is actually the biggest reason I have against the idea of using an email address or order number as the system for registration.

Patrick Burleson and Steve Streza says something similar:

@justin My guess would be that email addresses are easy to guess. If someone knows I own a product and knows my email: free registration.

My initial response to this was that it’s just as easy for someone to pass around the user’s serial number, but this could be afford a larger uptick in blind piracy. If I knew that Patrick had a copy of FancyApp 1.0, I could download the trial, test out his email address and possibly have a free copy.

The workaround for this could be to replace the email address with the Order # as the identifier, but I’m not sure how much of an upgrade that is versus serial numbers as the possibility of mistyping still exists. Not to mention that order numbers are tied to your purchasing system, which may be a problem longer term.

Nick Peelman brings up the enterprise angle:

Please please please remember some form of enterprise activation… no matter how insignificant you think your app is in enterprise, help out the guys running a managed environment :)

This is something I hadn’t considered, and a valid point. I’m honestly not sure of a good way to handle this without adding a ton of infrastructure work on my end for a small use case.

I am honestly not sure if there is a better system than the traditional serial, but it’s certainly something to ponder.

1. It should be noted that these people also don’t read the instructions you provide that explain exactly what to do with the file.

Unfortunately I discovered a pretty significant road block when working on improving Check Off’s accessibility. NSStatusItem, the class that inserts the check mark in the Mac’s menu bar, is not accessible via VoiceOver. Try it for yourself:

1. Launch System Preferences -> Universal Access
2. Turn on VoiceOver
3. Hold down `Control-Option-m’ to access the menu bar via VoiceOver. You’ll be at the Apple menu.
4. Press the Left and Right arrow keys to navigate between the File menus.
5. Press `Control-Option-m’ again. If you have them, you’ll jump to the standard OS X menu items like Airport, battery status and the clock.
6. Press `Control-Option-m’ again to access Spotlight’s menu.

Notice how VoiceOver skipped over your third-party menu items like Check Off, TextExpander or FastScripts? That’s not good. In essence there is no way for a user to get access to these menu items without using the mouse or establishing a hot key to toggle them.

The Apple menu extras get VoiceOver support due to them using the private NSMenuExtra class. Besides accessibility, NSMenuExtra items are draggable by holding down the Command key and moving them left or right. The disparities between NSStatusItem and NSMenuExtra were discussed back in the Jaguar and Panther eras, and sadly it doesn’t seem the two have moved any closer to being alike.

At this point, Check Off 4.1 will be fully accessible, save for the menu extra which is out of my hands. I would like to see Apple add accessibility support to the NSStatusItem class in a 10.6 point release, but I won’t hold my breath. If this is an issue for you as a developer or user, I encourage you to dupe this Radar bug.

• OpenRadar: OS X 10.5: Status Items created with NSStatusItem are not VoiceOver accessible
• rdar://5037324

Update: As Martin Pilkington pointed out, it’s actually NSStatusBar that isn’t accessible. Semantics aside, the issue remains as of Mac OS X 10.6.2.

Let’s say you are like me and want to push your code up to your project’s Kiln repository. This involves typing something along the lines of:

hg push "https://justinw@secondgear.fogbugz.com/kiln/repo/products/group/today"

Disregard the fact that Kiln URLs are reek of Linux or Windows guy cruft. That’s obviously a lot to type out. With schemes, you can shrink it a bit.

Add the following to your .hgrc file.

[extensions]
hgext.schemes=

[schemes]
k = https://justinw@secondgear.fogbugz.com/kiln/repo/products/group/

Now instead of typing out that long URL, you can type out the following:

hg push k://today

There are already predefined schemes entries for bitbucket (bb) and Google Code (gcode) repositories. Couple this with TextExpander and you have some seriously minimalist typing.

10/15/09 3:09:25 PM Check Off[197] *** -[NSCFDictionary unregisterHotKey:]: unrecognized selector sent to instance 0x1086b00 

unRegisterHotKey is a method in SGHotKeyCenter and it certainly isn’t related to SCFDictionary, NSCFString or any other method I saw it being applied to.

I fumbled with this for a while thinking that i had made a change in my code somewhere to cause the memory to be smashed a bit too soon, but kept coming up with no logical conclusion as to why the code worked without issue in Snow Leopard, but failed miserably in Leopard.

Long story short, I found the answer on the objc-language list from Bill Bumgarner:

The problem is that Clang generates the wrong write barrier for the global assignment; right for Snow Leopard, incompatible with Leopard.

If you look in SGHotKeyCenter, the sharedInstance is indeed a static global, and is being eaten alive far too soon by the collector.

...
static SGHotKeyCenter *sharedCenter = nil;

@implementation SGHotKeyCenter

+ (void)initialize {
...

There are two workarounds for the issue:

1. Switch off of Clang until the issue is resolved by Apple. GCC 4.2 works just fine.

2. Use NSGarbageCollector to disable collection on the pointer after assignment.

   [[NSGarbageCollector defaultCollector] disableCollectorForPointer:sharedCenter];
   

Hopefully this post will help a few other developers not waste a day’s work trying to figure out what was causing such a weird error.

Here’s your Radar:

• rdar://problem/7326965

Ever since Gruber linked to the new Mac OS X Automation site, I’ve been a bit obsessed with finding ways to automate workflows and tedious tasks I do on my Mac. With Snow Leopard’s newly enhanced services functionality, it’s much easier to do than ever before.

One thing I’ve long wanted to automate was the creation of clean Amazon affiliate URLs. A while back Amazon offered affiliate users the ability to create links from within Amazon itself using a bar along the top of the site, but the URLs it produces are far from clean. For example, this is the link Amazon provides for it’s Kindle through the Associates Link To This Page script.

http://www.amazon.com/gp/product/B00154JDAI?ie=UTF8&tag=carpeaqua-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B00154JDAI"

There is a lot of cruft in the URL that I don’t want to paste into MarsEdit, an email or wherever else I’m linking to a product page. What’s puzzling is that to get to the page, you really only need to append "/dp/", the product ID and your tracking ID for it to be a valid URL.

http://www.amazon.com/dp/B00154JDAI/ref=nosim/carpeaqua-20

I’ve usually worked around this by copying the Amazon created URL to my clipboard, pasting it into BBEdit, cleaning it up and then expanding my associate ID using TextExpander. With Services, I can automate this down to a single step.

I created a Safari service that allows me to select the product ID from any Amazon page URL and create an affiliate link from it. The clean, affiliated URL is then copied to my clipboard so I can paste it in whatever application I desire.

Here’s what to do:

1. Open Automator and create a new Service.
2. Set the service to receive selected text in Safari
3. Drag the “Run AppleScript” automator action into your workflow
4. Copy the script below in. Be sure to replace the "ref=nosim/carpeaqua-20" line with your own referral ID.

on run {input, parameters}
    set the_url to "http://www.amazon.com/dp/" & input & "/ref=nosim/carpeaqua-20"
    set the clipboard to the_url
    return the_url
end run

1. Save your service.

To test the service out, head to any Amazon URL and select the product ID (the string after /dp/). Right-click on the text and run your newly created service. A short, clean and affiliated Amazon URL is now on your clipboard.

The workflow on this isn’t perfect given that you can’t just copy in the entire URL, but given AppleScript’s lack of regular expression functionality, this was the best route I could think of taking.

If you find this service useful you could make me rich by either buying yourself a Kindle using this link or (even better) buy me one.

SmileOnMyMac’s PDFpen 4 has the ability to OCR documents and uses far less resources doing so than Acrobat. I’ve built a modified version of Joe Kissel’s OCR It scripts for Acrobat to use PDFpen instead.

To use it, do the following:

1. Download the script from here.
2. Unzip and place the OCR This (PDFpen) script in /Library/Scripts/Folder Action Scripts/
3. Create a folder on your Desktop or any other location you’d like.
4. Attach a folder action to the folder you created and select the OCR This (PDFpen) script as the action to perform.

Now whenever you pop a PDF into this folder, it will open in PDFpen, perform an OCR conversion, save the file and close it out.

If you find this script useful please do consider purchasing a license for Today to show your thanks.

Updated July 1, 2009 - I’ve updated the script to require PDFpen 4.1.4, which has some new OCR functionality in the AppleScript dictionary. No more GUI scripting!

I’m a big fan of foundation releases. In other words, release the bare minimum you possibly can to constitute a 1.0 and then let your users help decide the direction your application ships.

When I shipped 1.0 yesterday, I had 5 feature ideas written down. Now that thousands of people have downloaded and tried the application, I have increased that number 5x. More importantly, it’s great ideas that I never thought of myself.

Doing solo development can leave you in a bubble. Don’t worry if your application isn’t 100% perfect (Today certainly isn’t). Just ship what you can in 60-90 days and let actual, paying users help shape the direction of your product. A year from now, rather than having a 1.0, you’ll have a 2.0 that is so much better.