views:

63

answers:

4

I am still finding my feet with objective-c and was wondering if its acceptable to use @property on the two objects below.

#import <UIKit/UIKit.h>
#import <MapKit/MapKit.h>

@interface MapViewController : UIViewController <MKMapViewDelegate, CLLocationManagerDelegate> {
    CLLocationManager *locationManager;
    IBOutlet MKMapView *googleMapView;
}
@property(nonatomic, retain) CLLocationManager *locationManager;
@property(nonatomic, retain) MKMapView *googleMapView;
@end

One of my reasons for using them is so that I can use the setters in my viewDidUnload, I seem to be using @property a lot and was just wondering if the use in this situation is acceptable?

-(void)viewDidUnload {
    [self setLocationManager:nil];
    [self setGoogleMapView:nil];
    [super viewDidUnload];
}

much appreciated

Gary

+3  A: 

Yes. @property is extremely common. You shouldn't be surprised to use it a lot. Your viewDidUnload is exactly correct.

Rob Napier
Can I just ask, if those two variables were not declared as @property how would the viewDidUnload look? Would you [locationManager release]; locationManager = nil; and the same for googleMapView?
fuzzygoat
@fuzzygoat that's fine for cleaning up, but how would you set it?
mustISignUp
I guess you would have to set them directly (i.e.) locationManager = [[CLLocationManager alloc] init];
fuzzygoat
@fuzzygoat exactly, and if you needed to be able to set it from another object you would have to write a setter method. These setter methods are often 'boiler plate' code. The same code all over the place with just the name of the variable being set changing. Using @property helps to clean up this boiler plate code.
mustISignUp
A: 

That seems totally fine with me.

The only case I can think of where it would not be acceptable would be if these properties had to be private. It is a bit trickier to make properties private, but is essential practice to hide the internals of the class from abuse!

Mongus Pong
+1  A: 

Assuming you use @synthesize as well, then this is exactly what you should use it for. Don't get too hung up about 'nonatomic' and of course you could use the dot syntax if you like

self.locationManager = nil;
mustISignUp
It should be self.LocationManager = nil; You lose the set when you use the . notation.. ;)
Mongus Pong
thanks @Marcus i corrected my answer
mustISignUp
Thank you, I don't have anything against dot notation, but when I started learning I decided to stick with the bracket notation until I more fully understood the language.
fuzzygoat
That's cool. Then you should be able to appreciate that the combined @property and @synthesize are simply shortcuts to manually writing the accessor methods. Without the @property you would need to add accessor methods to get or set locationManager from another object. If locationManager never needed to be set or read from outside your MapViewController instance you would need to init and later release it.
mustISignUp
@fuzzygoat: don't feel you have to use the dot notation. I find it just muddies the water and obscures what is really going on. I think it was a mistake for Apple to even invent it.
JeremyP
@jeremyP That is one way to look at it, but i believe what the designers of it were trying to do (ok i'm guessing) is differentiate between Properties of an object and it's ivars. So, use [] to send messages and dot syntax to set and get Properties, which may or may not be implemented with iVars. In my opinion it makes it clearer. ie myView.position = centrePt; [myView print:self];
mustISignUp
A: 

Just a note, but you can also use the IBOutlet keyword in property declarations. Not important in this case, but if you were synthesizing the ivars rather than declaring them explicitly, you'd need the keyword for IB to automatically see the outlet.

jshier