iOS Programming: The Big Nerd Ranch Guide, 3/e (Big Nerd Ranch Guides) by Aaron Hillegass, Joe Conway Page A

 // item will be given a pointer to its container
    [i setContainer:self];
}

- (BNRItem *)containedItem
{
    return containedItem;
}

- (void)setContainer:(BNRItem *)i
{
    container = i;
}

- (BNRItem *)container
{
    return container;
}

     
    In main.m , remove the code that populated the array with random items. Then create two new items, add them to the array, and make them point at each other.
     
    #import
#import "BNRItem.h"

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        NSMutableArray *items = [[NSMutableArray alloc] init];

         for (int i = 0; i < 10; i++) {
             BNRItem *p = [BNRItem randomItem];
             [items addObject:p];
         }

         for (BNRItem *item in items)
             NSLog(@"%@", item);

             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;
    }
    return 0;
}
    Here’s what the application looks like now:
     
    Figure 3.7  RandomPossessions with retain cycle
     
    Per our understanding of memory management so far, both BNRItem s should be destroyed along with their instance variables when items is set to nil . Build and run the application. Notice that the console does not report that these objects have been destroyed.
     
    This is a retain cycle: the backpack and the calculator have strong references to one another, so there is no way to destroy these objects. Figure 3.8 shows the objects in the application that are still taking up memory once items has been set to nil .
     
    Figure 3.8  A retain cycle!
     
    The two BNRItem s cannot be accessed by any other part of the application (in this case, the main function), yet they still exist in their own little world doing nothing useful. Moreover, because they cannot be destroyed, neither can the other objects that their instance variables point to.
     
    To fix this problem, one of the pointers between the BNRItem s needs to be a weak reference. To decide which one should be weak, think of the objects in the cycle as being in a parent-child relationship. In this relationship, the parent can own its child, but a child should never own its parent. In our retain cycle, the backpack is the parent, and the calculator is the child. Thus, the backpack can keep its strong reference to the calculator ( containedItem ), but the calculator’s reference to the backpack ( container ) should be weak.
     
    To declare a variable as a weak reference, we use the __weak attribute. In BNRItem.h , change the container instance variable to be a weak reference.
     
    __weak  BNRItem *container;
    Build and run the application again. This time, the objects are destroyed properly.
     
    Every retain cycle can be broken down into a parent-child relationship. A parent typically keeps a strong reference to its child, so if a child needs a pointer to its parent, that pointer must be a weak reference to avoid a retain cycle.
     
    A child holding a strong reference to its parent’s parent also causes a retain cycle. So the same rule applies in this situation: if a child needs a pointer to its parent’s parent (or its parent’s parent’s parent, etc.), then that pointer must be a weak reference.
     
    It’s good to understand and look out for retain cycles, but keep in mind that they are quite rare. Also, Xcode has a Leaks tool to help you find them. We’ll see how to use this tool in Chapter 21 .
     
    An interesting property of weak references is that they know when the object they reference is destroyed. Thus, if the backpack is destroyed, the