Re: Interface Builder popularity w/ Cocoa Developers
Re: Interface Builder popularity w/ Cocoa Developers
- Subject: Re: Interface Builder popularity w/ Cocoa Developers
- From: Jim Witte <email@hidden>
- Date: Sun, 15 Jun 2008 23:52: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 iPhone and
cocoa development. Is IB heavily used in iP/cocoa development? Do
large cocoa projects use IB?
Yes. Aaron Hillegass, the author of "Cocoa Programming for Mac OS
X" says in an interview that one of the things that new OSX
developers from other platforms/OS's (including earlier MacOS) seem
to "fear" is IB, asking "can't I make the interface with some code?"
and such. I have noticed this myself - and I started (a long time
ago, and I haven't been programming for a while since) with
Hypercard, which is a lot like IB in that you graphically lay out the
interface before putting in "the code"
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?
IB isn't really an IDE code "builder" like the old AppMaker was in
which you lay out the interface and it writes all the code to make
the interface work. After you create an interface in IB, you can run
the application without ANY compilation to speak of. As for hidden
internal complexities - if there are bugs, they are bugs in the Cocoa
classes themselves, and thus affect ANYTHING in the OS that uses them
- it isn't a matter of a bug being in only your application or such.
You can "code it yourself" to some degree using Carbon (at least I
think you still can, although Apple seems to be moving away from
Carbon UI development if they haven't already done so - this is why
Adobe Photoshop won't be updated for Leopard in the next version).
The general consensus is that it's just not worth it to do so unless
you have a strong background (or are porting) "Classic" MacOS apps
that use the toolbox and such to make the interface that way. Even
if you do have a strong background, it isn't worth it.
Hillegass gives an example about the one-time Apple/IBM Taligent
venture, where he went to a demo and saw a person who was showing how
to make a simple app that would output a string to a text field when
a button was clicked. He left after 20 minutes, and the app still
wasn't done. He said, "I knew then that Taligent was doomed. Two
years later, it closed it's doors for good" If Cocoa, making that
would be about a 30 seconds to lay out the stuff in IB, and another
10 to write the code to put the string in the textfield.
"Cocoa Programming" is a great book for learning how to use IB
effectively. Especially impressive is when you put together a car
database application using CoreData and bindings that HAS NO CODE AT
ALL!!. Get the third edition as it's specific for Xcode 3 and
Leopard (although the basic concepts apply to Panther and Xcode 2,
the look of IB has changed from Xcode 2 to 3). About the only thing
you miss is the chapter on IB palette development, but the palette
interface has changed A LOT between Xcode 2 and 3 - this is one of my
grips with it - that it doesn't update that chapter (though perhaps
the new palette interface is not all that difficult once you've gone
through the rest of the book!)
I do hope I got the capitalization of 'Xcode' right.. :) Shouldn't
it actually be 'xCode' though in keeping with the Cocoa convention of
starting variable and method names with lowercase, and up-casing
following words? There's a message in the archive somewhere I spent
*far* too long looking for..
Jim Witte
_______________________________________________
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