Muddy Muddy Tuesday Update

So, surprise, in the new iDevBlogADay, I seem to have moved up to Tuesday. And instead of deep thoughts, all I’ve got is a grab-bag of updates:

CocoaConf ’11 – I’ve added links to the slides and all the demos to my previous entry, Can We Go To Slides, Please? Second day of the conference was as good as the first… this conference is off to a great start, with Dave Klein and his family helpers organizing everything to a T. Really good, deep, and unique talks too. The conference’s web page says that they’re coming to North Carolina next… another area that I don’t think has been served by the major touring iOS conferences so far.

iOS SDK Development, 2nd Edition – I’m nearly done with the “Programming iOS” chapter, which includes an introduction to Objective-C (and an optional slam-bang into to C) and a high-level tour of the iOS SDK platform stack. Bill, meanwhile, has been working on view controllers and all the fun new iOS 5 stuff that you can do with them.

Speaking of iOS 5, I found myself with some thoughts about the implications of Automatic Reference Counting (ARC), the iOS 5 feature that so many iOS devs are keen to work with. Since LLVM has published a paper on it, it’s public enough to talk about in the abstract without violating NDA, as long as we stay away from the particulars of the iOS 5 SDK implementation.

One thought that occurred to me was when I wrote the fairly typical:

NSString *aString = [NSString stringWithFormat:
                  @"Date is %@", [NSDate date]];

This creates an autoreleasing NSString, meaning we don’t have to worry about explicitly releasing it. But with ARC, we never have to worry about explicitly releasing anything. So you could just as easily write the non-autoreleasing equivalent:

NSString *aString = [[NSString alloc] initWithFormat:
                  @"Date is %@", [NSDate date]];

This creates a retained NSString, but so what? ARC will handle the release. If anything, this may be slightly better than the autoreleased version, since this one will be released as soon as possible, while the autorelease will occur only when the autorelease pool is drained, likely at the top of the main thread’s run loop.

I also caught myself referring to the over-release of objects and the dreaded EXC_BAD_ACCESS. This is probably the most common and most destructive problem for beginning developers, as it turns a simple memory-management mistake into a crash. In the first edition, we spent a lot of time introducing the NSZombie technique to find and kill these kinds of crashers, something I frequently find myself doing in my own work.

But if ARC works as advertised, do over-release bugs go away? If I throw all my retain/release work over to ARC, then I actually can’t over-release an object, since I won’t be doing any releasing at all!

Suddenly, I feel the debugging and performance chapters — some of my favorite stuff in the first edition and maybe the one thing I thought we’d be able to copy over from the first edition with only minor rework — now changing in scope drastically. Which means the 90% rewrite we were doing is now a 95% rewrite. Good for the readers, bad for my sanity.

Core Audio – Kevin’s got an interesting example on generating MIDI events and some of the write-up to go with it, I’m just not sure if telling the Core MIDI story is enough. It kind of begs the question of what you could actually do with the MIDI events if you were the one receiving them. But are we really going to get into the Music Player API (part of Audio Toolbox, but still pretty orthogonal to the rest of the book)? It would be great if Lion’s AUSampler unit, demonstrated at WWDC, could receive the MIDI events we’re generating, but I can’t get it working, the WWDC demo code is MIA, and there is effectively zero documentation (the six hits on Google are one-line references in changeset docs and three copies of my own post to coreaudio-api).

Also, there’s great pressure to just say pencils down and ship this damn book after two years. So… I don’t know how it’s all going to turn out. At this point, we now have to go back and make some Lion and iOS 5 fixes. When I first wrote the Audio Units chapters, I used the Component Manager because it was backwards-compatible with Tiger and Leopard. But it’s gone in Lion, so I need to move that stuff over to Audio Component Manager, and re-set expectations around Snow Leopard and Lion instead.

So, that’s Tuesday. Well, that and actual paying client work. And taking care of family up North. And getting some session descriptions written up for the next two conferences. And…

Comments (2)

  1. ARC in the new runtime is pretty smart. I believe that in the case where you call a function that returns an autoreleased object that is never assigned to a variable outside the local scope, the object is retained in the callee and released by the caller, without ever being added to an autorelease pool.

  2. See the LLVM docs on the subject: “In the worst case, this may involve an autorelease, but callers must not assume that the value is actually in the autorelease pool.”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.