The Root Class and Objective-C Objects

In a class hierarchy, a root class inherits from no other class and all other classes in the hierarchy ultimately inherit from it. NSObject is the root class of Objective-C class hierarchies. From NSObject, other classes inherit a basic interface to the Objective-C runtime system. And from NSObject, the instances of these classes derive their fundamental nature as Objective-C objects.

But by itself, an NSObject instance cannot do anything useful beyond being a simple object. To add any properties and logic specific to your program, you must create one or more classes inheriting from NSObject or from any other class that directly or indirectly inherits from NSObject.

NSObject adopts the NSObject protocol, which declares additional methods common to the interfaces of all objects. In addition, NSObject.h (the header file containing the class definition of NSObject) includes declarations of the NSCopying, NSMutableCopying, and NSCoding protocols. When a class adopts these protocols, it augments the basic object behaviors with object-copying and object-encoding capabilities. Model classes—those classes whose instances encapsulate application data and manage that data—frequently adopt the object-copying and object-encoding protocols.

The NSObject class and related protocols define methods for creating objects, for navigating the inheritance chain, for interrogating objects about their characteristics and capabilities, for comparing objects, and for copying and encoding objects. Much of the remainder of this article describes the basic requirements for most of these tasks.

Think in Terms of Objects

At runtime, an app is a network of cooperating objects; these objects communicate with each other to get the work of the app done. Each object plays a role, has at least one responsibility, and is connected to at least one other object. (An object in isolation is of little value.) As illustrated in the figure below, the objects in a network include both framework objects and application objects. Application objects are instances of a custom subclass, usually of a framework superclass. An object network is commonly known as an object graph.

You establish these connections, or relationships, between objects through references. There are many language forms of references, among them instance variables, global variables, and even (within a limited scope) local variables. Relationships can be one-to-one or one-to-many and can express notions of ownership or parent-child correspondence. They are a means for one object to access, communicate with, or control other objects. A referenced object becomes a natural receiver of messages.

Messages between objects in an app are critical to the functional coherence of the app. Like a musician in an orchestra, each object in an app has a role, a limited set of behaviors it contributes to the app. An object might display an oval surface that responds to taps, or it might manage a collection of data-bearing objects, or it might coordinate the major events in the life of the app. But for its contributions to be realized, it must be able to communicate them to other objects. It must be able to send messages to other objects in the app or be able to receive messages from other objects.

With strongly coupled objects—objects connected through direct references—sending messages is an easy matter. But for objects that are loosely coupled—that is, objects far apart in the object graph—an app has to look for some other communication approach. The Cocoa Touch and Cocoa frameworks feature many mechanisms and techniques enabling communication between loosely coupled objects (as illustrated in the figure below). These mechanisms and techniques, all based on design patterns (which you will learn more about later), make it possible to efficiently construct robust and extensible apps.

Create Objects

You usually create an object by allocating it and then initializing it. Although these are two discrete steps, they are closely linked. Many classes also let you create an object by calling a class factory method.

- (id)initFileURLWithPath:(NSString *)path isDirectory:(BOOL)isDir

NSURL *aURL = [[NSURL alloc] initFileURLWithPath:NSTemporaryDirectory() isDirectory:YES];

- (id)initWithFormat:(NSString *)format, ...;

+ (id)stringWithFormat:(NSString *)format, ...;

NSString *myString = [NSString stringWithFormat:@"Customer: %@", self.record.customerName];

Manage the Object Graph to Avoid Memory Leaks

The objects in an Objective-C program compose an object graph: a network of objects formed by each object’s relationships with—or references to—other objects. The references an object has are either one-to-one or (via collection objects) one-to-many. The object graph is important because it is a factor in the longevity of objects. The compiler examines the strength of references in an object graph and adds retain and release messages where appropriate.

You form references between objects through basic C and Objective-C constructs such as global variables, instance variables, and local variables. Each of these constructs carries with it an implied scope; for example, the scope of an object referenced by a local variable is the functional block in which it is declared. Just as important, references between objects are either strong or weak. A strong reference indicates ownership; the referring object owns the referenced object. A weak reference implies that the referring object does not own the referenced object. The lifetime of an object is determined by how many strong references there are to it. An object is not freed as long as there is a strong reference to it.

