Re: Interface Builder popularity w/ Cocoa Developers
Re: Interface Builder popularity w/ Cocoa Developers
- Subject: Re: Interface Builder popularity w/ Cocoa Developers
- From: Andy Lee <email@hidden>
- Date: Sun, 15 Jun 2008 23:27:08 -0400
On Jun 15, 2008, at 10:50 PM, Damon Allison wrote:
I'm trying to get a feel for the popularity of IB in [*] and cocoa
development. Is IB heavily used in [*]/cocoa development? Do large
cocoa projects use IB?
Yes.
In many other environments IDE builder tools generate sloppy code or
hide internal complexities from the developer which ultimately make
debugging difficult. Many times developers prefer to bypass the
tools and just "code it myself". Is that a common practice with IB?
No. Using IB rather than the "code it myself" approach is by far the
path of least resistance, and the most common and sensible approach.
It's important to understand that IB is not a code generator. And
although it's used for laying out user interfaces, it's best
understood not as a screen painter but as an _object editor_. A
window, for example, is an object -- an instance of NSWindow -- so
when you lay out a window in IB you are setting object attributes and
connections. You can also instantiate objects that are not UI objects.
There was a long thread about bypassing IB not long ago. Rather than
embarrass myself by beating that horse again, I'll repost an
explanation that a couple of people found helpful:
A nib file contains descriptions of a set of objects:
(1a) what class each object is an instance of,
(1b) values for each object's attributes, and
(1c) how the objects connect to each other (through instance
variables called outlets).
When you edit a nib file in IB, you're specifying:
(2a) what objects should be in the nib (by dragging them from a
palette that lists the classes you want),
(2b) what values their attributes should have (by entering values in
an inspector), and
(2c) how they connect to each other (by control-dragging between
them and selecting which outlet of the from-object you want the to-
object to be).
When your application *loads* a nib, it:
(3a) instantiates the objects,
(3b) sets their attributes, and
(3c) connects them both to each other and to certain things in your
application (in particular, File's Owner, which you should
definitely understand).
As others have explained, IB does not generate code to do (3a),
(3b), and (3c). That's all taken care of by the Cocoa framework
code that loads the nib file.
[...]
The "behind the scenes" of (3a), (3b), and (3c) are documented and
worth understanding; they touch on topics including init methods,
KVC, and the responder chain respectively. To be honest I can't
recite all the details offhand (like the exact rules for which init
method gets called), but I'm aware of the situations in which I
should refer to the documentation.
--Andy
[*] Note that we're not supposed to talk about iPhone development.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden