This is the type of statement you use to get the init method up and running:

(self = [super initWithAmount:theAmount
                                      forBudget:aBudget])

In this part of the statement, you're invoking the superclass's init method:

[super initWithAmount:theAmount forBudget:aBudget]

The entire statement sets up self and super as equals so that you can then use super.

Chapter 2 of this minibook points out that this is the standard way of sending a message to your superclass.

In this case, the superclass for the CashTransaction subclass is Transaction, and you invoke the Transaction superclass initialization method initWithAmount::. Your subclass should always invoke its superclass initialization method before doing any initialization. Your subclass's superclass is equally as respectful of its superclass and does the same thing; and up, up, and away you go from superclass to superclass until you reach the NSObject superclass init method. The NSObject superclass init method doesn't do anything; it just returns self. It's there to establish the naming convention, and all it does is return back to its invoker, which does its thing and then returns back to its invoker, until it gets back to you.

As you can see in Listing 3-2, Transaction invokes its superclass's init method as well. But in this case, it simply calls init (as per convention) because its superclass is NSObject.

- (id) initWithAmount: (double) theAmount forBudget:
   (Budget*) aBudget {

 if (self = [super init]) {

    budget = aBudget;
    amount = theAmount;
    }
  return self;
}

Next, examine this unusual-looking statement:

