iOS Programming: The Big Nerd Ranch Guide, 3/e (Big Nerd Ranch Guides) by Aaron Hillegass, Joe Conway Page B
Authors: Aaron Hillegass, Joe Conway
Ads: Link
calculator automatically sets its container instance variable to nil . In main.m , make the following changes to see this happen.
NSMutableArray *items = [[NSMutableArray alloc] init];
BNRItem *backpack = [[BNRItem alloc] init];
[backpack setItemName:@"Backpack"];
[items addObject:backpack];
BNRItem *calculator = [[BNRItem alloc] init];
[calculator setItemName:@"Calculator"];
[items addObject:calculator];
[backpack setContainedItem:calculator];
NSLog(@"Setting items to nil...");
items = nil;
backpack = nil;
NSLog(@"Container: %@", [calculator container]);
calculator = nil;
Build and run the application. Notice that after the backpack is destroyed, the calculator reports that it has no container without any additional work on our part.
A variable can also be declared using the __unsafe_unretained attribute. Like a weak reference, an unsafe unretained reference does not take ownership of the object it points to. Unlike a weak reference, an unsafe unretained reference is not automatically set to nil when the object it points to is destroyed. This makes unsafe unretained variables, well, unsafe. To see an example, change container to be unsafe unretained in BNRItem.h .
__unsafe_unretained BNRItem *container;
Build and run the application. It will most likely crash. The reason? When the calculator was asked for its container within the NSLog function call, it obligingly returned its value – the address in memory where the non-existent backpack used to live. Sending a message to a non-existent object resulted in a crash. Oops.
As a novice iOS programmer, you won’t use __unsafe_unretained . As an experienced programmer, you probably won’t use it, either. It exists primarily for backwards compatibility: applications prior to iOS 5 could not use weak references, so to have similar behavior, they must use __unsafe_unretained .
Be safe. Change this variable back to __weak .
__weak BNRItem *container;
Here’s the current diagram of RandomPossessions . Notice that the arrow representing the container pointer variable is now a dotted line. A dotted line denotes a weak (or unsafe unretained reference). Strong references are always solid lines.
Figure 3.9 RandomPossessions with retain cycle avoided
Properties
Each time we’ve added an instance variable to BNRItem , we’ve declared and implemented a pair of accessor methods. Now we’re going to see how to use properties instead. Properties are a convenient alternative to writing out accessors for instance variables – one that saves a lot of typing and makes your class files much clearer to read.
Declaring properties
A property is declared in the interface of a class where methods are declared. A property declaration has the following form:
@property NSString *itemName;
When you declare a property, you are implicitly declaring a setter and a getter for the instance variable of the same name. So the above line of code is equivalent to the following:
- (void)setItemName:(NSString *)str;
- (NSString *)itemName;
Each property has a set of attributes that describe the behavior of the accessor methods. The attributes are declared in parentheses after the @property directive. Here is an example:
@property (nonatomic, readwrite, strong) NSString *itemName;
There are three property attributes. Each attribute has two or three options, one of which is the default and does not have to explicitly declared.
The first attribute of a property has two options: nonatomic or atomic . This attribute has to do with multi-threaded applications and is outside the scope of this book. Most Objective-C programmers typically use nonatomic : we do at Big Nerd Ranch, and so does Apple. In this book, we’ll use nonatomic for all properties.
Let’s change BNRItem to use properties instead of accessor methods. In BNRItem.h , replace all of your accessor methods with properties that are nonatomic.
-
NSMutableArray *items = [[NSMutableArray alloc] init];
BNRItem *backpack = [[BNRItem alloc] init];
[backpack setItemName:@"Backpack"];
[items addObject:backpack];
BNRItem *calculator = [[BNRItem alloc] init];
[calculator setItemName:@"Calculator"];
[items addObject:calculator];
[backpack setContainedItem:calculator];
NSLog(@"Setting items to nil...");
items = nil;
backpack = nil;
NSLog(@"Container: %@", [calculator container]);
calculator = nil;
Build and run the application. Notice that after the backpack is destroyed, the calculator reports that it has no container without any additional work on our part.
A variable can also be declared using the __unsafe_unretained attribute. Like a weak reference, an unsafe unretained reference does not take ownership of the object it points to. Unlike a weak reference, an unsafe unretained reference is not automatically set to nil when the object it points to is destroyed. This makes unsafe unretained variables, well, unsafe. To see an example, change container to be unsafe unretained in BNRItem.h .
__unsafe_unretained BNRItem *container;
Build and run the application. It will most likely crash. The reason? When the calculator was asked for its container within the NSLog function call, it obligingly returned its value – the address in memory where the non-existent backpack used to live. Sending a message to a non-existent object resulted in a crash. Oops.
As a novice iOS programmer, you won’t use __unsafe_unretained . As an experienced programmer, you probably won’t use it, either. It exists primarily for backwards compatibility: applications prior to iOS 5 could not use weak references, so to have similar behavior, they must use __unsafe_unretained .
Be safe. Change this variable back to __weak .
__weak BNRItem *container;
Here’s the current diagram of RandomPossessions . Notice that the arrow representing the container pointer variable is now a dotted line. A dotted line denotes a weak (or unsafe unretained reference). Strong references are always solid lines.
Figure 3.9 RandomPossessions with retain cycle avoided
Properties
Each time we’ve added an instance variable to BNRItem , we’ve declared and implemented a pair of accessor methods. Now we’re going to see how to use properties instead. Properties are a convenient alternative to writing out accessors for instance variables – one that saves a lot of typing and makes your class files much clearer to read.
Declaring properties
A property is declared in the interface of a class where methods are declared. A property declaration has the following form:
@property NSString *itemName;
When you declare a property, you are implicitly declaring a setter and a getter for the instance variable of the same name. So the above line of code is equivalent to the following:
- (void)setItemName:(NSString *)str;
- (NSString *)itemName;
Each property has a set of attributes that describe the behavior of the accessor methods. The attributes are declared in parentheses after the @property directive. Here is an example:
@property (nonatomic, readwrite, strong) NSString *itemName;
There are three property attributes. Each attribute has two or three options, one of which is the default and does not have to explicitly declared.
The first attribute of a property has two options: nonatomic or atomic . This attribute has to do with multi-threaded applications and is outside the scope of this book. Most Objective-C programmers typically use nonatomic : we do at Big Nerd Ranch, and so does Apple. In this book, we’ll use nonatomic for all properties.
Let’s change BNRItem to use properties instead of accessor methods. In BNRItem.h , replace all of your accessor methods with properties that are nonatomic.
-
Similar Books
