Q: What are assign, weak, strong properties?

A:

link

strong is the same as retain in a property declaration.
For ARC projects I would use strong instead of retain,
I would use assign for C primitive properties
and user weak for weak references to Objective-C objects.

all the attributes information together:

  • atomic //default
  • nonatomic
  • strong = retain //default (retain for MRC)
  • weak
  • retain
  • assign //default
  • unsafe_unretained
  • copy
  • readonly
  • readwrite //default

1.strong (iOS4 = retain )

  • it says "keep this in the heap until I don't point to it anymore"
  • in other words " I'am the owner, you cannot dealloc this before aim fine with that same as retain"
  • You use strong only if you need to retain the object.
  • By default all instance variables and local variables are strong pointers.
  • We generally use strong for UIViewControllers (UI item's parents)
  • strong is used with ARC and it basically helps you , by not having to worry about the retain count of an object. ARC automatically releases it for you when you are done with it.Using the keyword strong means that you own the object. Example:
    @property (strong, nonatomic) ViewController *viewController;
@synthesize viewController;

2.weak

  • it says "keep this as long as someone else points to it strongly"
  • the same thing as assign, no retain or release A "weak" reference is a reference that you do not retain.
  • We generally use weak for IBOutlets (UIViewController's Childs).This works because the child object only needs to exist as long as the parent object does.
  • a weak reference is a reference that does not protect the referenced object from collection by a garbage collector.
  • Weak is essentially assign, a unretained property. Except the when the object is deallocated the weak pointer is automatically set to nil Example :
    @property (weak, nonatomic) IBOutlet UIButton *myButton;
@synthesize myButton;

Explanation
Imagine our object is a dog, and that the dog wants to run away (be deallocated).
Strong pointers are like a leash on the dog. 
As long as you have the leash attached to the dog, 
the dog will not run away. 
If five people attach their leash to one dog,
 (five strong pointers to one object), 
 then the dog will not run away until all five leashes are detached.

Weak pointers, on the other hand, 
are like little kids pointing at the dog and saying "Look! A dog!" As long as the dog is still on the leash, the little kids can still see the dog, and they'll still point to it. As soon as all the leashes are detached, though, the dog runs away no matter how many little kids are pointing to it.

As soon as the last strong pointer (leash) no longer points to an object, the object will be deallocated, and all weak pointers will be zeroed out.

When we use weak?

The only time you would want to use weak, is if you wanted to avoid retain cycles (e.g. the parent retains the child and the child retains the parent so neither is ever released).

3.retain = strong

it is retained, old value is released and it is assigned retain specifies the new value should be sent
retain on assignment and the old value sent -release
retain is the same as strong.
apple says if you write retain it will auto converted/work like strong only.
methods like "alloc" include an implicit "retain"
Example:

@property (nonatomic, retain) NSString *name;
@synthesize name;

4.assign(ref + 0)

assign is the default and simply performs a variable assignment
assign is a property attribute that tells the compiler how to synthesize the property's setter implementation
I would use assign for C primitive properties and weak for weak references to Objective-C objects.

assign: it doesn't nil out the object when released (set by default)
Example:

@property (nonatomic, assign) NSString *address;
@synthesize address;

5. nonatomic/atomic

nonatomic is much faster than atomic
IMP

always use nonatomic unless you have a very specific requirement for atomic, which should be rare (atomic doesn't guarantee thread safety - only stop accessing the property when it's being set by another thread at the same time)

I’ve made this mistake early on in PSPDFKit. From time to time, the application crashed with a EXCBADACCESS, when the contents property was set to nil after the check. A simple fix for this issue would be to capture the variable:

NSString*contents =self.contents; // this is the fix
if(contents) {
    CFAttributedStringRefstringRef =CFAttributedStringCreate(NULL,(__bridgeCFStringRef)contents,NULL);
    // draw string
}

This would solve the issue here, but in most cases it’s not that simple. Imagine that we also have atextColorproperty and we change both properties on one thread. Then our render thread could end up using the new content along with the old color value and we get a weird combination. This is one reason why Core Data binds model objects to one thread or queue.

IMP

Atomic is more resistant to threading errors. Overall, it is a curious default. The scenarios you would favor atomic for are very few. Atomic can increase the probability of correctness, but it's at too low a level be considered a substitute for a proper locking mechanism. Therefore, if you need thread safety, you still need some other synchronization primitive on top of the atomic reads/writes. If you don't need thread safety (e.g. the instance is immutable or intended to be run from the main thread only), atomic will add nothing.

  • Version 1

properties specified as atomic are guaranteed to always return a fully initialized object. This also happens to be the default state for synthesized properties so, while it is a good practice to specify atomic to remove the potential for confusion. If you leave it off, your properties will sell be atomic.This guarantee of atomic properties comes at a cost to performance. However, if you have a property for which you know that retrieving an uninitialized value is not a risk. For example, if all access to the property is already synchronized via other means. Then setting it to nonatomic can gain you bit of performance.

  • Version 2 better

Atomic and non-atomic refers to whether the setters/getters for a property will atomically read and write values to the property. When the atomic keyword is used on a property, any access to it will be “synchronized”. Therefore a call to the getter will be guaranteed to return a valid value, however this does come with a small performance penalty. Hence in some situations nonatomic is used to provide faster access to a property, but there is a chance of a race condition causing the property to be nil under rare circumstances (when a value is being set from another thread and the old value was released from memory but the new value hasn’t yet been fully assigned to the location in memory for the property).

6. strong/weak/assign

use strong to retain objects - although the keyword retain is synonymous, it's best to use strong instead
use weak if you only want a pointer to the object without retaining it

weak - useful for avoid retain cycles (ie. delegates) - it will automatically nil out the pointer when the object is released

use assign for primitives - exactly like weak except it doesn't nil out the object when released (set by default)

7. copy (retain + 1 for local copy)

use it for creating a shallow copy of the object
good practice to always set immutable properties to copy -

because mutable versions can be passed into immutable properties, copy will ensure that you'll always be dealing with an immutable object

if an immutable object is passed in, it will retain it (immutable doesnot need to copy)

if a mutable object is passed in, it will copy it

  • It is similar to strong, but instead of increasing the retain count and claiming ownership of an object, it copies the value of the object that it is assigned to, and takes strong ownership of that copy. The object must conform to the NSCopying protocol to allow this to work.
  • Why NSString, NSArray, NSDict, NSSet need a copy attribute?
  • Because other class can pass a NSMutableString to the NSString property. So if we use "Strong" , other class can modified the NSString passed in. However, currently still think that the NSString is immutable

8. unsafe_unretained

A pre-ARC attribute. This is similar to “weak”, but did not automatically set their value to nil if the referenced object was destroyed (as mentioned earlier). You should not use this in an ARC project.

9. readonly

use it to disable setting of the property (prevents code from compiling if there's an infraction)
you can change what's delivered by the getter by either changing the variable directly via its instance variable, or within the getter method itself

results matching ""

    No results matching ""