Mac Geekery

There’s nothing worse than an application that hides its data … no, your data from you. As a developer, you should take into account your experience as a user and avoid lock-in as much as possible, as well as enable useful “mashups” with other applications. To make it easier for users to use both your application and another with the same set of their data, you need to make it easy for users to get that data out of your application. You could support every common export type for your kind of data and hope that’s enough, or you could create a simple API to get at the data so that your users can do the work of making those exports. On the Mac, the easiest and most standard way of doing the latter is AppleScript.

With AppleScript you can setup a basic description of where you keep your data and let Cocoa Scripting take over and pull it all out of your program for you without you needing to change much at all. You’ll get features like searching and basic property editing for free. It’s quick, easy, and wonderful.

Unless you’re using Core Data. Like many other features in Mac OS X, gaining all the benefits of Core Data exempts you from the “easy” part that comes with the rest of the OS (like, oh, threading and autosave-enabled NSDocuments, for instance). It doesn’t make it impossible, it just makes it a very slight more interesting. In fact, making a read-only AppleScript interface is rather simple. Making a read/write interface is a minor pain in the posterior. Today, I’ll go over how to make a read-only interface and touch on the difficulties of making a read/write interface with Core Data. Later, I plan on covering the read/write interface when I’ve solved the ills of doing so and can explain how I got it to work. So much of this is “hold the bunny ears halfway up and lift your right leg towards the south” that it’s sometimes hard to say how something is working, or not. There's more »

So you’ve toyed with making a simple database and quickly found that you’d like to have the equivalent of multiple “tables” in your database. A reasonable request, and something that Core Data can do, again without coding. It’s not perfect, but it’s functional.

What we’ll do is take the previous call logger project and add in the ability to handle People entities and choose from them for the caller and the called. A little more work and we can see which messages were left for any given caller, but that will be left for a later article as it requires a little more effort than is done here, and I’d rather not throw it all out at once for the sake of leaving it digestible.

So if you haven’t gone through the previous walkthrough, now would be a good time as we’re making edits to that project. There's more »