Great writeup!
Why didn't you guys just use interface builder? Not only does it speed up view building in general, but, as you claimed, it would have fixed this issue in particular.
Why didn't you guys just use interface builder? Not only does it speed up view building in general, but, as you claimed, it would have fixed this issue in particular.
"...there's no more reason to abandon IB than there is to forego compilers and write all your code with a hex editor"
http://iphonedevelopment.blogspot.com/2009/10/dont-fear-inte...
Maintaining programmatically-generated views is miserable. But with IB, it's pretty simple. Wanna nudge that button up a couple pixels? Click. Drag. Done. Want to set up label and button appearances for multiple states? A few clicks save you several lines of code per UI object. As as mentioned in the above link, every line of code you don't have to write is a line of code you don't have to maintain/debug. The converse is a huge volume of code across an app to do tedious layout stuff, which doesn't sound fun.
You also cut down on compile/debug cycles, thanks to skipping things like "Oh, fuck, I forgot to set that label's background to clearColor."
Perhaps best of all, IB will help you set up autoresizing masks for your views. This process is extremely counterintuitive to me and it's nice to be able to immediately test out my changes without having to build and run for each tweak.
If that's true, why does Apple, easily the most experienced Cocoa developer of all, use nib files in its shipping products? What have you discovered about Interface Builder that the creator of the tools and frameworks doesn't know?
This isn't generated code. It's not even remotely like Frontpage. Again, from the above link:
"Interface Builder does not generate code. It doesn’t create a forms file of any sort. What it does, is actually instantiate and configure the same objects that you use in your application to show your user interface. If you add a button to your application in Interface Builder, you’re actually creating an instance of UIButton or NSButton. When you configure it, you’re actually setting state on that button instance. Then, when the nib file gets saved, that button gets serialized into the nib file using NSCoding, exactly the way we persisted objects the archiving section of the persistence chapter in Beginning iPhone 3 Development. Basically, the nib loader is doing exactly what the code you would write to create and configure the interface object would do, down to the actual method calls used."
Except instead of a couple dozen lines of code, you have no lines of code – which strikes me as an excellent deal.
"If you’re writing tons of code to implement your user interface, that’s lots of code you have to write, maintain, and debug. The nib loading code is solid. It’s been around darn near 20 years and is used in literally thousands of production applications, including most of Apple’s applications. Apple very much "eats their own dogfood" when it comes to their development tools. If you look inside the bundles of an Apple application, the chances are very high that you will find some nib files in there."
I'll use IB occasionally for some custom views but since I'm using dinking around with the CALayer level adding shadows effects, and handling rotation animations and resizes in custom ways it usually gets in the way. I honestly never feel like touching for a lot my stuff.
I also do a lot of custom views and the designer doesn't help me manage those as well. Before XCode 4, I could write IB plugins but those were removed in 4, so more and more I'm finding less use for it.
One neat trick though is that I'll create NIBs and run Nib2Objc to generate code that I'll fix up as needed: https://github.com/akosma/nib2objc
XIB files certainly do contain code, it's just interpreted by an NSCoding object instead of compiled into machine code, that's like saying a PHP file doesn't have code in it because there is something written in C that interprets it.