References in Objective-C are strong by default. Usually this is a good thing, enabling the compiler to manage the runtime life of objects so that objects are not freed while you’re using them. However, if you’re not careful, strong references between objects can form an unbroken chain of references, as illustrated on the left in the diagram below. With such an unbroken chain, it’s possible that the runtime will free none of the objects because there is a strong reference to each of them. Consequently, a strong reference cycle can cause your program to leak memory.

For the objects in the figure, if you break the reference between A and B, the subgraph consisting of B, C, D, and E lives on “forever” because these objects are bound together by a cycle of strong references. By introducing a weak reference from E to B, you break this strong reference cycle.

The fix for strong reference cycles is the judicious use of weak references. The runtime keeps track of both weak references and strong references to an object. After there are no strong references to an object, it frees that object and sets any weak references to the object to nil. For variables (global, instance, and local), use the __weak qualifier just before the variable name to mark the reference as weak. For properties, use the weak option. You should use weak references for the following kinds of references:

• Delegates

  @property(weak) id delegate;

  You will learn about delegates and targets in the Design Patterns article “Streamline Your App with Design Patterns.”

• Outlets that are not references to top-level objects

  @property(weak) IBOutlet NSString *theName;

  An outlet is a connection (or reference) between objects that is archived in a storyboard or nib file and restored when an app loads the storyboard or nib file. An outlet for a top-level object in a storyboard or nib file—typically a window, view, view controller, or other controller—should be strong (the default, so unmarked).

• Targets

  (void)setTarget:(id __weak)target

• References to self in blocks

  __block typeof(self) tmpSelf = self;

  [self methodThatTakesABlock:^ {

  [tmpSelf doSomething];

  }];

  A block forms a strong reference to variables it captures. If you use self within a block, the block forms a strong reference to self, so if self also has a strong reference to the block (which it typically does), a strong reference cycle results. To avoid the cycle, you need to create a weak (or __block) reference to self outside the block, as in the example above.

Manage Object Mutability

A mutable object is one whose state you can change after creating the object. You typically make changes through properties or accessor methods. An immutable object is one whose encapsulated state you cannot change after creating the object. The instances you’ll create of most classes of the Objective-C frameworks are mutable, yet a few are immutable. Immutable objects provide you with the following benefits:

• An immutable object won’t unexpectedly change in value while you’re using it.

• For many types of objects, application performance is improved if the object is immutable.

In Objective-C frameworks, the instances of immutable classes usually are ones that encapsulate collections of discrete or buffered values—for example, arrays and strings. These classes usually have mutable variants with “Mutable” in their names. For example, there is the NSString class (immutable) and the NSMutableString class. Note that some immutable objects that encapsulate discrete values, such as NSNumber or NSDate, do not have mutable class variants.

Use mutable objects instead of the immutable variant when you expect to change an object’s contents incrementally and frequently. If you receive an object from a framework that is typed as an immutable object, respect that return type; don’t attempt to change the object.

Create and Use Value Objects

A value object is an object that encapsulates a primitive value (of a C data type) and provides services related to that value. Value objects represent scalar types in object form. The Foundation framework provides you with the following classes that generate value objects for strings, binary data, dates and times, numbers, and other values:

• NSString and NSMutableString

• NSData and NSMutableData

• NSDate

• NSNumber

• NSValue

Value objects are important in Objective-C programming. You frequently encounter these objects as the parameters and return values of methods and functions that your application calls. By passing value objects, different parts of a framework or even different frameworks can exchange data. Because value objects represent scalar values, you can use them in collections and wherever else objects are required. But beyond their commonness and consequent necessity, value objects have an advantage over the primitive types they encapsulate: They enable you to perform certain operations on the encapsulated value in a simple yet efficient manner. The NSString class, for example, has methods for searching for and replacing substrings, for writing strings to files or (preferably) URLs, and for constructing file-system paths.

Sometimes you’ll find it more efficient and straightforward to use primitive types—that is, values typed as int (integer), float, and so on. A primary example of such a situation is computing a value. Consequently, NSNumber and NSValue objects are less commonly used as parameters and return values in framework methods. However, many of the frameworks declare their own numeric data types and use these types for parameters and return values; examples are NSInteger and CGFloat. You should use these framework-defined types where appropriate because they help you to abstract your code away from the underlying platform.

