I am extremely impressed with the quality of the responses, thank you. The iPhone NDA duly noted and I apologize.
After reading the archives (thanks Andy Lee), it seems this has been a long fought battle. One which I don't want to refight. I need to do my homework. Now that I understand IB is by far the preferred method of UI development, my syllabus is set. Thank you.
IB creates NIB's, what are commonly referred to as "freeze dried objects" and not code. They have been doing this ever since the early 1990s in the NeXT days. It is different than automatic code generation.
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.
A code gen file contains descriptions of a set of objects:
(1a) what classes each object is an instance of, (1b) values for each object's attributes, and (1c) how the objects connect to each other (through object references)
When you edit a code gen file with the UI editor, you're specifying:
(2a) what objects should be in the UI (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 connecting the objects via the UI builder interface)
When your application *loads* a code gen file, it:
(3a) instantiates the objects, (3b) sets their attributes, and (3c) connects them both to each other and to do certain things in your applications
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.
Damon
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).
|