Reader-submitted Objective-C / XCode tips of 2012 | Hacker News Reader

Reader-submitted Objective-C / XCode tips of 2012

nshipster.com

81 pointscozykozy21 comments

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.

He probably used Hopper, which he has tweeted about. http://www.hopperapp.com/

I can't say for sure, but I'd assume that he manually decompiled the code in the framework.

For clarification, this is a list of some reader-submitted tricks and tips from the last month, as a way to bring in the New Year.

I'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!

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.

Second that. I was pretty upset that I couldn't make it to the last one.

Also, on the tricks front: I was proxying UITableViews to override their layout before UICollectionViews were cool :)

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?

Good point. Updated title accordingly!

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.

The LLDB View Hierarchy Dump tip is something that I think I can use again and again and again.

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.

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

A good accompanying video from one of the XCode devs is the video from WWDC 2012 319 - Effective Debugging with Xcode 4

Definitely beats view.backgroundColor = [UIColor redColor];! Though I'm not sure I'll ever to shake that trusty old "debugging" hack.

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.

Well, I use the same method until I heard the DCIntrospect library (https://github.com/domesticcatsoftware/DCIntrospect)

It's super preliminary, but if you're debugging the problem I suspect you're debugging by looking at the view hierarchy (iOS touch handling), this might be helpful: https://github.com/MaxGabriel/debugiOSTouchHandling/blob/mas...

Yeah, I spotted that earlier today actually Max, I think it must have been something related to maintaining cocoapods. The library definitely has potential :)

This is also interesting (many might not know about it): https://github.com/glock45/iOS-Hierarchy-Viewer

Reply on news.ycombinator.com