This question already has answers here:
What's the difference between the atomic and nonatomic attributes?
(27 answers)
Closed 9 years ago.
What is the difference between atomic and nonatomic properties, and what does it have to do with retaining it?
I know what #property(retain) is, defined in this website: The #property is an Objective-C directive which declares the property. The "retain" in the parenthesis specifies that the setter should retain the input value, and the rest of the line simply specifies the type and the name of the property.
So #property(retain) does what was stated above, but how does nonatomic/atomic function with the retain property?
#property(nonatomic, retain)
#property(atomic, retain)
retain and atomic/nonatomic are orthogonal, meaning that any combination of them is valid. retain says that there is a strong link between the object and its retained property (i.e. the object referenced by the property should not be released while it is pointed to by this object). atomic/nonatomic means that the access to the property should or should not be synchronized. Here is a great explanation of the atomic/nonatomic.
Note that all of this is meaningful only when you use #synthesize.
Related
This question already has answers here:
Objective-C declared #property attributes (nonatomic, copy, strong, weak)
(4 answers)
Closed 9 years ago.
What is the difference between strong vs copy in objective-c? Which one should i be using?
I know copy prevents the value of the instance variable from changing if set with a mutable string that is later changed itself. Anything else?
strong increases retain counter of an object by 1.
copy creates an object's copy with retain counter 1.
If you use ARC you can't access to retain counter, but the approach is the same as for MRC.
This question already has answers here:
Objective-C declared #property attributes (nonatomic, copy, strong, weak)
(4 answers)
Closed 9 years ago.
How to quickly know which attribute to add to a #property ?
I got it for #property (strong) and #property (weak), I think : strong if the class "owns" the referred-to instance ; weak if it is just a reference to an object whose existence is not managed to our current class.
If the property is created by dragging-and-dropping from Interface Builder, sometimes there is the cryptic unretain_unsafe or so. It sounds so complicated to me, but I believe Xcode knows what it does...
I also kind of understand that retain, assign are kind of deprecated...
And that it is better (compulsory) to use copy for NSString attributes...
But what if I want to have a #property to an int or an enum ?
Shall I choose the weak attribute if my #property points to a singleton ?
You see : so many questions for theses attributes !
I thought it would be nice to have a short and clear explanation of these attributes as some members here do :)
A few notes in no particular order
weak has the additional features of being nil-ed out when the referred-to object is deallocated, so you are never left with a dangling pointer to garbage
It is not compulsory to use copy semantics with an NSString property, but it is highly recommended. While NSString is immutable, your property might be set to a mutable string subclass, so if you don't want it changing out from under you, you should use copy
The rule of thumb for scalar property types is pretty simple: they are not reference counted, so neither strong nor weak applies. But they can be readonly or readwrite, depending on what you need.
It is strange that in Big Nerd Ranch iOS 5 book (p.73) and Programming iOS 5 book (O'Reilly, p.314) (updadte: even Kochan's Objective-C book Fourth edition), in the context of ARC, they say the default for properties attribute is assign... But Apple's documentation says the default is strong.
I also tried a simple program where if I don't specify strong, the program works ok, and if I specify strong, it works the same, and when assign is used instead, the compiler shows a warning, so it seems the default is indeed strong.
So if most of the time, we want
#property (nonatomic, readwrite, strong) NSMutableArray *foo;
then we can just write
#property (nonatomic) NSMutableArray *foo;
as the other two (readwrite and strong) are the default?
readwrite and strong, are indeed the default under ARC*. Under manual reference counting, assign was (is) the default. I prefer to explicitly specify these, because it makes it clearer what the #property's parameters are instead of relying on the person reading the code knowing what the defaults are.
*strong is the default assuming you've either let the compiler synthesize an instance variable for you, or have declared an instance variable without an explicit ownership qualifier (in which case the ivar is __strong by default anyway). Otherwise, the default property ownership type matches the ownership qualifier in the ivar's declaration. So, if you explicitly declare an ivar with __weak, then declare an #property for it without an ownership qualifier, the synthesized property will be weak. This is all documented in the Clang ARC documentation.
By default, an object property is strong, atomic, readwrite. See
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
When do I need to have both iVar and a property?
I keep seeing the following in objective-C code.
#interface Contact : RKObject {
NSNumber* _identifier;
NSString* _name;
NSString* _company;
}
#property (nonatomic, retain) NSNumber* identifier;
#property (nonatomic, retain) NSString* name;
#property (nonatomic, retain) NSString* company;
Why is the bit inside of the block with the interface also required? Is that instead of using #synthesize?
The block inside the #interface are the ivars for your class, while the 3 elements below it are the properties, that is accessors (getters and setters) for your ivars.
You typically access an object’s properties (in the sense of its
attributes and relationships) through a pair of accessor
(getter/setter) methods. By using accessor methods, you adhere to the
principle of encapsulation. You can exercise tight
control of the behavior of the getter/setter pair and the underlying
state management while clients of the API remain insulated from the
implementation changes.
Although using accessor methods therefore has significant advantages,
writing accessor methods is a tedious process. Moreover, aspects of
the property that may be important to consumers of the API are left
obscured—such as whether the accessor methods are thread-safe or
whether new values are copied when set.
Declared properties address these issues by providing the following
features:
The property declaration provides a clear, explicit specification of how the accessor methods behave.
The compiler can synthesize accessor methods for you, according to the specification you provide in the declaration.
Properties are represented syntactically as identifiers and are scoped, so the compiler can detect use of undeclared properties.
Reference : https://developer.apple.com/library/mac/#documentation/cocoa/conceptual/objectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW1
Extending Dr. kameleon's answer, the iVars are unnecessary in this case, as they can be declared explicitly at the #synthesize line. For instance, #synthesize name = _name would be the same as declaring the iVar in the .h (note that the property is required for this syntax). Neither one is more OK than the other, one is just more efficient coding.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
#property #synthesize
When must I use property and synthesize for an element as NSArray, NSSTring....or IBOutelt as UIButton or UITextFiled?
A property is used mainly when other objects need to change or access the ivars in your object. Without manually defining getters and setters, or using #property, other objects can't see or change the ivars. Properties are also often used for convenience of memory management, assisting you in preventing memory leaks.