8

I'm still new to Objective-C and having some difficulties trying to figure out the appropriate way to use assign, retain, copy, strong, etc. when setting a property.

For example, I have the following types declared - how should I be setting the properties?

@property (nonatomic, ??) NSMutableArray *myArray
@property (nonatomic, ??) NSString *myString
@property (nonatomic, ??) UIColor *myColor
@property (nonatomic, ??) int *myIn
@property (nonatomic, ??) BOOL *myBOOL

Thanks....

wayneh
  • 4,393
  • 9
  • 35
  • 70

2 Answers2

20

To reiterate, it does depend on context. In an non-ARC situation:

@property (nonatomic, copy) NSMutableArray *myArray
@property (nonatomic, copy) NSString *myString
@property (nonatomic, retain) UIColor *myColor
//Note the change to an int rather than a pointer to an int
@property (nonatomic, assign) int myInt
//Note the change to an int rather than a pointer to an int
@property (nonatomic, assign) BOOL myBOOL

The copy on myArray is to prevent modification by another "owner" of the object you set. In an ARC project, things change a bit:

@property (nonatomic, copy) NSMutableArray *myArray
@property (nonatomic, copy) NSString *myString
@property (nonatomic, strong) UIColor *myColor
//Note the change to an int rather than a pointer to an int
@property (nonatomic, assign) int myInt
//Note the change to an int rather than a pointer to an int
@property (nonatomic, assign) BOOL myBOOL

The change is primarily to myColor in your situation. You wouldn't use retain as you aren't managing reference counting directly. The strong keyword is a way of asserting "ownership" of the property and similar to retain. An additional keyword is also provided, weak, that would typically be used in place of assign for object types. Apple's common example of a weak property is for delegates. I'd recommend going through the Transitioning to ARC Release Notes in addition to the Memory Management Guide a time or two as there is more nuance than can easily be covered in an SO post.

esqew
  • 42,425
  • 27
  • 92
  • 132
David Schaefgen
  • 800
  • 7
  • 9
  • Thanks David. Just to point out though, using `strong` is more than just "similar" to `retain`, it's a direct synonym (which I'm sure you already knew, just wanted to spell this out for other readers) http://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4 – dooleyo Aug 14 '13 at 06:38
0
@property (nonatomic, copy) NSMutableArray *myArray
@property (nonatomic, copy) NSString *myString
@property (nonatomic, retain) UIColor *myColor
@property (nonatomic) int myIn
@property (nonatomic) BOOL myBOOL

copy mutable objects, or objects with mutable subclasses such as NSString: this stops them being modified by another owner. although i don't think its recommended by apple to use mutable objects as properties

other objects are generally retained, with an exception being delegates, which are assigned to prevent ownership loops

primitives like int and BOOL are assigned, this is the default option for @property so doesnt need to be specified, although it doesnt hurt to add it in if you feel it helps the readability

wattson12
  • 11,176
  • 2
  • 32
  • 34
  • 2
    Why would using a mutable object as a property not be recommended by Apple? (I should clarify that these are in a Singleton) – wayneh Jan 27 '12 at 15:58
  • i think its a safety thing, say you pass a NSMutableString to an object which retains it. That object can now modify your data (that may be what you want if they're your classes, but if not its safer to stick to immutable types). its more of a recommendation than a hard rule – wattson12 Jan 27 '12 at 16:09
  • I see. I'm using these in my classes as a Singleton and they do need to be changed. I'm trying to set up an immutable array as well, but having issues. Thanks for your help. http://stackoverflow.com/questions/9026679/can-i-init-an-nsarray-in-a-singleton-with-specific-values-like-a-const – wayneh Jan 27 '12 at 16:13
  • 1
    @wattson the whole point of declaring mutable objects as copied properties is to avoid another owner modifying them. As long as you copy them (which is Apple's recommendation), there is no reason not to use them as properties. – UIAdam Jan 27 '12 at 17:20
  • @UIAdam you're right, copying them is safe. but i was thinking if you've got a mutable property then an object with a reference to your class could change the data, this may be how it was designed but it doesnt seem like very good encapsulation to me – wattson12 Jan 27 '12 at 17:25
  • Sure, another class can still access your copied version of the object and mess with it. You could always declare your own getter method that also returns a copy of the object if you want to be really safe. – UIAdam Jan 27 '12 at 17:47
  • yeah thats probably a good way to go. more of a general programming thing than apple specific restriction. and not really related to this question... – wattson12 Jan 28 '12 at 12:23