Alan Quatermain

Thus spake Deric Horn.

In related news, the paycheque which would cover the cost of my ticket to WWDC ought to clear into my bank account in 3… 2… 1…

Oh wait, no, it’ll clear tomorrow. Or maybe Friday. Well, this month at least.

sigh— this ought to put a hefty crimp into my just-starting freelance business. More on that soon, once I stop being hideously depressed.

So, it’s been some time since I promised a little Cocoa wrapper around the (private) TimeMachine client API, as used by such applications as Mail, Address Book, and iPhoto. What with one thing and another, I never got around to expanding the example code to do everything I wanted (such as pulling individual items out of a backed up data file for re-importing, similar to Address Book), but such as it is, here’s what I have right now.

Download the example code

The complete (2560×1600) screenshot

The source code is, needless to say, Leopard-only, and the Time Machine helper class uses ObjC 2.0 features such as properties and @optional protocol specifications.

The archive above contains the project, based upon Jon ‘Wolf’ Rentzsch’s CoreData tutorial. This was done purely as a time-saving measure, since this tutorial resulted in a small app with a single data store containing a bunch of separate data objects.

Yeah, okay, I was just too lazy to write my own.

The archive also contains a PDF version of a talk I gave on this subject for the Toronto CocoaHeads group. This PDF is available separately here. Once I’ve got the code cleaned up a bit and released, via Google code or my own repository, should I ever finish writing that (I said I’d been busy, didn’t I?) then I’ll rearrange that a bit & do a screencast similar to the ADC/WWDC ones.

For now, enjoy, and ping me via the comments for more information.

Cabel Sasser released his FancyZoom scripts last week, and I’ve gladly employed it here. It supports just about all the existing images, except for a couple really big ones for which I’ve turned it off. Here’s a couple more samplers, with captions! Now I’m simply waiting for Markdown to be updated to do image widths & anchor tag titles

Oh, and for those wondering when I’ll be back on track, I plan to post my (still not cleaned-up) Time Machine API stuff here a bit later.

…well, I did say they would be coming.

Click each thumbnail for a full-size picture.

This morning at 6:05, my wife gave birth to our first baby, Olivia Bethany. Both are in fine health, if a little tired right now (and both in need of food), but my wife and I are ecstatic with this addition to our family.

Today has been a long day, so I’ll break off here, but expect some more news soon.

So, I’ve not posted anything for a while — firstly I must apologize for that, I’ve simply been extraordinarily busy recently. However, I am aware of the changes in the Leopard version of BackRow, and hope to have an update ready for that soon. This will include copies of ATVLoader and the BDK for Leopard (yay ppc support), and some documentation on the changes required for other existing plugins to run on the Mac OS itself.

However, before that will come some information about Time Machine. I’ve not got an example put together yet, but I’m going great guns on working out the API used by apps like iPhoto and Address Book for their built-in Time Machine support. Back when it was first announced, this was to be a public developer feature, but it seems that plan went by the wayside. However, the APIs are in there, they just require a little working-out since we don’t seem to have headers for them. I hope to deliver those by this weekend, along with a working sample application.

Eh? Eh?

Didn’t I say that there would be an iPhone SDK coming along at some point? Well, okay, I didn’t say it here, but I did say it in IRC. Yes, really. Really. Fine, don’t believe me then.

But anyway, go & read this. No permalink unfortunately (shakes fist at Apple), so you might have to scroll down a bit.

sits back & looks smug

Well, I’ve got my iPhone project worked out. This is likely to be a goldmine for experienced developers, if you can get your stuff sorted out in time. And I plan to be picking little flakes of gold from the seat of my trousers in about 12 months’ time.

Mmmm, gold. It’s shiny.

Now, all I want for Christmas is docs for BackRow. Well, that & a moon-pony.

Mmmm, pony.

Why am I not surprised that one of my favourite writers/actors/critics is able to accurately describe the Apple users’ ethos so accurately:

Why should a faceless, graceless, styleless nerd or a greedy hog of a corporate twat deny us simplicity, beauty, grace, fun, sexiness, delight, imagination and creative energy in our digital lives? And why should Apple be the only company that sees that?

Full article here, if the site regains its composure after the thrashing it’s doubtless receiving from Fake Steve Jobs.

MacRumors today reports on a story at Gearlog, quoting Apple’s VP of marketing Greg Joswiak, in which he outlines Apple’s stance on iPhone development:

Apple takes a neutral stance - they’re not going to stop anyone from writing apps, and they’re not going to maliciously design software updates to break the native apps, but they’re not going to care if their software updates accidentally break the native apps either.

This to me echoes the reports that Apple was unconcerned about third-party Apple TV developers — that they would not be specifically doing anything to hamper that process, but that no support was offered and people who manage to brick their ATVs have only themselves to blame. The Gearlog story was in fact updated to clarify this with regards to the iPhone.

A second update to the Gearlog story mentions that Apple now says that “software updates will most likely break” native iPhone applications in the future. I take that to mean much the same as the Apple TV 1.1 update, which changed the APIs somewhat, but not extensively. So, after a software update your third-party apps may not function, but their developers will probably be able to create new versions without any real difficulty.

Recursive functions are great. They’re a very useful tool for a great many things, and in the BackRow framework’s RUIPreferenceManager class, they’re put to (presumably) good use when handling preference domains. There’s a single funnel function which uses CFPreferencesCopyAppValue() to fetch a preference from a given domain/app; if unable to find a value, it splits the domain, removes the last component (provided it’s got more than two components here) and then calls itself again with this new, shorter domain.

That in itself is not a problem. The implementation, however, has one small flaw that will at least throw an exception, and at worst cause a crash. See if you can find it:

- (id) _valueForKey: (NSString *) key forDomain: (NSString *) domain
{
    [_preferencesLock lock];
    id result = (id) CFPreferencesCopyAppValue( (CFStringRef)key, (CFStringRef)domain );
    [_preferencesLock unlock];

    if ( result == nil )
    {
        NSMutableArray * components = [NSMutableArray arrayWithArray: 
            [domain componentsSeparatedByString: @"."]];
        unsigned count = [components count];

        if ( (count == 0) || (count <= 2) )
        {
            [components removeLastObject];
            result = [self _valueForKey: key 
                              forDomain: [components componentsJoinedByString: @"."]];
        }
    }

    return ( [result autorelease] );
}

Yes, that’s right. The recursive call will return an autoreleased object. Which then gets autoreleased once more.

Oops. Time for another software update there