(I recently posted this thread to Apple’s
objc-language mailing list. I welcome feedback there or here.)
A recent Twitter conversation spurred me to think about how we use
super in Objective-C.
Recently my coworker Tom was having a hard time with converting a Mac NIB to Auto Layout. The NIB contained a split view; on the left was an instance of
OACalendarView, and on the right was a scroll view. The holding priorities of the left and right panes were 251 and 250, respectively, and the scroll view had a required width constraint of greater-than-or-equal-to 150.
For some reason, the left pane insisted on being as wide as possible, squeezing the right pane down to 150 points wide. Dragging the splitter had no effect. How do we figure this one out?
Up until three months ago, my time at the Omni Group had been spent programming solely for the Mac—I hadn’t written any iOS code professionally, and I’d only dabbled the slightest bit on the side.
That all changed when iOS 7 was announced, and I’ve now spent a solid three months as an iOS developer. For the most part, it was an easy transition; I’d picked up quite a bit of iOS knowledge peripherally, and I learned a lot more very quickly through hands-on experience. But one thing bedeviled me:
On Thursday, January 10, I gave a talk at Seattle Xcoders about Auto Layout, explaining the benefits and workings of this new technology and sharing some tips learned from our adoption of auto layout.
I’ve uploaded the slides from my talk.
I’ll upload the video once I’ve found a place to put it.
Update: Thanks to Paul Goracke of Seattle Xcoders, the video of my talk is now available as well. Unfortunately, for some reason the cursor got disassociated from the actual mouse position during the demos, and I don’t have any way to fix it. Sorry! (rdar://problem/13011198)
So WWDC 2012 was announced at early o’ clock and sold out in less than two hours. New restrictions on multiple purchases didn’t do anything to stave the ever-shortening window. As compensation for all the interested developers who won’t get to go to WWDC this year, Apple has promised to quickly post the session videos online (as they’ve done in the past few years).
Which leads me to ask: why is WWDC still worth attending? WWDC’s allure has always been the exclusive combination of three features: the sessions, the labs, and the social interaction with the worldwide Cocoa community. Now that the sessions can be gotten online mere days after the conference (and have lately been repeated locally during the Tech Talk series), and much of the community wasn’t even awake to purchase tickets, the only remaining feature of WWDC is the direct access to Apple engineers provided by the labs.
Maybe it’s time to think of a post-WWDC world. Or perhaps a world in which an event named WWDC still exists but bears no resemblance to the event we currently know.
Adding namespaces to Objective-C is a non-trivial problem. This proposal is a working draft; it may have bugs. (In particular, the definition of
@namespace blocks and the
@using directive is incomplete, but it’s analogous enough to other languages that the intent should be obvious.) This draft will certainly need updates; I welcome comments at optshiftk [at] optshiftk [dot] com.
UPDATE September 11th, 2012: You can now find this proposal on GitHub. Further development will occur there.
UPDATE April 18th, 2012: Fixed a problem with the
FwkProto example. The
@implementation directive was all sorts of screwy. Thanks to Greg Parker for catching it.
Last Thursday I gave a talk at Seattle Xcoders titled “iCloud: Lessons Learned.” I’m very grateful for the warm reception and the stunning turnout—there were over 40 attendees, many of whom asked some very good questions.
By request, I have uploaded my slides. Hopefully they will be useful.
If anyone happened to take video of the talk, please contact me at kyle dot sluder at gmail dot com.
Thanks again to Disney for hosting us and to Seattle Xcoders for inviting me to blather on about iCloud for just over an hour.
I noticed that the Resource Programming Guide has been updated for ARC, which prompted me to investigate something that has puzzled me for a long time: how does NSWindowController interact with NSWindow’s “convenience” method -isReleasedWhenClosed?
It turns out that NSWindowController actually calls -setReleasedWhenClosed:NO on its window as part of -setWindow:. It doesn’t matter if NSWindowController loaded the window from nib, or if it was initialized with -initWithWindow: directly.
This makes memory management of NSWindowController-owned windows saner. And nowadays, with our multi-core multi-GHz machines packed with oodles of RAM, it’s worth spending the extra bytes to create an NSWindowController to manage your windows rather than rely on the arcane -isReleaedWhenClosed method (and its equally-outmoded companion, the “visible at launch” flag in Interface Builder).
I’d really prefer if the Window nib templates assumed File’s Owner was an NSWindowController and unchecked the “Release when closed” checkbox by default. NSWindowController’s cleanup behavior means you can leave the “Release when Closed” checkbox checked but still reopen a closed window, which is misleading and probably the source of my confusion in the first place. I’ve filed this request as rdar://10349276 (also viewable on OpenRadar).