int n = 5; // Value assigned to primitive type

NSNumber *numberObject = [NSNumber numberWithInt:n]; // Value object created from primitive type

int y = [numberObject intValue]; // Encapsulated value obtained from value object (y == n)

NSURL *theURL = // Code that creates a file URL from a string path...

NSData *theData = [[NSData alloc] initWithContentsOfURL:theURL];

// use theData...

[theData writeToURL:theURL atomically:YES];

NSString *greeting = [[NSString alloc] initWithFormat:@"Hello, %@!", nameString];

// Create the string "My String" plus carriage return.

NSString *myString = @"My String\n";

// Create the formatted string "1 String".

NSString *anotherString = [NSString stringWithFormat:@"%d %@", 1, @"String"];

// Create an Objective-C string from a C string.

NSString *fromCString = [NSString stringWithCString:"A C string" encoding:NSASCIIStringEncoding];

NSNumber *myIntValue    = @32;

NSNumber *myDoubleValue = @3.22346432;

NSNumber *myBoolValue = @YES;

NSNumber *myCharValue = @'V';

NSNumber *myFloatValue = @3.2F

NSDate *now = [NSDate date]; // 1

NSCalendar *calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; // 2

[calendar setTimeZone:[NSTimeZone systemTimeZone]]; // 3

NSDateComponents *dc = [calendar components:(NSHourCalendarUnit|NSMinuteCalendarUnit|

    NSSecondCalendarUnit) fromDate:now];  // 4

NSLog(@"The time is %d:%d:%d", [dc hour], [dc minute], [dc second]); // 5

Create and Use Collections

A collection is an object that stores other objects in a certain way and allows clients to access those objects. You often pass collections as parameters of methods and functions, and you often obtain collections as return values of methods and functions. Collections frequently contain value objects, but they can contain any type of object. Most collections have strong references to the objects they contain.

The Foundation framework has several types of collections, but three of them are particularly important in Cocoa Touch and Cocoa programming: arrays, dictionaries, and sets. The classes for these collections come in immutable and mutable variants. Mutable collections permit you to add and remove objects, but immutable collections can contain only the objects they were created with. All collections allow you to enumerate their contents—in other words, to examine each of the contained objects in turn.

Different types of collections organize their contained objects in distinctive ways:

• NSArray and NSMutableArray — An array is an ordered collection of objects. You access an object by specifying its position (that is, its index) in the array. The first element in an array is at index 0 (zero).

• NSDictionary and NSMutableDictionary — A dictionary stores its entries as key-value pairs; the key is a unique identifier, usually a string, and the value is the object you want to store. You access this object by specifying the key.

• NSSet and NSMutableSet — A set stores an unordered collection of objects, with each object occurring only once. You generally access objects in the set by applying tests or filters to objects in the set.

Because of their storage, access, and performance characteristics, one type of collection can be better suited to a particular task than another one.

You can create arrays and dictionaries and access the values they contain either by calling methods of NSArray and NSDictionary or by using special Objective-C container literals and subscripting techniques. The following sections describe both approaches.

// Compose a static array of string objects

NSString *objs[3] = {@"One", @"Two", @"Three"};

// Create an array object with the static array

NSArray *arrayOne = [NSArray arrayWithObjects:objs count:3];

// Create an array with a nil-terminated list of objects

NSArray *arrayTwo = [[NSArray alloc] initWithObjects:@"One", @"Two", @"Three", nil];

NSArray *myArray = @[ @"Hello World", @67, [NSDate date] ];

NSString *theString = [arrayTwo objectAtIndex:1]; // returns second object in array

id theObject = myArray[1];

NSArray *myArray = // get array

for (NSString *cityName in myArray) {

    if ([cityName isEqualToString:@"Cupertino"]) {

        NSLog(@"We're near the mothership!");

        break;

    }

}

NSArray *myArray = // get array

[myArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {

    if ([obj isEqual:@"Cupertino"]) {

        NSLog(@"We're near the mothership!");

        *stop = YES;

    }

}];

