A Quick Objective-C 2.0 Tutorial: Part II

In the first tutorial, we looked at the basic syntax and features in Objective-C 2.0. In this installment, we'll take a look at some of the options for customizing, and some of the more advanced syntax.

Notes About Dot Syntax

This may be obvious, but a few comments I've seen elsewhere suggests maybe it's not. If you use dot syntax like this:

NSString* movieTitle = movie.title;

You can continue to add dots to the expression:

NSString* director;

director = movie.director.fullName.capitalizedString;

NSUInteger movieTitleLength;

movieTitleLength = movie.title.length;

Which is equivalent to:

NSString* director;

director = [[[movie director] fullName] capitalizedString];

NSUInteger movieTitleLength;

movieTitleLength = [[movie title] length];

If you have a category for an existing class, you can use it with dot syntax as you would any other property:

@interface NSString (MyCategory)

- (NSUInteger)lengthWithoutSpaces;

@end

NSUInteger movieTitleLength;

movieTitleLength = movie.title.lengthWithoutSpaces;

This syntax should only be used for methods that act as getters or setters.

Public Properties with Private Setters

Some properties should have public getters and private setters. A good example of this is a cached value that you don't want clients to set directly. The conventional Cocoa solution to this is to create a Private category:

// Movie.h

@interface Movie : NSObject

{

    NSString* summary;

}

- (NSString*)summary;

@end

// Movie.m



@interface Movie (Private)

- (void)setSummary:(NSString*)aValue;

@end



@implementation Movie

- (void)setSummary:(NSString*)aValue

{

  NSString* oldSummary = summary;

  summary = [aValue retain];

  [oldSummary release];

}

@end

If you translate this to the property syntax, you'll end up with the following:

// Movie.h

@interface Movie : NSObject {

  NSString* summary;

}

@property (readonly) NSString* summary;

@end

// Movie.m

@interface Movie (Private)

@property (readwrite,copy) NSString* summary;

@end



@implementation Movie

@synthesize summary;

@end

This looks okay, but when the program runs, we see that the setter was never actually implemented:
-[Movie setSummary:]: unrecognized selector sent to instance 0x132ac0

The reason for this is that the compiler only looks at the original class definition — not additions from categories — to determine which methods to implement. Summary is declared as readonly, so the compiler doesn't generate a setter.

But there's another way. Objective-C 2.0 allows you to create nameless categories, which are formally called class continuations. From the compiler's perspective, any methods in a continuation are part of the original class — not just add-ons. This gives the compiler enough information to generate a setter.

Using a class continuation, we can redefine the property privately in the implementation file to be readwrite:

// Movie.m

@interface Movie ()

@property (readwrite,copy) NSString* summary;

@end

The one caveat here is that we get a warning:
warning: property 'summary' attribute in 'Movie' class continuation
does not match class 'Movie' property

Let's put the two definitions side-by-side to see why we get this warning:

// Movie.h

@interface Movie : NSObject {

  NSString* summary;

}

@property (readonly) NSString* summary;

@end

// Movie.m

@interface Movie ()

@property (readwrite,copy) NSString* summary;

@end

If we don't specify copy/retain/assign, the property defaults to assign. So, to the compiler, it looks like this:

@property (readonly,assign) NSString* summary;

@property (readwrite,copy) NSString* summary;

We can fix this by changing the public property definition to copy. Here's the final, correct version of a public property with a private setter:

// Movie.h

@interface Movie : NSObject {

  NSString* summary;

}

@property (readonly,copy) NSString* summary;

@end

// Movie.m

@interface Movie ()

@property (readwrite,copy) NSString* summary;

@end

It looks a little bit weird, but usually it's better to make sure your project compiles without warnings. And don't worry about clients of your class accidentally calling the setter. If they do, they'll get this:
error: object cannot be set - either readonly
property or no setter found

That's a hard error, not a warning. If the Movie class attempts to set its own private value internally, no errors or warnings are generated:

self.summary = @"Superheroing meets everyday life.";

Custom Accessor and Variable Names

If you want customize getter and/or setter names, it's a simple matter of adding an additional key/value pair to the property declaration:

@property (assign,getter=isSelected) BOOL selected;

The setter is a bit different. It must have the colon at the end to match normal Objective-C notation:

@property (copy,setter=setDefaultTitle:) NSString* title;

You should use these sparingly, though. Properly-named accessors will make your life easier, particular with Key-Value Coding and Cocoa Bindings. The example above of adding an "is" prefix is fairly common for BOOLs, and Key-Value Coding is smart enough to understand the intention.

You can also override instance variable names. By default, the compiler will look for an instance variable which has the same name as the property, but you can customize this with the following syntax:
@synthesize propertyName=ivar;

For example:

// Movie.h

@interface Movie : NSObject {

  NSString* movieTitle;

}

@property (copy) NSString* title;

@end

// Movie.m

@implementation Movie

@synthesize title=movieTitle;

@end

Mixing Synthesized and Custom Accessors

The @synthesize directive is flexible. It will only generate accessors for methods which don't already exists. For example, this is completely valid:

@implementation Movie



@synthesize title;



- (void)setTitle:(NSString*)newTitle {

  title = [newTitle copy];

}



@end

(this example assumes garbage collection is on)

In this case, @synthesize will only generate a getter, since the setter already exists. This is helpful if you want to do something other than just set a value in the setter — such as add logging, for example.

Methods Provided at Runtime

Some accessors are created dynamically at runtime, such as certain ones used in CoreData's NSManagedObject class. If you want to declare and use properties for these cases, but want to avoid warnings about methods missing at compile time, you can use the @dynamic directive instead of @synthesize. For example:

// Movie.h

@interface Movie : NSManagedObject {

}

@property (retain) NSString* title;

@end

// Movie.m

@implementation Movie

@dynamic title;

@end

The other subtle note here is that there's no title instance variable defined. This is because NSManagedObject has its own data store. Since we're using @dynamic, there will be no warnings or errors about the missing instance variable.

Using the @dynamic directive essentially tells the compiler "don't worry about it, a method is on the way."

Extra Notes

The poseAsClass: method has been deprecated, but the runtime functions have been completely overhauled, so you might be able to find what you need in /usr/include/objc/runtime.h

In terms of style, you should only use the dot syntax for things that act as getters and setters. You should not use it for utility methods, for example. In this way, Objective-C is different from Ruby, JavaScript, Java, and so on:

// Good

NSString* fileName = filePath.lastPathComponent;

NSSize imageSize = image.size;

person.fullName = @"Bob Parr";



// Don't do this

container.rebuildCache;

fileName.stripWhitespace;

object.alloc.init;

Finally, it's worth noting that Xcode 3.0 can actually convert your code to Objective-C 2.0:

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.