Archives for : August2011

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…

Can We Go To Slides, Please?

Trying something different for my two 90-minute AV Foundation presentations at CocoaConf today, I decided to do my presentation entirely from the iPad with the VGA adapter… no laptop.

In some ways, it was an easy choice to make: I’d already done the slides in Keynote, so running the same presentation off the iPad only necessitated changing a few fonts (I usually code in Incosolata, which required a change to Courier). If anything, the app demos worked better, since running apps in the simulator precludes showing off anything particular to the device hardware, such as accelerometers, location, or (in my case) video capture. In fact, as soon as you touch the AV Foundation capture APIs in a project, you lose the ability to build for the Simulator.


Downsides include the fact that I couldn’t hop into source on Xcode, so any important code needed to be in slides (I continue to hope for Xcode for iPad, though its painful performance on my 4GB MacBook has dashed those hopes somewhat). Still, I remain impressed that I can get so much done with just the iPad… probably my biggest disappointment today was having to use the official WordPress app to upload this entry’s picture, as WordPress always destroys user data, and even if I do need it only for uploading pictures from the iPad, I don’t need the pictures more than I need the blog itself (how can it be that the WordPress app is as bad as it is?)

One thing to keep in mind for iPad-only presentations is that you cannot charge while the VGA cable is plugged in, so you need to start with enough battery power to get through your presentation. That said, it’s not hard: between two 90-minute talks, I drained my battery from 90% to 55%. The battery certainly seemed likely to outlast both my voice and my legs, so that’s not a problem.

I’m happy to leave the laptop behind whenever possible, and will probably do so at my next conference. Speaking of which, the Voices That Matter: iOS Developers’ Conference is coming to Boston on Nov. 12-13, and you can get $150 off with my speaker code: BSSPKR5.

Tomorrow is the second and final day for CocoaConf, which has a shockingly deep and thorough collection of talks for a first time conference. Nice to have another good Mac/iOS conference in this part of the country.

Update 8/23/11 – Here, after much delay, are links to the slides and sample code from my CocoaConf presentation.