I finally cleaned up and posted the notes and code from my presentation at the last CocoaHeads. See here.

Hotkeys for running AppleScript was a requested topic. Since I didn't know anything about global hotkeys, the existence of DDHotKey and ShortcutRecorder was convenient to say the least.

Since some of the target audience was new to Cocoa programming, I sprinkled helpful comments and links throughout the code, but not nearly as many as I could have — it would have been like trying to write a whole book in comments.

I was surprised how many conceptual topics even a simple Cocoa app can get into that I take for granted. It just goes to show, even the best example code is not enough to get a new Cocoa programmer started, not in a serious way. You really have to commit a bunch of time and work through Apple's conceptual documentation or something like Hillegass's book. Or go to a good training camp like Hillegass's Big Nerd Ranch.

[Presented at the joint meeting of CocoaHeads-NYC and the New York FileMaker Developers Group, July 8, 2010. I've heavily edited this since giving the presentation. The original text was much more sparse.]

Mixed audience for this meeting

Therefore:

• Partly an intro to global hotkeys
• Partly a glimpse into Cocoa development, for newcomers
• Will show two apps, one trivial and one more advanced

App One: "Hello World" of hot keys

App is called "Hotness".

• A minimal complete app
• Bare-bones UI with five buttons (actually a matrix of five button cells)
• Just one Objective-C class, four methods
• Hotkey actions are defined in five AppleScript files
• Uses a third-party library called DDHotKey which makes registering hotkeys very simple

Cocoa patterns and techniques:

• target-action (the button matrix has a target)
• delegation (the application object has a delegate)
• calling AppleScript from Cocoa
• bringing your application to the front (see the hotkey mapping for Control-0)

App Two: more realistic

App is called "WhatKeys".

• User can create, modify, and remove hotkey assignments
• Hotkeys can be mapped to either an AppleScript file or AppleScript code entered directly
• Like Hotness, uses DDHotKey
• Uses a third-party library called ShortcutRecorder for entering and displaying keyboard shortcuts

Cocoa patterns and techniques are same as in Hotness, plus:

• MVC ("Model-View-Controller")
  • a model class (WKHotKeyAssignment)
  • view controller and window controller ("coordinating controllers")
  • array controller ("mediating controller")
• bindings
• properties
• responder chain
• user defaults and property lists (for saving the user's hotkey assignments)
• handling NSError

Where to get

Here are links for the source:

• Hotness
• WhatKeys

[UPDATE 2011-01-12: I've put the code in GitHub and changed the above links accordingly.]

To compile the example code you'll need Apple's Developer Tools, which you can get for free here (requires registration). After installing the Dev Tools, double-click an xcodeproj file to open the project in Xcode.

[UPDATE 2001-02-09: This post used to be a WordPress "page", but I decided it should really be a regular blog post, so here it is.]

TUAW reports on a study by a firm called MyType, with a sample size of 20,000. The upshot? iPad owners are "rich and smart, but also spoiled and cruel."

In other words, we are winners. I knew it!

As for the iPad haters:

"bashing the iPad is, in a way, an identity statement for independent geeks."

In other words, they are losers who do exactly what they claim Apple fans do: rabidly focus on a piece of technology because it makes them feel cool.

(In case it wasn't clear: my comments are purely tongue-in-cheek. Mostly.)

Here's another usability glitch when double-tapping to select a word on the iPhone.

Suppose you're in a notes app and you're looking at a note with the keyboard deactivated. Double-tap a word near the bottom of the screen. The word is selected, as it should be. In some apps, the keyboard slides up to allow you to start editing.

The problem is that the second of your two taps lands on a point that lies within the keyboard area, so you unintentionally type whatever character corresponds to the key at that point.

This happens in Notespark and Simplenote, because they bring up the keyboard, but not in Apple's Notes app. In Notes, single-tapping brings up the keyboard but double-tapping does not, perhaps because of this very problem.

I'm not sure whether this should be considered an app problem or an OS problem. I lean toward OS, because from the user's perspective touch events should be captured by the view I actually touched. I suspect the issue is related to the way Core Animation works. The first tap immediately adds the keyboard into the view hierarchy, so technically the second tap really is in the keyboard, but you don't see the keyboard until it animates into place.

On the other hand, I would think the app should be able to deal with this fact, though I haven't thought the logic through. Maybe Apple's approach in their own app should be a hint that there's no good solution.

I wanted to include screen shots, but again, I don't have time.

I just filed the following as rdar://8231424 ("double-tap to select a word is sluggish in long documents"). I'd have mirrored the bug on Open Radar, but I don't have time. Maybe later.

Summary: Double-tap selects a word instantaneously if keyboard is off, but with a long delay if keyboard is on.

Steps to Reproduce: In the iOS Notes app, edit a long document (mine was 8K, about 600 short lines). Make sure the keyboard is active. Double-tap a word to select it. It takes a second or two to select the word. Since there is no visual feedback during that time it is not clear whether the double-tap was detected, and whether it was done in the intended spot. Now tap "Done" to deactivate the keyboard and double-tap a word. Now the word is selected immediately.

Expected Results: Immediate selection of the double-tapped word.

Actual Results: A delay of a second or so.

Regression:

Notes: I saw this on an iPhone 4.

I originally saw this when editing a todo list in the Notespark iPhone app. (I have a todo list that was intended to be a quick "do it now" list but grew to 8K and 600 lines, so you can see how good I am at getting things done.) At first I blamed Notespark, which hasn't been updated in a long time so I guessed maybe Apple had changed the text APIs and Notespark simply needed to modernize. But I saw the same problem in Simplenote and Apple's own Notes app. This is with iOS 4.01.

I see the problem does not happen on my iPad — double-tap always selects the word instantaneously. I don't know if this is because the iPad has faster hardware, or because it's only running iPhone OS 3.2.1.

Speaking of modernizing, I really, really want a version of Notespark for the iPad. I'd pay a couple of bucks for it. Notespark says they're looking into it, but I don't understand why there would be hesitance or delay. Maybe they don't see sales numbers justifying the development cost? Maybe I'm underestimating the effort to design a good UI around the larger screen space (I'm thinking of the conflict resolution UI)? All I know is, I would switch to a different notes app in a minute if there was one that supported three-way merge and had an iPad version. I haven't researched this lately, so maybe there's a competitor I don't know about.

That's something else I don't understand — why nobody else but Notespark seems to think merging is important. Maybe I use notes apps differently from most people.

Maybe I should finally get my iOS developer chops up to speed and offer to do the work for free.