if (self = [super initWithAmount:theAmount
  forBudget:aBudget]) {

Ignore the if for the moment. What you're doing is assigning what you got back from your superclass's init method to self. As you remember, self is the "hidden" variable accessible to methods in an object that points to its instance variables. (If you're unclear on this point, refer to the discussion in Chapter 1 of this minibook.) So it would seem that self should be whatever you got back from your allocation step. Well, yes and no. Most of the time, the answer is yes, but sometimes the answer is no, which may or may not be a big deal. So, check out the following bullet list and examine the possibilities.

When you invoke a superclass's initialization method, one of three things can happen:

Initializing instance variables, including creating the objects you need, is what you probably thought initialization is about. Notice that you're initializing your instance variable after your superclass's initialization, which you can see in Listings 3-1 and 3-2. Waiting until after your superclass does its initialization gives you the opportunity to actually change something your superclass may have in initialization, but more importantly, it allows you to perform initialization knowing that what you have inherited is initialized and ready to be used.

In the CashTransaction initWithAmount:: initializer, all that's done is the initialization of the name instance variable of the superclass (Transaction) with the kind of transaction it is — cash, in this case.

name = @"Cash";

In the section, "Invoking the superclass's init variable," the self = statement ensures that self is set to whatever object you get back from the superclass initializer. After the code block that initializes the variables, you put

return self;

Remember that if a method does not specify the type of its return value, the default is to return a pointer to an object (for example, something of id type). This means that, barring any other sensible thing to return, methods should always return self.

No matter what you get back from invoking the superclass initializer, in the initialization method you need to set self to that value and then return it to the invoking method. That could be a method that wants to instantiate the object or a subclass that invoked the init method (the init method being its superclass's init method).

When you're instantiating a new object, it behooves you to determine whether a return of nil is a nonfatal response to your request (and, if so, coding for it). In the examples in this book, the answer will always be no, and that will generally be the case with framework objects as well. In this example

theBudget = [[Budget alloc] initWithAmount:budgetAmount withE
   xchangeRate:theExchangeRate];

getting nil back would be more than your poor app could handle and would signal that you're in very deep trouble.

Listings 3-3 through 3-13 show how to implement initializers in the conventional way. You create the init... structure that enables you to more easily initialize any new instance variables you may add to existing classes, as well as ensure that you can do initialization correctly when you add any new superclasses or subclasses. (The lines in bold are changes to the code examples in Chapters 1 and 2 of this minibook.)

#import <Cocoa/Cocoa.h>

@interface Budget : NSObject {

  float  exchangeRate;
  double budget;
  double transaction;
}

- (id) initWithAmount: (double) aBudget
               withExchangeRate: (double) anExchangeRate ;

- (void) spendDollars: (double) dollars ;

- (void) chargeForeignCurrency: (double) euros;
- (double) returnBalance;
@end

#import "Budget.h"

@implementation Budget

 - (id) initWithAmount: (double) aBudget
                withExchangeRate: (double) anExchangeRate {

   if (self = [super init]) {
     exchangeRate = anExchangeRate;
     budget = aBudget;
   }
   return self;
}
- (void) spendDollars: (double) dollars {

  budget -= dollars;
}
- (void) chargeForeignCurrency: (double) foreignCurrency {

  transaction = foreignCurrency*exchangeRate;
  budget -= transaction;
}
- (double) returnBalance {

  return budget;
}
@end

#import <Cocoa/Cocoa.h>
@class Budget;
@interface Transaction : NSObject {

  Budget *budget;
  double amount;
NSString *name;
}

- (id) initWithAmount: (double) theAmount
                                        forBudget: (Budget*) aBudget;
- (void) spend;
@end

#import "Transaction.h"
#import "Budget.h"

@implementation Transaction

- (id) initWithAmount: (double) theAmount
                            forBudget: (Budget*) aBudget {
  if (self = [super init]) {
    budget = aBudget;
    amount = theAmount;
  }
  return self;
}
- (void) spend {
}
@end

#import <Cocoa/Cocoa.h>
#import "Transaction.h"

@interface CashTransaction : Transaction {

}

- (id) initWithAmount: (double) theAmount forBudget:
   (Budget*) aBudget ;
@end

#import "CashTransaction.h"
#import "Budget.h"

@implementation CashTransaction

- (id) initWithAmount: (double) theAmount forBudget:
   (Budget*) aBudget {

  if (self = [super initWithAmount:theAmount
   forBudget:aBudget]) {
    name = @"Cash";
  }
  return self;
}

- (void) spend {
  [budget spendDollars:amount];
}
@end

#import <Cocoa/Cocoa.h>
#import "Transaction.h"

@interface CreditCardTransaction : Transaction {

}
- (id) initWithAmount: (double) theAmount forBudget:
   (Budget*) aBudget ;
@end

#import "CreditCardTransaction.h"
#import "Budget.h"

@implementation CreditCardTransaction

- (id) initWithAmount: (double) theAmount forBudget:
   (Budget*) aBudget {

  if (self = [super initWithAmount:theAmount
   forBudget:aBudget]) {
    name = @"Credit card";
  }
  return self;
}
- (void) spend {
  [budget chargeForeignCurrency:amount];
}
@end

#import <Cocoa/Cocoa.h>
@class Budget;

@interface Destination : NSObject {

  NSString       *country;
  double          exchangeRate;
  NSMutableArray *transactions;
  Budget         *theBudget;

}
- (id) initWithCountry: (NSString*) theCountry
                      andBudget: (double) budgetAmount
                      withExchangeRate:(double) theExchangeRate;
- (void) spendCash: (double) aTransaction;
- (void) chargeCreditCard:(double) aTransaction;
- (double) leftToSpend
@end

#import "Destination.h"
#import "CashTransaction.h"
#import "CreditCardTransaction.h"
#import "Budget.h"
#import "Transaction.h"
@implementation Destination

- (id) initWithCountry: (NSString*) theCountry andBudget:
   (double) budgetAmount withExchangeRate: (double)
   theExchangeRate{
  if (self = [super init]) {
    transactions = [[NSMutableArray alloc]
   initWithCapacity:10];

theBudget = [[Budget alloc] initWithAmount:budgetAmount
             withExchangeRate:theExchangeRate];
              country = theCountry;
              NSLog (@"I'm off to %@", theCountry);
             }

             return self;
}

-(void) spendCash:(double)amount{

Transaction *aTransaction = [[CashTransaction alloc]
   initWithAmount:amount forBudget:theBudget];
  [transactions addObject:aTransaction];
  [aTransaction spend];
}
-(void) chargeCreditCard: (double) amount{

Transaction *aTransaction =
          [[CreditCardTransaction alloc]
   initWithAmount:amount forBudget:theBudget];
  [transactions addObject:aTransaction];
  [aTransaction spend];
}
- (double) leftToSpend {

  return [theBudget returnBalance];
}
@end

#import <Foundation/Foundation.h>
#import "Destination.h"

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

  NSString* europeText = [[NSString alloc]
   initWithFormat:@"%@", @"Europe"];
  Destination* europe = [[Destination alloc]
   initWithCountry:europeText andBudget:1000.00
   withExchangeRate:1.25];

  NSString* englandText = [[NSString alloc]
                       initWithFormat:@"%@", @"England"];

  Destination* england = [[Destination alloc]
   initWithCountry:englandText andBudget:2000.00
   withExchangeRate:1.50];

for (int n = 1; n < 2; n++) {
      double transaction = n*100.00;
      NSLog (@"Sending a %.2f cash transaction", transaction);
      [europe spendCash:transaction];
      NSLog(@"Remaining budget %.2f", [europe leftToSpend]);
      NSLog (@"Sending a %.2f cash transaction", transaction);
      [england spendCash:transaction];
      NSLog(@"Remaining budget %.2f", [england leftToSpend]);
    }

    int n = 1;
    while (n < 4) {
      double transaction = n*100.00;
      NSLog(@"Sending a %.2f credit card transaction",
     transaction);
      [europe chargeCreditCard:transaction];
      NSLog(@"Remaining budget %.2f", [europe leftToSpend]);
      NSLog(@"Sending a %.2f credit card transaction",
     transaction);
      [england chargeCreditCard:transaction];
      NSLog(@"Remaining budget %.2f", [england leftToSpend]);
      n++;
    }
    return 0;
}

In Chapter 1 of this minibook, you found out how to allocate and initialize objects using a combination of alloc and init. Many objects you allocate stay around for the duration of your program, and for those objects, all you have to do is, well, nothing really. When your program terminates, they are de-allocated, and the memory is returned to the operating system.

But some objects you use for a while to get your money's worth out of them and then . . . you're done with them. When you're done with them, you should return the memory allocated to them back to the OS so it can allocate that memory for new objects. If you don't, you may cause problems.

Start by looking at how memory management works. In Objective-C 2.0 (as opposed to earlier versions), you can manage memory for iPhone apps by reference counting — keeping the system up to date on whether an object is currently being used. Read on to find out more.

In many ways, Objective-C is like the coolest guy in your school, who now makes a seven-figure income bungee jumping and skateboarding during the summers, while snowboarding around the world in the winter.

In other ways, though, Objective-C is like the nerd in your class, who grew up to be an accountant and reads the Financial Times for fun. Memory management falls into this category.

In fact, memory management is simply an exercise in counting. To manage its memory, Objective-C (actually Cocoa) uses a technique known as reference counting. Every object has its own reference count, or retain count.

When an object is created via alloc or new — or through a copy message, which creates a copy of an object but has some subtleties beyond the scope of this book — the object's retain count is set to 1. As long as the retain count is greater than zero, the memory manager assumes that someone cares about that object and leaves it alone.

It's your responsibility to maintain that reference count by directly or indirectly increasing the retain count when you're using an object and then decreasing it when you're finished with it. When the retain count goes to zero, the runtime system (Cocoa) assumes that no one needs it anymore. Cocoa automatically sends the object a dealloc message, and after that, its memory is returned to the system to be reused.

Take a look at an example: In Vacation.m, you create a string object and then pass that as an argument into the init method when you create the Destination object, as shown here:

NSString* englandText = [[NSString alloc]
                      initWithFormat:@"%@", @"England"];
Destination* england = [[Destination alloc]
   initWithCountry:englandText andBudget:2000.00
   withExchangeRate:1.50];

The Destination object sticks around until the program is terminated. At that point, everything gets de-allocated, so there is really no problem and no real (although some potential) memory management issues.

But what happens if you decide sometime along the way on your trip not to go to England after all. You really have always wanted to go to Antarctica, and an opportunity to hitch a ride on a rock star's private jet presents itself, so bye-bye England, and hello Ushuaia, Tierra del Fuego, Argentina.

Before you take off, however, you want to do one thing — besides send for your long underwear. You need to delete England as a destination, freeing up that budget money, and create a new destination — Antarctica.

[england release];

release does not de-allocate the object!

All release does is decrement the retain count by 1. This is very important to keep in mind because while one method or object in your application may no longer need an object, it still may be needed by another method or object in your program. That's why you don't dealloc it yourself, and instead you need to trust the runtime system to manage the retain count for you. But it is your job to keep the runtime system informed of your object by using the release message.

Well that's cool, and being a good citizen, the england object wants to release all its objects in its dealloc method. No problem here, one would think. Destination has instance variables pointing to the objects it uses:

NSString* country;
double exchangeRate;
NSMutableArray *transactions;
Budget* theBudget;

So, in the dealloc method that is invoked before the Destination object is de-allocated by the OS, those other objects can be released.

- (void) dealloc {

  [transactions release];
  [country release];
  [theBudget release];
  [super dealloc];
}

Although you don't have to release the exchangeRate because it is not an object, do you really want to release all those other objects? What if other objects in your program still need to use those objects? Actually, taking that into account is very easy, as long as you follow the rules.

As I mention earlier, when you create an object using alloc or new, or through a copy message, the object's retain count is set to 1. So you're cool. In fact, whenever you create an object like that, your solemn responsibility is to release it when you are done. There is a flip side to this coin, however; if you're using an object, a pointer to it is sent to you as an argument in a message, as is the case for the NSString object in the following:

Destination* england = [[Destination alloc]
   initWithCountry:englandText andBudget:2000.00
   withExchangeRate:1.50];

Then it's also your responsibility to increment the retain count by sending it the retain message, as you can see in the bolded section of the implementation of the initWithCountry::: method:

- (id) initWithCountry: (NSString*) theCountry andBudget:
   (double) budgetAmount withExchangeRate: (double)
   theExchangeRate{
  if (self = [super init]) {
    transactions = [[NSMutableArray alloc]
                                     initWithCapacity:10];
    theBudget = [[Budget alloc]
                       initWithAmount:budgetAmount
                       withExchangeRate:theExchangeRate];
    exchangeRate = theExchangeRate;
    country = theCountry;
    [country retain];
  }
  return self;
}

In this method, the Destination object creates two objects on its own, theBudget and transactions. As a result, the retain count for each is set to 1. It also gets passed a pointer to an NSString object that was created at another time and place. If Destination plans to use that object, it needs to send it the retain message. That way, the retain count is increased by 1. If the creator of that object decides it no longer needs the object and sends it the release message, the retain count is decremented by 1. But because the Destination object sent it a retain message, the release count is still greater than 0 — the object lives!

In fact, that is exactly what happens. In main, after the object is created and sent as an argument to the Destination objects, the good little code releases the object because it really has no need for the object. When you do release an object in your code, you're counting on the fact that other objects are playing according to the rules, and the receiving object increases the retain count if it needs to continue to use an object you created. This frees the creator of an object from the responsibility of having to know anything about who's using an object it has created and worrying about when it has to free the object.

In the code in main, the string object sent in the initWithCountry::: message is released after the message is sent because the code in main has no further use for the string object it created. (Note the bolded code in the following block.)

NSString* englandText = [[NSString alloc]
   initWithFormat:@"%@", @"England"];
  Destination* england = [[Destination alloc]
   initWithCountry:englandText andBudget:2000.00
   withExchangeRate:1.50];
  [englandText release];

europeText is released as well. All's right with the world.

Here's the fundamental rule of memory management:

That's it, with corollaries of course.

In general, somewhere in your code there should be a release for every statement that creates an object using alloc or new, or contains copy or sends a retain message.

Look at the dealloc method in Destination.m:

- (void) dealloc {

  [transactions release];
  [theBudget release];
  [country release];
  [super dealloc];
}

Notice you release the transactions array. What happens to all the objects you added to that particular array? As you might expect, the rules are that if you want to use an object, you must send it a retain message, and if you do, then at some point you must release it. The array follows those rules, and when you add an object to an array, the array object sends the object that was just added a retain message. When the array is de-allocated, it sends release messages to all its objects. If you want to use the object after the array is de-allocated, you need to send it a retain message before the array is de-allocated.

In addition, if you remove an object from a mutable array — which is the only kind that you can add and remove objects from (refer to Chapter 4 of this minibook for more on this topic) — the object that has been removed receives a release message. So, if an array is the only owner of an object, then (by standard rules of memory management) the object is de-allocated when it's removed. If you want to use the object after its removal, you need to send it a retain message before you remove it from the array.

At the end of the discussion of using accessors to get data from objects in Chapter 1 of this minibook, you used the following code:

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

  // insert code here...

[pool drain];

This code creates an autorelease pool that is a way to manage memory for objects when it is not possible for the object creator to easily release them.

The memory management rules require you to release objects when you're done with them, and often that's pretty easy, as shown in the following example:

NSString* englandText = [[NSString alloc]
  initWithFormat:@"%@", @"England"];

Destination* england = [[Destination alloc]
  initWithCountry:englandText andBudget:2000.00
  withExchangeRate:1.50];

  [englandText release];

In main, the string object is created and then used as an argument in the Destination object's initWithCountry::: method. After control is returned to main, you can safely release that object because, as far as you are concerned, you are done with it; if Destination needs it, well, it's the Destination object's responsibility to retain it. But what about those circumstances where the creator never gets control back? For example, what if you were to create a new method called returnCountry that created a copy of the country string and returned it back to the invoker?

- (NSString*) returnCountry {

  return [country copy];
}

You might want to do that if the receiver could possibly modify it. The problem here is that control is never returned back to returnCountry, so returnCountry never has a chance to release the copy it made.

To deal with the problem of control never being returned to a creator of an object so the creator can release it, Cocoa has the concept of an autorelease pool, and the statement

NSAutoreleasePool * pool =
                        [[NSAutoreleasePool alloc] init];

creates one of those pools to be used by main. The pool is nothing more than a collection of objects that will be released sometime in the future. When you send autorelease to an object, the object is added to an NSAutoreleasePool. When that pool is "cleared" (which happens on a regular basis), all the objects in the pool are sent a release message.

So, you can now write a returnCountry method that manages memory correctly.

- (NSString*) returnCountry {

  return [[country copy] autorelease];
}

Now, memory management works just right because the returnCountry method creates a new string, autoreleases it, and returns it to the object that requested it. If that object wants to continue to use the string, that object has to send a retain message to the string because the string gets a release message in the future.

So when is that release message sent? If you're using an AppKit or UIKit application, the release message is sent in the main event loop that you return to after your program handles the current event, such as a mouse click or touch. With a Foundation Command Line Tool, the release message is sent when you destroy or drain the pool.

[pool drain];

That's as far as I'm going with how the autorelease pool works — anything else is beyond the scope of this book. Besides, I assume that you're using Cocoa (the runtime system) for your application, which automatically takes care of managing the autorelease pool for you — both creating the pool and releasing it periodically.

You want to avoid using the autorelease pool on the iPhone when possible. The memory allocated for an autoreleased object remains allocated for some period of time after you're done with it and can be an issue in more memory-intensive applications. But autorelease could be used "behind your back" at times.

For example, Objective-C has a concept called class methods. This method belongs to the class object (as opposed to an instance object of the class), and class methods used to create new instances are called factory or convenience methods. The objects it creates are autoreleased. The ones you probably will be most concerned with are in the NSString class (although there are more, even in the NSMutableArray class), such as the following:

stringWithContentsOfFile
stringWithContentsOfURL
stringWithCString
stringWithFormat:
stringWithString:

So, instead of using

NSString *newText = [NSString stringWithFormat:
@"Yo ", name];

You're using

NSString *newText = [[NSString alloc] initWithFormat:
@"Yo ", name];

and doing the release yourself.

Notice these methods are of the form stringWith, as opposed to init.... This naming convention is a handy way to differentiate a class method that uses autorelease from the init methods that use alloc.

If you do need to continue to use an autoreleased object, just like with any other object you receive, you need to send it a retain message. In doing so, you become responsible for managing that object, and you must send a release message at some point.

These methods occur most commonly when creating an object using a class method, which saves you the trouble of doing an alloc, an init..., and then a release for the object. If you look in the documentation, as illustrated in Figure 3-6, these are under the heading Class Methods. They all have a + instead of a − before the return type, which designates them as a class method.

In Figure 3-6, you can see the NSString Class reference. In the Table of Contents, I expanded the disclosure triangle next to Class Methods and then clicked the stringWithFormat: class method, the counterpart to the initWithFormat: instance method. You can see the + in front of the method declaration.

Figure 3-6. Class methods.

Notice that for class methods like these, instead of having their names start with init (for example, initWithFormat: for an NSString), they start with a reference to the class name (stringWithFormat:, for example).