I understand that normally you use copy for NSStrings, so that your property stays as the same value as when you assigned it, even when there’s an attempt to re-set it somewhere else.
But I am having hard time completely understanding this concept. Doesn’t this apply to basically any kind of object (not just NSStrings)?
So my question is, “What kind of properties should I set as ‘copy’, and why?”
Objects that are simple bits of data, like strings, that won’t have references to a ton of other objects in your application are great for copying.
Now you can, of course, retain things like strings instead. This will work fine. But what if you had a mutable string instead, and you modified it. Now every other object that had a reference to that string will see that modification. This may not be what you want. This is one reason copying is “simpler”, because any changes to that data is localized to just that bit of code.
On the other hand, lets say you have a instance of a class you wrote for your app. It has references to other objects in your app, it has a ton of it’s own strings or other values in it, and it’s a complex beast. Now copying this object may not be a good idea. Chances are that if you modify this object then you want the changes to propogate to every object that holds a reference. And even if you did copy it, do you need a shallow copy (a new instance but it’s ivars references the same objects) or a deep copy (a new instance containing containing new copies of every ivar)? And the object in question may not even support
<NSCopying>, meaning it can’t technically be copied at all.So to sum up:
copy: Objects that are small, atomic bits of data without any internal references to other objects.retain: Nearly every other kind of object.