This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iOS: must every iVar really be property?
I really would appreciate if somebody could explain to me why some properties are defined in the interface statement and some as #property ones.
#interface PlacesParser : NSObject
{
NSMutableArray *arrPlaces;
TBXML *tbxml;
}
#property(nonatomic,retain) NSMutableArray *arrPlaces;
-(void)loadRecords:(NSString *)records;
-(void)traverseElement:(TBXMLElement *)element;
#end
In my example we got "arrPlaces" as #property
and "arrPlaces" within the interface.
The thing in the interface is not actually a property, it is just a plain old instance variable. The #property statement is what makes it a property (giving you the setters and getters). You used to need both, but you don't anymore. If you want your field to be a property with those generated methods, you can leave out the initial field declaration.
What is the difference between ivars and properties in Objective-C
This thread really opened my eyes. Great explonation to my question.
Related
This question already has answers here:
When should I use #synthesize explicitly?
(7 answers)
Closed 8 years ago.
I am having some difficulty understanding what objects are supposed to be synthesized. For example:
#interface DoSomething : UIView
#property (strong, nonatomic) UIColor *frameColor;
#property BOOL toggleScrollability;
- (void) changeBackgroundColorOfView;
#end
In the .m file, which of these three items should be synthesized? Is there any disadvantage if I try and synthesize them all? In general, what is the rule of thumb for what objects you are supposed to synthesize?
The first two are properties; the third is an instance method. #synthesize applies only to properties.
However, if you're building for iOS 6 or newer, you don't need to synthesize at all. The compiler has handled this automatically for the last few years now.
You can only synthesize properties, so you won't be able to write #synthesize changeBackgroundColorOfView.
Since XCode 4 I think, you don't have to use #synthesize anymore. The compiler automatically add it when it needs to be and you can access it by adding a _ before the name of your property.
In your example, you will access the frameColor property as _frameColor if you are in the DoSomething class, doSomethingInstance.frameColor if not.
But, you can always add it yourself if you want to rename your property for internal stuff.
See Apple's reference.
This question already has answers here:
How does an underscore in front of a variable in a cocoa objective-c class work?
(9 answers)
Closed 9 years ago.
I have created a UIViewController in the .h file named myViewController.
Should I refer to it in the .m file with self.myViewController or _myViewController (being autosynthesized with that name).
Is it a personal preference or is there any difference between the two? If so, what is the difference?
Sorry for asking a strange question, but I didn't know how to google this.
Basics
Using the dot syntax is completely different from using the auto-synthesized underscore-prefixed instance variable!
When you declare a property (let's say name of type NSString *) in a class Person you get implicitly this:
#interface Person : NSObject
// #property (copy) NSString *name;
// Results in
- (NSString *)name;
- (void)setName:(NSString *)name;
#end
Plus the implementation of these methods which do nothing different than setting _name. _name is an private instance variable which is created when a property is synthesized (obviously if the property has the name viewController the name of the ivar is _viewController).
So using the “dot syntax” calls one of the two generated methods, depending on whether you assign a value or read a value.
If you want you can give the underlying ivar a different name by explicitly synthesizing the property and assigning a new name.
#implementation Person
#synthesize name = nameOfThisPerson_ivar;
...
#end
Now you won't see _name any more in the code completion but nameOfThisPerson_ivar.
Or you can implement your own name and setName: methods (or just one) but then you have to assign the value yourself (in the setter) and you have to copy it yourself, if the property's attribute is copy; if your property should be atomic, this has to be implemented by you and so on.
So what to use?
Prior to ARC you should always use the dot notation which actually calls one of the two generated methods because there the retain/release memory management was implemented for you. And I think you should still use properties because then you can e.g.
easily implement Lazy initialization
you can easily have thread safety (just by not specifying nonatomic in your properties' attributes)
and a lot of other stuff …
Edit
As Catfish_Man pointed out in the comments atomic properties do not guarantee thread safety
This question already has answers here:
How to make a real private instance variable?
(7 answers)
Closed 8 years ago.
How exactly should attributes be declared if they are needed to be private and the language supports automatic getter/setter method creation?
Is the only way to override the automatically created getter or setter as needed?
In the top of the .m (implementation) file:
// Private category on your class, declared at top of implementation file.
#interface MyClass ()
#property (nonatomic, copy) NSString * privateString;
#end
#implementation
...
#end
These "private properties" are visible only within your implementation.
Please note that ObjC has no facility for runtime access restriction. Other objects can still call your private getters and setters if they want to (although this will generate compiler warnings).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iOS: must every iVar really be property?
I just read a book that said that modern convention is not to declare any ivars at all in your .h file between curly braces, and instead to make everything properties.
I want to make sure this is true even in trivial cases. I am making a class where there is a BOOL named "recording" which says whether the device is currently recording some video. This isn't something that other classes need, and my incline is to just put it as a BOOL in the header then refer to it in the .m file in the 2 spots where it is needed.
However, I also want to do things the accepted, right way. But I don't see why I make it a public property?
What you read is wrong, plain and simple.
Modern convention is to skip ivars when there is a corresponding property that can synthesize them. Additionally, with recent versions of LLVM it is possible to move your ivars to your implementation file (as #DrummerB has already mentioned) so that the header contains no ivars. That's considered good practice because it doesn't expose internal workings of the class.
But have no ivars at all and a property for everything that was an ivar? Nope, not normal Objective-C.
Your book is right (and wrong). Don't declare ivars in your headers anymore. That's only supported for compatibility reasons. But also don't declare properties for private variables.
If you want do declare a private ivar that other classes don't need to use, declare them in your implementation file:
// MyClass.m
#implementation {
BOOL recording;
}
// methods
#end
I recommend to not use ivar at all. Instead you can create a class extension in which you will declare properties that has to be hidden:
#interface MyClass ()
#property (nonatomic, assign) BOOL recording;
#end
You could use something like
#interface G4AppDelegate ()
#property (nonatomic, assign) BOOL recording;
#end
To make an "internal" property.
Or as the other answer states use an iVar in your implementation
Some books explain that you should only use getter and setter to access your ivar, even if they are private. This is a little too psychotique to me.
Before clang, u should have to create category on class and use synthesizer to make ur ivar private. like this:
#interface AppDelegate ()
#property(nonatomic, assign)int aValue;
#end
// + #implement AppDelegate
// #synthetise aValue;
that could be annoying since sometime u need some simple ivar, without any getter/setter control. And u're adding code where there is no need.
Now with clang you can put ur ivar directly on implementation file like this in ur code:
#interface AppDelegate (){
int _aValue;
}
#end
And u're hiding private ivar out of the scope the header.
Note, u can't compile this with gcc.
This question already has answers here:
Why are Objective-C delegates usually given the property assign instead of retain?
(4 answers)
Closed 8 years ago.
Let's say I have a class called colorPicker which holds a delegate to notify about color changes.
Does the property for this delegate need to be set to retain or assign? WHY?
#interface ColorPicker : UIView
#property (nonatomic, retain) NSObject <ColorPickerDelegate> *delegate;
#end
Short: use assign to avoid retain cycles.
Retaining an object creates a strong reference, and an object cannot be deallocated until all of its strong references are released. If two objects retain each other, neither object ever gets deallocated because the connection between them cannot be broken (source)
Long: Why are Objective-C delegates usually given the property assign instead of retain?