The suggestion that "+initialize is great for registering NSURLProtocol, NSValueTransformer, and NSIncrementalStore subclasses" is, alas, off the mark. If you use +initialize for anything that needs to be registered before it gets used, you'll end up with a chicken-and-egg problem, because +initialize doesn't run until the class's first use. +initialize is great for one-time setup of class-wide data, but it doesn't work for registering classes with the system when the act of registering is the only thing that causes them to be used.
Displaying his characteristic brilliance and familiarity of Cocoa internals Cédric Luthi submitted a reverse-engineered implementation of the NString equality methods. Fascinating!
Forgive my ignorance, but how do you go about and reverse engineer NSString equality? Looking at the code is interesting but what I'd really like to understand is where it comes from and how it was extracted; is it supposed to be close to the original implementation, is it an informed guess based on CFLite, ...? Please be patient and again forgive my ignorance.
Hey Matt, I have some amazing tricks for you but I want to save it for a Cocoaheads talk first. :-) We should get around to doing another.
Reimplementing the runtime and foundation and hacking on our Clang fork at Apportable the last 6 months, I've learned some amazingly interesting things.
zbowling, I would be fascinated to read up on some of the things you've learned. I'm based in NYC / UK so its unlikely I'd end up in the SF based cocoaheads. Any chance of a write-up for us all in the new year?
As these are reader submitted, I thought I would mention that I've just released a library for dealing with multiple analytics providers with a single API: https://github.com/orta/ARAnalytics
One I personally really like is typing "target modules lookup --address" in the debugger, followed by a hex value. Really helpful if your app crashes without an interactive stack trace, as it lets you figure out where the crash occurred in your code.
It wasn't clearly explained in the blog post, but that .lldbinit command should be all on one line. It creates a new command, ”rd”, that can be used in two ways.
Typing “rd” by itself does “po [[UIApp keyWindow] recursiveDescription]”, so it dumps your entire on-screen view hierarchy.
Typing “rd someview” does “po [someview recursiveDescription]”, so it dumps the view hierarchy starting at a specific view.
For Mac (Cocoa) apps, the equivalent message is _subtreeDescription, but since a window is not a view, the entire-hierarchy command needs to be “po [[[NSApp frontWindow] contentView] _subtreeDescription]”.
I mentioned this to Mattt on Twitter but I don't think he saw it. There's a lot you can do at the debugger and recursiveDescription can be called on any UIView or UIView subclass. So if you set a breakpoint you can do something like:
(lldb) po [self.view recursiveDescription]
from one of your view controllers to dump the hierarchy of that view. This of course will work on any object that is a subclass of UIView, such as a UITableView (subclass of UIScrollView, which is in turn a subclass of UIView), a UITableViewCell (directly inherited from UIView), etc.
It's definitely worth the time to go through it all if you spend any time debugging iOS code (and there's a Mac OS X equivalent but I can't speak for its usefulness).
I've also started writing a little piece on debugging code with lldb and Xcode, but it's a work in progress: https://gist.github.com/3943317
I keep some UIColor categories around so at least I can have prettier colours for debugging. It would be nice to make a variant of the method that (somewhat randomly) colours all views and logs the usual info + the colour out to the console.
Yeah, I spotted that earlier today actually Max, I think it must have been something related to maintaining cocoapods. The library definitely has potential :)