NSMutableArray *myMutableArray = [NSMutableArray arrayWithCapacity:1];

NSDate *today = [NSDate date];

myMutableArray[0] = today;

// First create an array of keys and a complementary array of values

NSArray *keyArray = [NSArray arrayWithObjects:@"IssueDate", @"IssueName", @"IssueIcon", nil];

NSArray *valueArray = [NSArray arrayWithObjects:[NSDate date], @"Numerology Today",

    self.currentIssueIcon, nil];

// Create a dictionary, passing in the key array and value array

NSDictionary *dictionaryOne = [NSDictionary dictionaryWithObjects:valueArray forKeys:keyArray];

// Create a dictionary by alternating value and key and terminating with nil

NSDictionary *dictionaryTwo = [[NSDictionary alloc] initWithObjectsAndKeys:[NSDate date],

    @"IssueDate", @"Numerology Today", @"IssueName", self.currentIssueIcon, @"IssueIcon", nil];

NSDictionary *myDictionary = @{

   @"name" : NSUserName(),

   @"date" : [NSDate date],

   @"processInfo" : [NSProcessInfo processInfo]

};

NSDate *date = [dictionaryTwo objectForKey:@"IssueDate"];

NSString *theName = myDictionary[@"name"];

NSMutableDictionary *mutableDict = [[NSMutableDictionary alloc] init];

mutableDict[@"name"] = @"John Doe";

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {

    UITouch *theTouch = [touches anyObject];

    // handle the touch...

}

Verify Object Capabilities at Runtime

Introspection, a powerful and useful feature of Objective-C and the NSObject class, enables you to learn certain things about objects at runtime. You can thus avoid mistakes in your code such, as sending a message to an object that doesn’t recognize it or assuming that an object inherits from a given class when it doesn’t.

There are three important types of information that an object can divulge about itself at runtime:

• Whether it’s an instance of a particular class or subclass

• Whether it responds to a message

• Whether it conforms to a protocol

static int sum = 0;

for (id item in myArray) {

    if ([item isKindOfClass:[NSNumber class]]) {

        int i = (int)[item intValue];

        sum += i;

    }

}

if ([item respondsToSelector:@selector(setState:)]) {

    [item setState:[self.arcView.font isBold] ? NSOnState : NSOffState];

}

- (void) setDelegate:(id __weak) obj {

    NSParameterAssert([obj conformsToProtocol:

        @protocol(SubviewTableViewControllerDataSourceProtocol)]);

    delegate = obj;

}

Compare Objects

You can compare two objects by using the isEqual: method. The object receiving the message is compared to the passed-in object; if they’re the same, the method returns YES. For example:

BOOL objectsAreEqual = [obj1 isEqual:obj2];

if (objectsAreEqual) {

    // do something...

}

Note that object equality is different from object identity. For the latter, use the equality operator == to test whether two variables point to the same instance.

What is compared when you compare two objects of the same class? That depends on the class. The root class, NSObject, uses pointer equality as the basis of comparison. Subclasses at any level can override their superclass’s implementation to base the comparison on class-specific criteria, such as object state. For example, a hypothetical Person object might equal another Person object if the first-name, last-name, and birth-date attributes of both objects match.

The value and collection classes of the Foundation framework declare comparison methods of the form isEqualToType:, where Type is the class type minus the NS prefix—for example, isEqualToString: and isEqualToDictionary:. The comparison methods assume that the passed-in object is of the given type and raise an exception if it is not.

Copy Objects

You make a copy of an object by sending a copy message to it.

NSArray *myArray = [yourArray copy];

To be copied, the class of the receiving object must conform to the NSCopying protocol. If you want your objects to be copyable, you must adopt and implement the copy method of this protocol.

You sometimes copy an object obtained from elsewhere in a program when you want to ensure the object’s state does not change while you’re using it.

Copying behavior is specific to a class and depends upon the specific nature of the instance. Most classes implement deep copying, which makes a duplicate of all instance variables and properties; some classes (for example, the collection classes) implement shallow copying, which only duplicates the references to those instance variables and properties.

Classes that have mutable and immutable variants also declare a mutableCopy method to create a mutable copy of an object. For example, if you call mutableCopy on an NSString object, you get an instance of NSMutableString.