CHAPTER 10: Object Initialization 199 - (id) initWithPressure: (float) p { if (self = [self initWithPressure: p treadDepth: 20.0]) { } return (self); } // initWithPressure - (id) initWithTreadDepth: (float) td { if (self = [self initWithPressure: 34.0 treadDepth: td]) { } return (self); } // initWithTreadDepth NOTE You don’t really need the empty bodies for the if statements, as in initWithPressure:treadDepth:. We like to do that so that all the init methods have a consistent look. Adding the AllWeatherRadial Initializer Now, it’s time to add an initializer to AllWeatherRadial. The only method we need to add is an override of the designated initializer: - (id) initWithPressure: (float) p treadDepth: (float) td { if (self = [super initWithPressure: p treadDepth: td]) { rainHandling = 23.7; snowHandling = 42.5; } return (self); } // initWithPressure:treadDepth CHAPTER 10: Object Initialization200 Now, when we run the program, the proper defaults are set: AllWeatherRadial: 34.0 / 20.0 / 23.7 / 42.5 AllWeatherRadial: 34.0 / 20.0 / 23.7 / 42.5 AllWeatherRadial: 34.0 / 20.0 / 23.7 / 42.5 AllWeatherRadial: 34.0 / 20.0 / 23.7 / 42.5 I am a slant- 6. VROOOM! VROOM, indeed! Initializer Rules You’re not required to create an initializer method for your class. If you don’t have any state you need to set up or the default behavior of alloc in clearing everything out to zero is good enough, you might choose not to bother with an init. If you do write an initializer, be sure you call the superclass’s designed initializer in your own designated initializer. If you have more than one initializer, pick one to be the designated initializer. That method will be the one that calls the superclass’s designated initializer. Implement all of your other initializers in terms of your designated initializer, as we did previously. Summary In this chapter, you learned all about object allocation and initialization. In Cocoa, these are two separate operations: alloc, a class method that comes from NSObject, allocates a chunk of memory and clears it to zero. init methods, which are instance methods, get an object up and running. A class can have more than one init method. These init methods are usually convenience methods that make getting the object configured the way you want easier. You’ll choose one of these init methods to be the designated initializer. All other init methods are coded in terms of the designated initializer. In your own init methods, you need to call either your own designated initializer or the superclass’s designated initializer. Be sure to assign the value of the superclass’s initialzer to self and return that value from your init method. It’s possible for a superclass to decide to return an entirely different object. Coming next are properties, a quick and easy way to make your accessor methods. 201 r Chapter11 Properties emember back in the mists at the dawn of time when we wrote accessor methods for our instance variables? We wrote a lot of boilerplate code, creat- ing both a -setBlah method to set the object’s blah attribute (obviously) and a -blah method to retrieve it. If the attribute is an object, we needed to retain the new one and release the old one. There are utilities out there that will turn your class definition into method declarations and definitions that you can paste into your files. But still, writing accessor methods is a lot of mind- numbing work that can better be applied to doing the cool stuff that’s unique to your program. In Objective-C 2.0, Apple introduced properties, a combination of new compiler directives and a new attribute accessor syntax. The new proper- ties feature greatly reduces the amount of mindless code you have to write. Throughout this chapter, we’ll be modifying 10.01 CarParts-Init to use proper- ties. The final code for this chapter can be found in the 11.01 CarProperties project. Remember that Objective-C 2.0 features can only be used on Mac OS X 10.5 (Leopard) or later. Properties are used heavily in newer parts of Cocoa (espe- cially the snazzy Core Animation features) and are also used a lot in iPhone development, so they’re worth getting familiar with. CHAPTER 11: Properties202 Shrinking Property Values First off, we’re going to convert one of the simpler classes, AllWeatherRadial, to use prop- erties. To make the discussion a little more interesting, we’ll add a couple of calls in main to change some values on the AllWeatherRadials we create. We’re simulating someone buy- ing four tires on sale from different stores, so all four have different handling characteristics. Here is main again, with the new lines in bold: int main (int argc, const char * argv[]) { NSAutoreleasePool *pool; pool = [[NSAutoreleasePool alloc] init]; Car *car = [[Car alloc] init]; int i; for (i = 0; i < 4; i++) { AllWeatherRadial *tire; tire = [[AllWeatherRadial alloc] init]; [tire setRainHandling: 20 + i]; [tire setSnowHandling: 28 + i]; NSLog(@"the tire's handling is %.f %.f", [tire rainHandling], [tire snowHandling]); [car setTire: tire atIndex: i]; [tire release]; } Engine *engine = [[Slant6 alloc] init]; [car setEngine: engine]; [car print]; [car release]; [pool release]; return (0); } // main If you run the program now, you’ll get this output, showing our newly changed tire handling values: CHAPTER 11: Properties 203 tire 0's handling is 20 28 tire 1's handling is 21 29 tire 2's handling is 22 30 tire 3's handling is 23 31 AllWeatherRadial: 34.0 / 20.0 / 20.0 / 28.0 AllWeatherRadial: 34.0 / 20.0 / 21.0 / 29.0 AllWeatherRadial: 34.0 / 20.0 / 22.0 / 30.0 AllWeatherRadial: 34.0 / 20.0 / 23.0 / 31.0 I am a slant-6. VROOOM! Shrinking the Interface Now let’s look at AllWeatherRadial’s class interface: #import <Foundation/Foundation.h> #import "Tire.h" @interface AllWeatherRadial : Tire { float rainHandling; float snowHandling; } - (void) setRainHandling: (float) rainHanding; - (float) rainHandling; - (void) setSnowHandling: (float) snowHandling; - (float) snowHandling; @end // AllWeatherRadial This should be old hat for you. Let’s clean it up, property-style: #import <Foundation/Foundation.h> #import "Tire.h" @interface AllWeatherRadial : Tire { float rainHandling; float snowHandling; } @property float rainHandling; @property float snowHandling; @end // AllWeatherRadial A bit simpler, isn’t it? No need for the four method definitions. Notice that we’ve grown two keywords preceded by at signs. Recall that the at sign is a signal for “Objective-C weirdness CHAPTER 11: Properties204 coming your way”! @property is a new compiler feature that says that a new object attribute is being declared. @property float rainHandling; says that objects of the class AllWeatherRadial have an attribute, of type float, called rainHandling. It also says that you can set the property by calling -setRainHanding: and that you can access the attribute by calling -rainHandling. You can run the program now, and it behaves just as it did before. All @property is doing is automatically declaring the setter and getter methods for the attribute. The attribute doesn’t actually have to match the name of the instance variable, but it will in most cases. We’ll talk about this a bit later. There are also some additional knobs you can turn on the properties; we’ll talk about them later too, so please hang on. Shrinking the Implementation Now, let’s look at the AllWeatherRadial implementation again: #import "AllWeatherRadial.h" @implementation AllWeatherRadial - (id) initWithPressure: (float) p treadDepth: (float) td { if (self = [super initWithPressure: p treadDepth: td]) { rainHandling = 23.7; snowHandling = 42.5; } return (self); } // initWithPressure:treadDepth - (void) setRainHandling: (float) rh { rainHandling = rh; } // setRainHandling - (float) rainHandling { return (rainHandling); } // rainHandling - (void) setSnowHandling: (float) sh CHAPTER 11: Properties 205 { snowHandling = sh; } // setSnowHandling - (float) snowHandling { return (snowHandling); } // snowHandling - (NSString *) description { NSString *desc; desc = [[NSString alloc] initWithFormat: @"AllWeatherRadial: %.1f / %.1f / %.1f / %.1f", [self pressure], [self treadDepth], [self rainHandling], [self snowHandling]]; return (desc); } // description @end // AllWeatherRadial In the previous chapter, we discussed the init method, the designated initializer, all the set- ter and getter methods, and the description. We’re now going to ruthlessly eliminate of all the setter and getter methods and replace them with two lines of code: #import "AllWeatherRadial.h" @implementation AllWeatherRadial @synthesize rainHandling; @synthesize snowHandling; - (id) initWithPressure: (float) p treadDepth: (float) td { if (self = [super initWithPressure: p treadDepth: td]) { rainHandling = 23.7; snowHandling = 42.5; } return (self); CHAPTER 11: Properties206 } // initWithPressure:treadDepth - (NSString *) description { NSString *desc; desc = [[NSString alloc] initWithFormat: @"AllWeatherRadial: %.1f / %.1f / %.1f / %.1f", [self pressure], [self treadDepth], [self rainHandling], [self snowHandling]]; return (desc); } // description @end // AllWeatherRadial @synthesize is a new compiler feature that says “create the accessors for this attribute.” For the line of code @synthesize rainHandling;, the compiler emits the compiled code for -setRainHandling: and -rainHandling. NOTE You may be familiar with code generation: Cocoa accessor-writing utilities and UI builders on other platforms generate source code, which is then compiled. But @synthesize is not code generation. You won’t ever see the code that implements -setRainHandling: and -rainHandling, but these methods will exist and will be callable. This gives Apple the flexibility of changing the way accessors are generated in Objective-C, possibly leading to safer implementations or better performance. If you run the program now, you’ll get the same results as we got before the changes. Dots Incredible Objective-C 2.0 properties introduce a new bit of syntactic sugar that makes accessing object attributes easier. These new features also make Objective-C a bit more approachable for folks who are used to languages like C++ and Java. Recall the two new lines we added to main to change the tire’s handling values: [tire setRainHandling: 20 + i]; [tire setSnowHandling: 28 + i]; CHAPTER 11: Properties 207 We can replace that code with this: tire.rainHandling = 20 + i; tire.snowHandling = 28 + i; If you run the program again, you’ll see the same results. We use NSLog to report the han- dling values of the tires: NSLog(@"tire %d's handling is %.f %.f", i, [tire rainHandling], [tire snowHandling]); We can now replace that code with this: NSLog(@"tire %d's handling is %.f %.f", i, tire.rainHandling, tire.snowHandling); The “dot notation” looks a lot like structure access in C and object access in Java—on pur- pose. When you see a dot on the left-hand side of an equal sign, the setter for that attribute name (-setRainHandling: and -setSnowHandling:) will be called. Otherwise, if you see a dot next to an object variable, the getter for that attribute name (-rainHandling and -snowHandling) is called. NOTE Dot notation is just shorthand for calling accessor methods. No additional magic is happening under the hood. In Chapter 15, we’ll talk about key-value coding, which actually uses some hard-core runtime magic. There is no connection between the property dot notation and the cool stuff key-value coding does behind the scenes. If you’re using properties, and you get strange error messages about accessing something that is not a struct, make sure you’ve included all the necessary header files for the classes you’re using. That’s pretty much it for the new stuff that properties introduce. Of course, we have some additional cases to discuss for the proper handling of object attributes and for avoiding the exposure of both setters and getters. Let’s talk about those next. CHAPTER 11: Properties208 Objecting to Properties So far we’ve looked at properties for scalar types—float in particular, but the same techniques apply for int, char, BOOL, and struct. For example, you can have an NSRect property if you want. Objects bring some added complications. Recall that we retain and release objects as they flow through our accessors. For some object values, particularly string values, you want to always -copy them. Yet for other object values, like delegates (which we’ll talk about in the next chapter), you don’t want to retain them at all. NOTE Whoa, wait a minute. What’s with that copying and not retaining? You want to make copies of string arguments. A common error is to get a string from the user interface, like a text field, and use that as something’s name. The strings you get from text fields are typically muta- ble strings and will change when the user types something new. Making a copy of the string prevents the value from changing unexpectedly. Now, what about not retaining objects? There is a special case, called a retain cycle, in which reference counting breaks down. If you have an owner/owned relationship, as between Car and Engine, you want the car to retain (own) the engine but not the other way around. The engine should not retain the car it has been installed in. If the car retains the engine, and the engine retains the car, then neither refer- ence count will go to zero, and neither will ever be cleaned up. Car’s dealloc won’t get called until the engine releases the car in its dealloc, and the engine’s dealloc won’t get called until car’s dealloc releases the Engine. They just sit there, staring at each other, waiting for the other to blink. The general rule is that the owner object retains the ownee object, and not the other way around. Lucky garbage collection users don’t need to worry about this case. Let’s add a new feature to Car so that we can play with some new property syntax. That’s gonna be exciting! We’ll give the car a name. We’ll start out old school and use traditional accessor methods. First is Car.h, with the new goodies in bold: #import <Cocoa/Cocoa.h> @class Tire; @class Engine; @interface Car : NSObject { NSString *name; NSMutableArray *tires; Engine *engine; } [...]... (readonly or readwrite) and object memory management (retain, assign, or copy) Behind the scenes, the compiler automatically generates the method declarations for the setter and getter for the object’s attribute Use the @synthesize directive to tell the compiler to generate the implementation for the accessors You can control which instance variable is affected by the generated implementation If you don’t... that the category is called NumberConvenience, and it adds methods to NSString Another way to say this is, “We’re adding a category onto NSString called NumberConvenience.” You can add as many categories to a class as you want, as long as the category names are unique You indicate the class you’re putting the category onto (NSString) and the name of the category (NumberConvenience), and you list the. .. *engine; and then change the synthesize directive: @synthesize name = appellation; The compiler will still create -setName: and -name but will use the appellation instance variable inside of their implementations But when you compile, you see a couple of errors You may recall that we directly accessed the name instance variable, which has been changed We can choose to do a search and replace on the name,... directory and contains the code that adds such a category to NSString @interface The declaration of a category looks a lot like the declaration for a class: @interface NSString (NumberConvenience) - (NSNumber *) lengthAsNumber; @end // NumberConvenience You should notice a couple of interesting things about this declaration First, an existing class is mentioned, followed by a new name in parentheses... bit Categories have two limitations The first is that you can’t add new instance variables to a class There’s nowhere to put them The second limitation concerns name collisions, in which one of your category methods has the same name as an existing method When names collide, the category wins Your category method will completely replace the original method, with no way of getting the original back Some... object by asking it, “Can you respond to this selector?” If it can, NSNetServiceBrowser sends the message What is a selector? It’s just the name of a method, but it’s encoded in a special way that’s used by the Objective- C runtime for quick lookups You indicate a selector by using the @selector() compiler directive, with the name of the method nestled in the parentheses So, the selector for the Car... where all the autoreleased objects go In particular, the mutable dictionary will end up in here, as will all of the NSNumbers our category creates After making the pool, a new mutable dictionary is created Recall that this handy Cocoa class lets us store pairs of keys and objects NSMutableDictionary *dict; dict = [NSMutableDictionary dictionary]; We can’t put primitive types like ints into a dictionary,... You’ll notice the declarations of the simple accessors are gone, and they have been replaced by @property declarations You can decorate @property with additional attributes to express your exact intentions on how the property is to behave By adding copy to name, the compiler and users of the class know that name is going to be copied This can simplify the life of programmers using this class, because programmers... First is CategoryThing.h, which has the class declaration and some categories This file starts with the #import of the Foundation framework, and the class declaration with three integer instance variables: #import @interface CategoryThing : NSObject { int thing1; int thing2; int thing3; } @end // CategoryThing After the class declaration come three categories, and each category... NumberConvenience CHAPTER 12: Categories Like the @interface for the category, the @implementation has the names of the class and the category, along with the bodies of the new methods The lengthAsNumber method gets the length of the string by calling [self length] You will send the lengthAsNumber message to this string Then, a new NSNumber is created with the length Let’s take a quick time-out for one . for the object’s attribute. Use the @synthesize directive to tell the compiler to generate the implementation for the accessors. You can control which instance variable is affected by the generated. dealloc won’t get called until the engine releases the car in its dealloc, and the engine’s dealloc won’t get called until car’s dealloc releases the Engine. They just sit there, staring at each. // Car Now we add the implementation of the accessors (notice that we’re copying the name), along with choosing a default name for the car and displaying it in the description: #import "Car.h" @implementation