• Choose a category
• All
• Classic-Fiction

Methods for reading the defaults. If the user hasn’t changed them, the factory defaults are returned.

- (void)removeObjectForKey:(NSString *)defaultName

Removes the user’s preference, so the application will return to using the factory defaults.

Precedence of Types of Defaults

So far, we have talked about two levels of precedence: What the user writes to his or her defaults database overrides the factory defaults. In fact, several more levels of precedence exist. These levels of default settings are known as domains. Here are the domains used by an application, from highest to lowest priority:

Arguments: Passed on the command line. Most people start their applications by double-clicking on an icon instead of by working from the command line, so this feature is seldom used in a production app.

Application: What comes from the user’s defaults database.

Global: What the user has set for his or her entire system.

Language: What is set based on the user’s preferred language.

Registered defaults: The factory defaults for the app.

Setting Defaults

The Identifier for the Application

What is the plist file in ~/Library/Preferences created for this application called? By default, it uses the identifier of the application that created it. You set this identifier in Chapter 10 to be com.bignerdranch.RaiseMan, so the filename will be com.bignerdranch.RaiseMan.plist.

Create Keys for the Names of the Defaults

You will be registering, reading, and setting defaults in several classes in your application. To make sure that you always use the same name, you should declare those strings in a single file and then simply #import that file into any file where you use the names.

There are several ways to do this (for example, you could use the C preprocessor’s #define command), but most Cocoa programers use global variables for this purpose. Add the following lines to your PreferenceController.h file after the #import statement:

extern NSString * const BNRTableBgColorKey;

extern NSString * const BNREmptyDocKey;

Now define these variables in PreferenceController.m. Put them after the #import lines but before @implementation:

NSString * const BNRTableBgColorKey = @"BNRTableBackgroundColor";

NSString * const BNREmptyDocKey = @"BNREmptyDocumentFlag";

Why would we declare global variables that simply contain a constant string? After all, you could just remember what the string was and type it in whenever you need it. The problem is that you might misspell the string. If the string is surrounded by quotes, the compiler will accept the misspelled string. In contrast, if you misspell the name of a global variable, the compiler will catch your error.

To keep the global variables from conflicting with another company’s global variables, you have prefixed them with BNR (for Big Nerd Ranch). Global variables from Cocoa are prefixed with NS. These prefixes are important only when you start using classes and frameworks developed by third parties. (Note that class names are also global. You might prefer to prefix all your class names with BNR to keep them from conflicting with anyone else’s classes.)

Register Defaults

Each class is sent the message initialize before any other message. To ensure that your defaults are registered early, you will override initialize in AppController.m:

+ (void)initialize

{

// Create a dictionary

NSMutableDictionary *defaultValues = [NSMutableDictionary dictionary];

// Archive the color object

NSData *colorAsData = [NSKeyedArchiver archivedDataWithRootObject:

[NSColor yellowColor]];

// Put defaults in the dictionary

[defaultValues setObject:colorAsData forKey:BNRTableBgColorKey];

[defaultValues setObject:[NSNumber numberWithBool:YES]

forKey:BNREmptyDocKey];

// Register the dictionary of defaults

[[NSUserDefaults standardUserDefaults]

registerDefaults: defaultValues];

NSLog(@"registered defaults: %@", defaultValues);

}

This is a class method; that is why its declaration is prefixed with a +.

Note that