set prepended. For illustration, here is a User class with a property named active:@interface User : NSObject {
BOOL active;
}
@property BOOL active;
@end
@implementation User
@synthesize active;
@end
The compiler will generate a getter method named active and a setter method named setActive. Sometimes the default method names aren't exactly what you want; for instance, it's a common convention that getters for BOOL properties be prefixed with is. In the case of our User class, we would like to have the getter named isActive.@property directive has two attributes to do just this: getter=name and setter=name. Just like the other attributes of @property, getter and setter are placed in parentheses after the @property directive and before the property type and name. So the active property in our example would look like:@interface User : NSObject {
BOOL active;
}
@property (getter=isActive) BOOL active;
@end
@implementation User
@synthesize active;
@end
And usage the active property now looks like:// example use of isActive getter
User *user = [[User alloc] init];
// getter/setter called as methods
if ( ! [user isActive] ) {
[user setActive:YES];
}
// getter/setter called with dot syntax
if (user.isActive) {
user.active = NO;
}
We'll take a closer look at dot syntax in the near future, but basically when the compiler sees code like this:if ( user.isActive ) {
user.active = NO;
}
it translates it into this:if ( [user isActive] ) {
[user setActive:NO];
}
Dot syntax is complementary to properties, but is separate and unaware of them. When translating a setter call in dot syntax to the corresponding method call, the compiler always looks for a method beginning with set. If you change your setter name to something different, you'll see a compiler error likeobject cannot be set - either readonly property or no setter foundor
request for member 'setter name' in something not a structure or unionif you call it using dot syntax. So if we rename the setter for the
active property to makeActive instead of the default setActive:@interface User : NSObject {
BOOL active;
}
@property (getter=isActive, setter=makeActive) BOOL active;
@end
then using method call syntax, we can now do this:if ( [user isActive] ) {
[user makeActive:NO];
}
but because the compiler expects setters to begin with set, using dot syntax generates an error:if (user.isActive) {
user.makeActive = NO; // ERROR: request for member 'makeActive'
// in something not a structure or union
}
In general you should follow the standard conventions and use the default getter and setter names; it's less work for you and your code is easier for others to understand.
@property directive and last week we saw how to use the @synthesize directive to tell the compiler to generate getters and setters for properties. We've covered the most commonly used attributes of the @property directive: readonly/readwrite and assign/retain/copy. Today we'll look at the nonatomic attribute and talk about what it's for and why you should (or should not) use it.@interface MyWidget {
CGPoint center;
// ...
}
@property CGPoint center;
// ...
@end
@implementation
@synthesize center;
// ...
@endcenter, it would look like this:// example assign-type getter and setter
- (CGPoint) center {
return center;
}
- (void)setCenter:(CGPoint)theCenter {
center = theCenter;
}This looks simple enough, but the compiler is helping us out here. The center instance variable is a struct that's defined like this:// struct CGPoint
struct CGPoint {
CGFloat x;
CGFloat y;
};The setCenter: method is actually doing something like this:- (void)setCenter:(CGPoint)theCenter {
center.x = theCenter.x;
center.y = theCenter.y;
}Let's look at what happens when one thread calls the setter and a second thread calls the getter. In the simple case, the setter and getter calls don't overlap:// given MyWidget instance myWidget:
// thread 1 calls setter:
[myWidget setCenter:CGPointMake(1.0f, 2.0f)];
// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
center.x = theCenter.x; // 1.0f
center.y = theCenter.y; // 2.0f
}
// center is now {1.0f, 2.0f}
// ... thread 1 preempted by thread 2 ...
// thread 2 calls getter:
CGPoint point = [myWidget center];
// center method executes:
- (CGPoint) center {
return center; // 1.0f, 2.0f
}
// point is now {1.0f, 2.0f}In this case, we get the answer we expect. Now suppose we do this again, only thread 1 gets preempted by thread 2 in the middle of the setCenter method:// myWidget.center is {1.0f, 2.0f}
// thread 1 calls setter:
[myWidget setCenter:CGPointMake(3.0f, 5.0f)];
// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
center.x = theCenter.x; // 3.0f
// ... thread 1 preempted by thread 2 ...
// thread 2 calls getter:
CGPoint point = [myWidget center];
// center method executes:
- (CGPoint) center {
return center; // 3.0f, 2.0f
}
// point is now {3.0f, 2.0f}
center.y = theCenter.y; // 5.0f
}
// myWidget.center is now {3.0f, 5.0f}
// but thread 2 read {3.0f, 2.0f}Now thread 2 is working off of a corrupt value and things are likely to go haywire. To solve this problem, we need to prevent all threads from reading center until the setCenter: method is finished. Because this is a common problem in multithreaded code, Objective-C has a special directive to accomplish this: @synchronized. We can rewrite our getter and setter for the center property like this:// adding @synchronized to getter and setter
- (CGPoint) center {
CGPoint theCenter;
@synchronized(self) {
theCenter = center;
}
return theCenter;
}
- (void)setCenter:(CGPoint)theCenter {
@synchronized(self) {
center = theCenter;
}
}Now when we read and write center from two threads, @synchronized causes other threads to pause whenever one thread is inside either of the @synchronized blocks:// myWidget.center is {1.0f, 2.0f}
// thread 1 calls setter:
[myWidget setCenter:CGPointMake(3.0f, 5.0f)];
// setCenter method executes:
- (void)setCenter:(CGPoint)theCenter {
@synchronized(self) {
center.x = theCenter.x; // 3.0f
// ... thread 1 preempted by thread 2 ...
// thread 2 calls getter:
CGPoint point = [myWidget center];
// center method executes:
- (CGPoint) center {
CGPoint theCenter;
@synchronized(self) {
// thread 1 is already synchronized on
// self so thread 2 pauses here
// ... thread 2 yields and thread 1 runs again ...
// still inside @synchronized on thread 1
center.y = theCenter.y; // 5.0f
}
}
// ... thread 1 preempted by thread 2 again ...
@synchronized(self) {
// now thread 2 resumes
theCenter = center; // 3.0f, 5.0f
}
return theCenter; // 3.0f, 5.0f
}
// point is now {3.0f, 5.0f}I'm glossing over many of the details of @synchronized here. If you're writing multithreaded code, you should read the Threading Programming Guide. The key concept here is that by default, the @synthesize directive generates this type of synchronization for you.nonatomic@synchronized directive uses a lock to prevent two threads from accessing a @synchronized block simultaneously. Although acquiring and releasing the lock is very quick, it's not free. Occasionally you have a property that is so frequently accessed that all this locking and unlocking adds up to a noticeable penalty. In these rare cases, you can declare the property to be nonatomic:@interface MyWidget {
CGPoint center;
// ...
}
@property (nonatomic) CGPoint center;
// ...
@endThe compiler omits the synchronization code when generating nonatomic getters and setters. Note that there isn't a corresponding atomic attribute for @property; generated getters and setters are synchronized by default.nonatomic.@property declarations only apply when you use @synthesize to have the compiler generate the getter and setter methods. If you write the getter or setter yourself, the attributes are ignored. Next week we'll look a little more at synchronization and show you how to write a thread safe getter when returning an Objective-C object.
To achieve a magical sense of childlike wonder that you have a hard time differentiating from megalomania: Objective C
@synthesize directive that tells the compiler to write getters and setters automatically.@property directive can shrink the boilerplate code in a class @interface declaration somewhat. We started with this:@interface Person : NSObject {
int age;
Address *address;
NSString *name;
}
- (int)age;
- (void)setAge:(int)anAge;
- (Address *)address;
- (void)setAddress:(Address *)anAddress;
- (NSString *)name;
- (void)setName:(NSString *)aName;
// ...
@endAnd by using properties, we end up with this:@interface Person : NSObject {
int age;
Address *address;
NSString *name;
}
@property int age;
@property (retain) Address *address;
@property (copy) NSString *name;
// ...
@endIt's not a giant difference, but it's an improvement. As well as making the code more compact, it separates the logical properties of the class from the rest of the methods. Where @property really starts to pay off is when we combine it with @synthesize. The @implementation for the Person class looks like this:// hand written getter and setter methods
@implementation Person
- (int)age {
return age;
}
// assign-type setter
- (void)setAge:(int)anAge {
age = anAge;
}
- (Address *)address {
return address;
}
// retain-type setter
- (void)setAddress:(Address *)anAddress {
if (address != anAddress) {
[address release];
address = [anAddress retain];
}
}
- (NSString *)name {
return name;
}
// copy-type setter
- (void)setName:(NSString *)aName {
if (name != aName) {
[name release];
name = [aName copy];
}
}
// ...
@endThat's a lot of boilerplate code to churn out, and memory management in the retain and copy type setters makes it more error prone than simple assign type setters. It's just begging to be machine generated, so let's do that:// synthesized getter and setter methods @implementation Person @synthesize age, address, name; // ... @endAll that onerous code can be deleted, and the compiler now generates the correct type of getters and setters based on the attributes of the corresponding
@property directive. Note that to use @synthesize, you must have a corresponding @property in the @interface section. I like to put the property names in a list after @synthesize, but you can have multiple @synthesize lines if you like, with one or several property names per line:@implementation Person @synthesize age; @synthesize address, name; // ... @endIf you need to provide a particular getter or setter yourself, but you want the compiler to write the rest of them, you simply add it to your
@implementation. The compiler looks first to see what you provided before it generates anything. So if we need to do a check when setting the age of a Person instance, we simply write our own setter:// synthesized getter and setter methods
// with one custom setter
@implementation Person
@synthesize age, address, name;
- (void)setAge:(int)anAge {
age = anAge;
if (age >= 55) {
[[JunkMailer sharedJunkMailer] addPersonToAARPMailingList:self];
}
}
// ...
@endThis is great, but sometimes you want the property to have a different name than the instance variable that backs it up. For example, we might call the instance variable ageInYears, but want to call the property age:@interface Person : NSObject {
int ageInYears;
// ...
}
@property int age;
// ...
@end
@implementation Person
@synthesize age, address, name;
// ...
@endThis confuses the compiler and it complains:synthesized property 'age' must either be named the same as a compatible ivar or must explicitly name an ivarSo how do we tell it to use the instance variable
ageInYears when generating the age property? The @synthesize directive has one modifier, which solves our problem:@implementation Person @synthesize age = ageInYears, address, name; // ... @end
@synthesize. Next week, we look at one attribute of @property that we've neglected so far: nonatomic.
 |
Places? (NEW) Category: Entertainment Released Jan 4, 2009 Version: 1.0 1.3 MB $0.99 USD  |
 |
People? (NEW) Category: Entertainment Released Dec 28, 2009 Version: 1.0 1.3 MB $0.99 USD |
 |
Orchard's Craps (NEW) Category: Games Released Oct 2, 2009 Version: 1.0 2.9 MB $0.99 USD |
 |
Hi Ka Flash (NEW) Category: Education Released Aug 15, 2009 Version: 1.0 1.2 MB $0.99 USD |
 |
Fridgemags (NEW) Category: Entertainment Released Jul 24, 2009 Version: 1.0 2.3 MB $0.99 USD |
 |
Animals? (UPDATED) Category: Entertainment Released Mar 17, 2009 Version: 1.1 1.4 MB $0.99 USD |
Posts
All Comments
