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?
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.
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 :)
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
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]”.
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
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.
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.
21 comments
[ 3.0 ms ] story [ 62.3 ms ] threadI'm looking forward to doing more of these in the future, so if anyone has any ideas or suggestions, feel free to tweet them to @NSHipster. Thanks!
Reimplementing the runtime and foundation and hacking on our Clang fork at Apportable the last 6 months, I've learned some amazingly interesting things.
Also, on the tricks front: I was proxying UITableViews to override their layout before UICollectionViews were cool :)
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.
There's a lot of good information provided by Apple on debugging here: http://developer.apple.com/library/ios/#technotes/tn2239/
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
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]”.