views:

260

answers:

4

As I'm learning the iPhone API, the book I'm using has me doing everything possible with the Interface Builder. We (lonely here sometimes) are writing code, too, but I really feel like I'm getting to know the Interface Builder quite well.

I know that the Interface Builder is different from other GUI Builders as it uses serialized objects and doesn't write code. This is supposedly a good thing. So...in day-to-day work, is it the tool of choice, or should I try to get over my dependence on the Interface Builder?

Also: if you suggest that "it depends on what you're doing," what does it depend on? How should I make the decision to use the Interface Builder or not?

Note: The subjective and argumentative version of this question was titled, Interface Builder: Serious Tool or Just For Kids? but I decided against it since I want to avoid getting the question closed.

+6  A: 

Interface Builder really is used to make apps. Take a look at any Cocoa-based Mac app — which is most that aren't by Adobe or Microsoft — and you'll see it's full of nibs. It's slightly more common for iPhone apps to be made without Interface Builder (because the original SDK shaped without IB), but it's still a very commonly used tool.

The difference between Interface Builder and most other GUI builders is that Cocoa and Interface Builder were designed with each other in mind. In fact, if you search the Cocoa mailing list archives, you'll find lots of people over the years wondering how it's possible to make a Cocoa app without using Interface Builder. (The answer is always the same: You can do it all in code, but you'd just be wasting your time and making it harder to design a good interface.)

Chuck
Thanks, this is kind of what I was thinking. At least it's a positive note on a day filled with reference counting.
Yar
+3  A: 

Interface builder is great if you plan on using standard UIKit user interface elements. Using Interface Builder to design UIKit-based user interfaces also helps you to conform to the Apple iPhone Human Interface Guidelines.

There are only a handful of cases where you wouldn't want to use Interface Builder, the most obvious one being games that offer their own unique look and feel.

I don't think you need to be concerned about building a "dependence on the Interface Builder". It's a tool, just like any other. Using it isn't a dependence, it's just the way we get things done.

Brian
thanks Brian, this is not true with other GUI tools on other platforms. Code created with builders often-times looks horrible and can be hard to maintain. So I don't think it's like any other tool. It seems to fit in well with NOT using it, as well, or using it sometimes.
Yar
+1  A: 

Interface Builder is a great tool. Use it as much as you can.
When you can't do something using Interface Builder only, then it's time to write code that mix IBOutlets and code, or do it in code only.

Guillaume
+1  A: 

Interface Builder doesn't generate code, it merely creates an object graph of existing classes. If you look at nib file you can see this. Its just a list of rules for what objects to create and what relationships to set between them. There's no code in a nib and there is surprisingly very little code int the various loadFromNib methods.

It is the runtime coupling in Objective-c that makes all this possible. I don't any other language can really pull it off.

TechZen
Perhaps I'm wrong, but I think that even Java has Runtime coupling (via Reflection and dynamic invocation)... although there is no interface builder, it's theoretically possible in many languages. No?
Yar
Java was inspired in part by Objective-C so it come close but IIRC, Java has no counterpart to the "id" reference so its not as flexible as Objective-C in this regard. Every language has something it does better than others and runtime coupling is Objective-C forte.
TechZen