Re: Interface Builder popularity w/ Cocoa Developers
Re: Interface Builder popularity w/ Cocoa Developers
- Subject: Re: Interface Builder popularity w/ Cocoa Developers
- From: "Jack Nutting" <email@hidden>
- Date: Mon, 16 Jun 2008 11:04:07 +0200
On Mon, Jun 16, 2008 at 6:57 AM, Damon Allison <email@hidden> wrote:
> So IB uses a persisted/reloaded object graph. A codegen based tool uses
> code. Ultimately with either approach, you end up with a set of UI objects.
> The difference between the two approaches seems to be the visibility into
> the creating/reloading process. My thought process is that with code, I can
> clearly see the graph and watch it during the rebuild. By attaching a
> debugger, I could have better success in finding missing connections or
> whatever is causing the problem. Loading a nib seems to be a more generic
> object hydration process and perhaps tougher to debug. That's my initial
> assessment, which will undoubtably change after some research into nib
> creation/loading.
For the most part, the basics of nib-loading are so mature that
there's rarely a problem in practice. Each object in the nib is
created and initialized (in no particular order), their attributes are
set and their connections are established, and then each is sent
-awakeFromNib (again in no particular order). As long as you
understand that ordering, and defer most of your initiallization (in
particular anything that needs to use a connection to another object)
until awakeFromNib, it is generally a smooth ride.
The notable exception to this is the Bindings system, which can crash
when loading a nib for a variety of reasons. The good news is that
the crashing is usually quite consistent, so you'll probably discover
that there's a problem the first time you load the nib in a running
app; The bad news is that these crashes can be tricky to track down
in a systematic way (I usually find myself reverting to a known good
state, then retracing my edits one at a time, each time re-running the
app, until I make it crash again, at which point I can hopefully
figure out just what went wrong). This seems to have improved
somewhat since bindings were introduced, but is still a source of pain
at times. Some people apparently set up their bindings in code
instead, possibly to avoid this headache.
I'd like to point out another problem with the code-generation
approach, related to what Greg pointed out, about the
viability/usefulness of the generated code. With code-generation, if
you have some special tweak for your GUI that cannot be done with your
layout tool, it may be tempting to put those modifications into the
generated code (indeed, in some systems it may be the *only* option)
instead of in a separate file. Doing so puts you at the risk of
either making the generated code unparsible by the tool (if the tool
tries to read it back in), or more likely having your changes wiped
out the next time the tool generates the code. With the archived
object graph approach, any tweaking that cannot be done with IB is
done (can *only* be done) in external code that doesn't affect the
archive itself, just changes the graph in-memory after it is loaded,
so the archive and the tweaking are insulated from changes in each
other.
--
// jack
// http://www.nuthole.com
_______________________________________________
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