I've heard its simply a question of preference. But there must be advantages to adding views programmatically. Any experienced Xcoders care to comment?
views:
63answers:
3
+1
A:
There is no advantage to doing something in code that you can do in IB. It's just a bad habit that people bring with them from other platforms.
NSResponder
2010-05-19 02:15:39
A:
It's important to point out, that for very specific things, it can be very useful to "program a view" if you want specific behavior, etc.
So I wouldn't drop the idea, still I recommend to go with Interface Builder for most of the stuff you're going to develop, it will save you writing lot's of code lines + Time.
Mr.Gando
2010-05-19 02:20:54
A:
It will be a lot easier to do via code when adding a lot of similar UI elements.
A side benefit is I can understand what is really going on. Charles Petzold once said he won't write a C# book if he cannot do all via code. I think some programmers just don't like the automatic feeling of generated code. It's not saying IB is not good for programmers, it's only not good for understanding the nuts and bolts. That's also one reason why many programmers love Delphi (and the IDE).
ohho
2010-05-19 02:25:18
IB doesn't do code generation — it creates the objects and serializes them. You can't get source code out of it because it doesn't create any.
Chuck
2010-05-19 02:48:40
@Chuck ... only if you do not consider `xml` is _code_.
ohho
2010-05-19 03:15:48
The XML is just serialized object graph. Unless you consider every persistence library in the world to be a code generation tool, I don't see the relevance. What IB does is quite different from what most GUI builders do.
Chuck
2010-05-19 03:28:50
Let's use an example. Open any .xib and search for `<bytes key="NSRGB">`. Is it easier for a newbie iPhone programmer to understand this or the `.currentTitleColor` API? A "serialized object graph" may be human-readable, but it's too difficult for a newbie to create one. I don't mean create UI elements is easier via coding. What I mean is coding is a learning process. After getting that confidence of understanding how the underlying stuff work, using IB is a joy. Then we happily use `initWithNibName:`.
ohho
2010-05-19 03:49:30
This "the code is what's really going on" thing is a pet peeve of mine. Here's how I think of it (and I'm in the Cocoa group at apple): What's "really going on" is the in memory state of an object. In IB, you manipulate that state by sending messages to the objects in your window via the controls IB provides. Then those objects save themselves, and are restored on app launch. Code is another way of manipulating on object, not the "truth". If you want to "really know" a person, do you want a transcript of every interaction they've had with their environs? That's like code. It's indirect.
Ken
2010-05-19 04:37:45
And right, the archived nib is not human readable. It's the saved state of the object. No one's business but the object itself. If you want to understand the object, open the nib and look at it in IB. If you want to understand a word document, do you look at it in a hex editor?
Ken
2010-05-19 05:44:14
IB is the way to go data driven for GUI creation using XML. It's totally data driven IMHO, nothing to do with straight "compiled" code.
Mr.Gando
2010-05-19 08:55:59
Even the XML thing is somewhat misleading… it was opaque binary data until IB version 3.0. It's only XML for the sake of version control tools, which are text oriented. Interface builder doesn't understand that XML, it's only the classes themselves that know how to save and restore their state. This is called the memento pattern in the gang of four book.
Ken
2010-05-19 10:05:31