CODEWITHSUNDEEP
iphonecocoacocoa-touch
NibQuestions
NibQuestions

Reputation:

NIB/XIB files with Cocoa programming - faster development time?

I have been programming with the iPhone SDK for some time now.

I have not been using Interface Builder. This scares me a little. I know that in effect I may be 'fighting the framework' but I do not see it that way.

I find it very easy to just instantiate my UITabBarController in my app delegate, instantiate a UINavigationController, then push and pop view controllers as I go.

Naturally I do not have an extensive knowledge of how to architect an app with XIB files because I have never done so, however I do know the general gist of it, having built some Mac apps in Cocoa using NIBs. So I am not completely ignorant.

My question is whether there is an increase in development time when choosing to lay out UITableViewControllers and UIViewControllers using XIBs rather than programmatically instantiating them and then setting up the ivars.

As I see it, both methods still require you to subclass the view controller for customization which will probably occur for the majority of your views. As well, there are still manual classes required for delegates, and the process of connecting outlets from within the XIB seems comparable to me from setting an ivar.

Or am I missing some other major point?

Thanks!

Upvotes: 5

Views: 1380

Answers (5)

Kendall Helmstetter Gelner
Kendall Helmstetter Gelner

Reputation: 75058

For the uses you outline just doing things in code is fine, and possibly even a little easier to understand.

Laying out views, or custom cells though... then you get into a ton of font/color/position setting that quickly explodes into a lot of code, hard to maintain and tweak. Much easier to adjust what you want in IB in those cases.

Upvotes: 0

Becca Royal-Gordon
Becca Royal-Gordon

Reputation: 17861

IB shines when you're using it to actually lay out views; even two or three views can be a real hassle to lay out and configure in code. I do tend to use it for tab bar and navigation controllers, and sometimes for subcontrollers (usually only if I think the user is very likely to use it), but that's more just because I'm already there so I find it convenient.

With this new version 3 OS they're announcing next week, I'm hoping Interface Builder gains some of the flexibility it has in Cocoa, where you can add palettes for your own classes and even build up complex non-view data structures (by using custom palettes). We'll have to see, though.

Upvotes: 2

Marc Charbonneau
Marc Charbonneau

Reputation: 40515

In the end they both accomplish the same thing. You should use either one depending on the circumstances. Most of the time writing the code to create and position views, and especially maintaining it down the road, will take much longer than using IB. In a simple app for the iPhone though, this might not be true and you'd be just as well off creating everything in code. Basically, you should know how to do both, and pick the path that involves the clearest code and quickest development.

Upvotes: 2

Genericrich
Genericrich

Reputation: 4651

Code takes much longer to write to configure UIs than IB does.

Plus, you can hand off design to designers and let them tweak the UI.

Upvotes: 2

Andrew Grant
Andrew Grant

Reputation: 58804

Don't worry too much, IMO Interface Builder is a little over-rated too.

It's definitely useful for getting things up and running quickly, or if you have an app with a lot of screens that are tedious to setup, but you're not missing much.

Upvotes: 1

Related Questions