Now, hot on the heels of a despised “tips and tricks” post1, a problem that has been bugging me for a while.
If you do much programming in the Cocoa environment, you’ll very quickly run into Apple’s preferred software architecture: Model-View-Controller. Every class that’s part of the grand scheme of data manipulation and display falls into one of these three categories, depending on its purpose2:
It’s been a while since I wrote on making command-line apps in Objective-C. It’s interesting to me that I don’t see more on the subject: it’s not like command-line applications are hard to make, or that Apple actively discourages them. However, the lack of documentation means it was a bit tricky for me to get started.
As linked above, I’ve previously written some notes on how to make Objective-C applications. After the success of kanban-fetch and the sudden motivation to clean it up, I’ve discovered some handy shortcuts and best practices I’ll be sticking to in the future.
OmniFocus 2 is now in public beta, and I’ve been shifting my scripts over to use its new and improved AppleScript library. Of course, since I ported all my scripts to Cocoa recently, it’s more like I’m digging into the guts of Objective-C, updating some bundled dictionaries, and the like.
All of my OmniFocus export scripts need to check if OmniFocus is running before embarking on data export. Because I’m pulling data out through the app, rather than accessing the database on file, the app needs to be open for these scripts to run. I’ve been using code that looks like the following to do this:
