views:

2268

answers:

2

I don't plan to write applications without IB, I'm just in the process of trying to learn more about programming.

How can I get a single instance of my AppController class at startup? (It's normally loaded from the nib.) And can you clear up the use of +initialize and -init? If I understand, +initialize is called on all classes at startup. How can I use this to create an instance of my AppController with instance variables that make up my interface?

Hope that makes sense, and thanks for any help.

+4  A: 

+initalize is sent to a class the first time it or one of its subclasses receives a message for the first time. So, when you do:

instance = [[[YourClass alloc] init] autorelease];

That alloc message triggers initialize.

If you do the same thing with a subclass:

instance = [[[SubclassOfYourClass alloc] init] autorelease];

That alloc message will trigger +[YourClass initialize] the same way the other one did (prior to also triggering +[SubclassOfYourClass initialize]. But only one of these will do it—each class's initialize never gets called more than once. (Unless you call it yourself with [super initialize] or [SomeClass initialize]—so don't do that, because the method won't be expecting it.)

-init, on the other hand, initializes a new instance. In the expression [[YourClass alloc] init], you are personally sending the message directly to the instance. You may also call it indirectly, through another initializer ([[YourClass alloc] initWithSomethingElse:bar]) or a convenience factory ([YourClass instance]).

Unlike initialize, you should always send init (or another initializer, if appropriate) to your superclass. Most init methods look roughly like this:

- (id) init {
 if ((self = [super init])) {
  framistan = [[Framistan alloc] init];
 }
 return self;
}

Details differ (this method or the superclass's or both may take arguments, and some people prefer self = [super init] on its own line, and Wil Shipley doesn't assign to self at all), but the basic idea is the same: call [super init[WithSomething:…]], make sure it didn't return nil, set up the instance if it didn't, and return whatever the superclass returned.

This implies that you can return nil from init, and indeed you can. If you do this, you should [self release], so that you don't leak the failed object. (There are few reasons to do this, however. For detecting invalid argument values, you should use NSParameterAssert instead.)

How can I use this to create an instance of my AppController with instance variables that make up my interface?

The best way is to do it all in main:

int main(int argc, char **argv) {
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

 AppController *controller = [[[AppController alloc] init] autorelease];
 [[NSApplication sharedApplication] setDelegate:controller]; //Assuming you want it as your app delegate, which is likely
 int status = NSApplicationMain(argc, argv);

 [pool drain];
 return status;
}

You'll do any other set-up in your application delegate methods in AppController.

You already know this, but for anyone else who reads this: Nibs are your friend. Interface Builder is your friend. Don't fight the framework—work with it, and build your interface graphically, and your application will be better for it.

Peter Hosey
Thanks a ton, that helped, but it looks like IB does quite a bit. I made a method in AppController called load interface, and called it in main.AppController *controller = [...][controller loadInterface];When I try to assign a value to my controller variable mainWindow, (continue comment)...
I get console errors:_NXCreateWindow: error setting window property (1002) _NSSetWindowTag, error clearing window tags (1002)_NSSetWindowTag, error setting window tags (1002)Can this be fixed?
You need to have NSApplication running before you can create windows. That's why it's better to make your controller the app delegate and create/load windows in your delegate methods. (Note that command-line apps *can't* create windows, because they haven't run NSApplication yet and never will.)
Peter Hosey
Awesome! I got it to work! Thanks again
+1  A: 

A set of NIBs seem to be an unsatisfactory answer, even when represented in XML (as a XIB), because there's no easy way to compare or merge them with any standard subversion or SCM-style tool. The encoded information is fragile and not intended to be edited by mere humans. How would changes be represented by a GUI? Would I step through each attribute of each control and visually check them?

If the app's behavior is written in code, however, there is a chance that I can figure out what's going in, even if I have to keep lots of details close at hand at the same time.

A proposed solution: use a top-level NIB that the main architect coded up, but then code the rest of the app explicitly.

Anybody got a better idea?

greggT