Cocoa without a Builder interface, initialize an application controller instance?

I do not plan to write applications without IB, I'm just trying to learn more about programming.

How can I get one instance of the AppController class at startup? (It usually loads from the tip.) And can you clear the use of +initialize and -init ? If I understand, +initialize is called for all classes at startup. How can I use this to instantiate my AppController with the instance variables that make up my interface?

Hope this makes sense and thanks for any help.

+4
objective-c xcode cocoa interface-builder
source share
3 answers

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

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

This alloc message calls initialize .

If you do the same with a subclass:

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

This alloc message will run +[YourClass initialize] just as the other did (before running +[SubclassOfYourClass initialize] . But only one of them will do this - each initialize class will never be called more than once. (If you don't call it yourself using [super initialize] or [SomeClass initialize] - do not do this because the method does not expect this.)

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

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

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

The details are different (this method or superclass or both can take arguments, and some prefer self = [super init] in their line, and Wil Shipley doesn't assign self at all ), but the main idea is the same: call [super init[WithSomething:…]] , make sure that he did not return nil , set up the instance if he did not, and return no matter what the superclass returned.

This means that you can return nil from init , and indeed you can. If you do this, you must [self release] so that you do not leak the damaged object. (To detect invalid argument values, an alternative is NSParameterAssert , which throws an exception if the statement fails. The relative merits of each of them are beyond the scope of this question.)

How can I use this to instantiate my AppController with the 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 will perform any other configuration in the application delegation methods in AppController .

You already know this, but for everyone who reads this: Nibs is your friend. Interface Builder is your friend. Do not fight with wireframe work with it and graphically create your interface, and your application will be better for him.

+7
source share

The NIB set seems like an unsatisfactory answer even if it is represented in XML (like XIB) because there is no easy way to compare or combine them with any standard disruptive tool or SCM style tool. The encoded information is fragile and not intended for editing by a simple person. How will the changes be presented in a graphical interface? Can I go through each attribute of each control and visually inspect them?

If the behavior of the application is written in code, however, there is a chance that I can understand what is happening, even if I need to keep a lot of details close at hand at the same time.

A suggested solution : use the top-level NIB, which is coded by the main architect, but then explicitly write down the rest of the application.

Has anyone got a better idea?

+1
source share

Another solution to the problem of launching the application without a tip.

Instead of allocating your own controller, simply use additional parameters in the NSApplicationMain() method:

 int retVal = NSApplicationMain(argc, argv, @"UIApplication", @"MyAppDelegate"); 

This applies to all the necessary links that you need.

Then the only thing you need to remember is to create your own window and set it to visible.

+1
source share

All Articles