Return to the Alphabetic Index
Return to the Class Browser
Return to the Picture Browser
Copyright (c) 1994 by NeXT Computer, Inc. All Rights Reserved.


Inherits From: NSResponder : NSObject

Conforms To: NSCoding (NSResponder) NSObject (NSObject)

Declared In: AppKit/NSApplication.h





Class Description

The NSApplication class provides the central framework of your application's execution. Every application must have exactly one instance of NSApplication (or of a custom subclass of NSApplication). Your program's main() function should create this instance by calling the sharedApplication class method. (Alternatively, you could use alloc and init, making sure they're called only once.) After creating the NSApplication, the main() function should load your application's main nib file, and then start the event loop by sending the NSApplication a run message. Here's an example of a typical OpenStep main() function in its entirety:

void main(int argc, char *argv[]) {

NSApplication *app = [NSApplication sharedApplication];

[NSBundle loadNibNamed:@"myMain" owner:app];

[app run];


Creating the NSApplication object connects the program to the window system and the Display PostScript server, and initializes its PostScript environment. The NSApplication object maintains a list of all the NSWindows that the application uses, so it can retrieve any of the application's NSViews.

The NSApplication object's main task is to receive events from the window system and distribute them to the proper NSResponders. The NSApplication translates an event into an NSEvent object, then forwards the NSEvent to the affected NSWindow object. A key-down event that occurs while the Command key is pressed results in a commandKey: message, and every NSWindow has an opportunity to respond to it. Other keyboard and mouse events are sent to the NSWindow associated with the event; the NSWindow then distributes these NSEvents to the objects in its view hierarchy.

In general, it's neater and cleaner to separate the code that embodies your program's functionality into a number of custom objects. Usually those custom objects are subclasses of NSObject. Methods defined in your custom objects can be invoked from a small dispatcher object without being closely tied to the NSApplication object. It's rarely necessary to create a custom subclass of NSApplication. You will need to do so only if you need to provide your own special response to messages that are routinely sent to the NSApplication object. To use a custom subclass of NSApplication, simply substitute it for NSApplication in the main() function above.

When you create an instance of NSApplication (or of a custom subclass of NSApplication), it gets stored as the global variable NSApp. Although this global variable isn't used in the example main() function above, you might find it convenient to refer to NSApp within the source code for your application's custom objects. Note that you can also retrieve the NSApplication object by invoking sharedApplication.

The NSApplication class sets up autorelease pools during initialization and during the event loopthat is, within its init (or sharedApplication) and run methods. Similarly, the methods that the Application Kit adds to NSBundle employ autorelease pools during the loading of nib files. The autorelease pools aren't accessible outside the scope of the respective NSApplication and NSBundle methods. This isn't usually a problem, because a typical OpenStep application instantiates its objects by loading nib files (and by having the objects from the nib file create other objects during initialization and during the event loop). However, if you do need to use OpenStep classes within the main() function itself (other than to invoke the methods just mentioned), you should instantiate an autorelease pool before using the classes, and then release the pool once you're done. For more information, see the description of the NSAutoreleasePool class in the Foundation Kit.

The Delegate and Observers

The NSApplication object can be assigned a delegate that responds on behalf of the NSApplication to certain messages addressed to the NSApplication object. Some of these messages, such as application:openFile:withType:, ask the delegate to open a file. Another message, applicationShouldTerminate:, lets the delegate determine whether the application should be allowed to quit.

An NSApplication can also have observers. Observers receive notifications of changes in the NSApplication, but they don't have the unique responsibility that a delegate has. Any instance of a class that implements an observer method can register to receive the corresponding notification. For example, if a class implements applicationDidFinishLaunching: and registers to receive the corresponding notification, instances of this class are given an opportunity to react after the NSApplication has been initialized. (The observer methods are listed later in this class specification. For information about how to register to receive notifications, see the class specification for the Foundation Kit's NSNotificationCenter class.)

There can be only one delegate, but there can be many observers. The delegate itself can be an observerin fact, in many applications the delegate might be the only observer. Whereas most observers need to explicitly register with an NSNotificationCenter before they can receive a particular notification message, the delegate need only implement the method. By simply implementing an observer method, the NSApplication's delegate is automatically registered to receive the corresponding notification.

Creating and Initializing the NSApplication

Changing the Active Application

Running the Event Loop

Getting, Removing, and Posting Events

Sending Action Messages

Setting the Application's Icon

Hiding All Windows

Managing Windows

Showing Standard Panels

Getting the Main Menu

Managing the Windows Menu

Managing the Services menu

Getting the Display PostScript Context

Reporting an Exception

Terminating the Application

Assigning a Delegate

Implemented by the Delegate