On Apr 26, 2010, at 8:15 AM, ML wrote:
>
> How about a good book that explains what IB does, how to set delegates, first
> responders, connect things up, etc
Here is an example of making a (simple) iPhone project all in code:
http://www.trilithon.com/download/CodeOnly.zip
There is a Cocoa Resource Programming Gude that covers Interface Builder issues.
Setting delegates is done i the same way as making connections between any
other pair of
objects. You control-drag a connection from the object that should have the
reference (pointer)
to the object being referenced ( pointed at).
In general, you hardly ever need to play with the responder chain.
Connecting things together is as I described above in the context of delegates.
> I think that misunderstanding prevents me from using IB as much as I really
> should.
An Interface Builder document (xib/nib) is simply a box full of serialised
(freeze-dried, pickled, embalmed, archived, choose your metaphor)
objects, with connections between them in such a way that they (should, at
least) form a complete object graph.
Objects in the XIB and on the design surface during design and construction
time are live objects,
exactly the same as if you had created them programatically. When you change
attributes using
Interface Builder's Attributes Inspector, Interface Builder is sending messages
to those objects, just
as if you had programatically sent those messages from code. So in the end,
there is nothing really magic
about Interface Builder.
At application run time, when the time comes to load the NIB using the Bundle
Loader, the
important tasks that the loading process performs are (1) unarchiving the
archived objects into memory
to form an object graph, and (2) using the information provided in File's Owner
plus the already instantiated
'owner' object in the existing application's object graph to join the two
object graphs together.
There are various (opinionated) factions on the subject of whether or not to
use Interface Builder.
The choice is entirely yours.
That said, if and when the time cones to locali[sz]e your application, you will
suddenly discover that
Interface Builder can and will save you tons of otherwise laborious drudge work.
I live to a certain degree in both camps. Doing a iPhone Tab Bar application
via Interface Builder
I find to be laborious, error-prone, and klunky. But instead of writing
loads of code, I write an XML
description of the starting architecture in a plist, and dynamically
instantiate everything at launch time
in a fairly compact loop.
In applications where I need a lot of fiddly and finicky layout, I use
Interface Builder for what it's good at.
Cheers,
. . . . . . . . Henry
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
