Re: Interface Builder popularity w/ Cocoa Developers
Re: Interface Builder popularity w/ Cocoa Developers
- Subject: Re: Interface Builder popularity w/ Cocoa Developers
- From: Greg Guerin <email@hidden>
- Date: Sun, 15 Jun 2008 23:42:22 -0700
Damon Allison wrote:
It is only with very a very kind spirit I would like to note that
everything said below about IB can be said for codegen UI tools.
So even though the process is different, the ultimate outcome of
having an object model is consistent between both approaches.
I can think of one major difference: UI editing after the fact.
A nib embedded in a shippable app-bundle is "just data". It is also
the SAME data that IB operates on. That nib can be edited at any
later date using IB, without changing or recompiling any of the
program's code. As long as the edits don't change something
fundamental, the existing program wouldn't care. It might not even
be able to detect a difference: a don't-care difference. For
example, it might not know or care about colors of some elements,
whether there are static boxes or lines, or whether a list is located
on the top and scrolls horizontally or on the side and scrolls
vertically.
Codegen, however, is code. That means a change to anything in the
layout requires regenerating code, which is then recompiled. There
may be a "just data" representation somewhere, such as an object
graph used by the layout editor, but that representation is typically
not distributed with the final app. As a result, neither users nor
anyone else can change the GUI after the fact. For better or for worse.
In essence, nib files directly encapsulate or modularize the
contained components. There is no intermediate "codegen" or
"compilation" tool used. The same nib file is used by both IB during
editing and by the actual program at runtime.
To some extent this modularity isolates the GUI components from the
program (the actual code), except for a limited number of contact
points, such as IBOutlets, actions, and tags associated with some
elements. The degree of isolation depends entirely on how the
interfaces or contact points between the code and the object graph
are designed. You get as much or as little coupling or cohesion as
you care to design in.
If you wanted to do something like that with codegen, you'd have to
ship a regenerator tool, and you'd have to distribute the original
object graph representations of the GUI layouts, or whatever the
codegen or IDE uses as "source" for the layouts. I think the codegen
equivalent might be like "level builders" for some games. The data
the builder operates on may or may not be what the game itself consumes.
I'm not saying one approach is necessarily better or worse than the
other, just that I can see differences. For example, you might not
want users fiddling with layouts and breaking things. Or you might
want to allow fiddling without having to write your own separate
level-builder tool. Or as you said, your thought process works more
naturally by visualizing code.
-- GG
_______________________________________________
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