Beginning iOS 7 Development exploring the iOS sdk-navigation Controllers and Table views

Note Notice that the Familynames property is declared using the Copy keyword instead of strong. What's up with that? Why should we be copying arrays willy-nilly? The reason is the potential existence of mutable arrays.

Imagine if we had declared the property using strong, and a outside piece of code passed in an instance of Nsmutablearray To set the value of the Familynames property. If that original caller later decides to change the contents of this array, the Bidrootviewcontroller instance would end up In a inconsistent state, where the contents of Familynames are no longer in sync with what's on the screen! Using copy eliminates, risk, since calling copy on any nsarray (including any mutable subclasses) always gives
us an immutable copy. Also, we don ' t need to worry about the performance impact too much. As it turns out,sending copy to any immutable object doesn ' t actually copy the object. Instead, it returns the same objectafter increasing its reference count. In effect, calling copy on a immutable object is the same as Callingretain, which are what ARC might do behind the scenes Anytime set a strong property. So, it works outjust fine for everyone, since the object can never a change.

This situation applies to all value classes where the base class was immutable, but mutable subclasses exist. These value classes include Nsarray, Nsdictionary, Nsset, NSString, NSData, and a few more.
Any time your want to onto an instance of one of the these in a property, you should probably declare Theproperty ' s Storag E with copy instead of strong to avoid any problems.

Beginning iOS 7 Development exploring the iOS sdk-navigation Controllers and Table views