Re: Need an alternative to Interface Builder for a good reason
Re: Need an alternative to Interface Builder for a good reason
- Subject: Re: Need an alternative to Interface Builder for a good reason
- From: John Stiles <email@hidden>
- Date: Sun, 12 Aug 2007 12:46:48 -0700
If you're going to use XML, why not try to figure out IB's XML and
then write code to just interpret the XML that comes out of IB?
Honestly if I were going to develop a cross-platform app, that would
be one of the first things I tried.
On Aug 12, 2007, at 12:15 PM, Chris Hanson wrote:
On Aug 12, 2007, at 9:27 AM, j o a r wrote:
You said:
I understand that there is a method by which interfaces can be
built out of Cocoa objects with Java, but I can't find
documentation on exactly how to do this, and the one person I've
corresponded about it has told me it is rather cumbersome. The
impression I've gotten is that it is sort of a dirty way just to
get the job done, and is neither efficient nor condusive to
productivity.
You can of course always fall back to creating your interface
objects in code instead of using Interface Builder. The only
drawback with this is that something simple as for example adding
a button to a window involves more lines of code than most people
might expect. No need to involve Java.
As Joar says, it may require more lines of code than many people
expect to instantiate and configure controls. However, it's fairly
straightforward and well-explained in the documentation. For
example, the NSView designated initializer is -initWithFrame:
meaning that if you want to create a 50x60 view that will be
located at point (10,20) in its superview, you just need to write
MyView *subview = [[MyView alloc] initWithFrame:NSMakeRect
(10,20,50,60)];
[superview addSubview:subview];
[subview release];
Since NSControl is a subclass of NSView, most controls also use -
initWithFrame: as their designated initializer. However, there's
typically more setup involved in getting the look and feel of a
control exactly right. For example, an NSButton isn't an Aqua-
style pushbutton when instantiated; it needs a number of properties
specified to appear as one.
That said, if you find yourself writing a lot of repetitive code to
do this kind of setup, it might be easy to create a simple XML
format describing your interfaces. Then you could use either
NSXMLParser or NSXMLDocument to read and instantiate your
interfaces. This won't let you use Interface Builder, but it will
let you maintain most of the benefits of declarative user
interfaces, while also maintaining the benefits of a textual format.
You may also find my weblog posts on test-driven development of
Cocoa UI useful:
http://chanson.livejournal.com/118380.html
http://chanson.livejournal.com/148204.html
http://chanson.livejournal.com/172390.html
After all, if your tests are sufficiently complete, it shouldn't
matter whether you make your tests pass by manipulating a nib or by
writing code; the interface the user works with should be the same.
Hope this helps!
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden