Why are class objects the property attribute of retain and not copy?

Question

I was trying to pass a custom object to the next view controller and I encountered this error -[ClassName copyWithZone:] unrecognized selector sent to instance

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

    if ([segue.identifier isEqualToString:@"attemptDetails"])
    {
        ResultsVC *vc = segue.destinationViewController;
        vc.selectedEntry = selectedEntry;
    }
}

@property (nonatomic, retain) ClassName *selectedEntry; //Why is it retain and not copy?

I'm still very confused with property attributes and why certain types use certain attributes, like NSString uses (nonatomic, copy) and CLLocationCoordinate2D uses (nonatomic, readonly).

Could someone explain or link a reference to me how each property attribute works? Much thanks!

Answer 1

There are lots of descriptions for property attributes explanation,

Reference links,

Objective-C ARC: strong vs retain and weak vs assign

https://stackoverflow.com/a/4511004/4294543

@property and retain, assign, copy, nonatomic in Objective-C

Short & simple my understanding is like,

retain : It's working on the created object, and it just increase the reference count.

• Here in your case you have already model class object so not need to copy in the second vc property,you just need to retain it to second vc property.

copy : The value you assigned to property can be copied & used for other purposes too(create shallow copy of object & need when object is mutable & need to release after finish with it).

nonatomic : Thread access is faster but you can't simultaneously access & change your property.

readonly : You can't directly assign the property new value.

Even i have run your case in the my project,

#import "ViewController.h"
#import "TestViewController.h"
#import "CustomClass.h"
@interface ViewController (){

    CustomClass *classT;
}

@end
@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    classT = [[CustomClass alloc]init];
    classT.test = YES;

}
- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
}
- (IBAction)btn:(id)sender {
    TestViewController * vc = [self.storyboard instantiateViewControllerWithIdentifier:@"TestViewController"];
    vc.className = classT;
    [self presentViewController:vc animated:YES completion:nil];
}
@end




#import <UIKit/UIKit.h>
#import "CustomClass.h"

@interface TestViewController : UIViewController


@property (nonatomic,retain) CustomClass *className; // Work as i said

//@property (nonatomic,copy) CustomClass *className; // Makes a copy of an object, and returns it with retain count of 1. If you copy an object, you own the copy. This applies to any method that contains the word copy where “copy” refers to the object being returned thats why here you will get crash


@end

Answer 2

I have read couple of good article for memory management. According to rypress

Retain Attribute : The retain attribute is the Manual Retain Release version of strong, and it has the exact same effect: claiming ownership of assigned values. You shouldn’t use this in an Automatic Reference Counted environment.

Copy Attribute : The copy attribute is an alternative to strong. Instead of taking ownership of the existing object, it creates a copy of whatever you assign to the property, then takes ownership of that. Only objects that conform to the NSCopying protocol can use this attribute.

Even I went through some good link of stackoverflow as well. Joshua Nozzi's answer gave good explanation for retain vs copy.

Retain vs. Copy - Declared properties use retain by default (so you can simply omit it altogether) and will manage the object's reference count automatically whether another object is assigned to the property or it's set to nil; Use copy to automatically send the newly-assigned object a -copy message (which will create a copy of the passed object and assign that copy to the property instead - useful (even required) in some situations where the assigned object might be modified after being set as a property of some other object (which would mean that modification/mutation would apply to the property as well).

Also found good example here.

Code :

NSMutableArray *array = [[NSMutableArray alloc] initWithObjects:@"First",@"Second", nil];
    NSMutableArray *copiedArray = [array mutableCopy];
    NSMutableArray *retainedArray = [array retain];
    
    [retainedArray addObject:@"Retained Third"];
    [copiedArray addObject:@"Copied Third"];
    
    NSLog(@"array = %@",array);
    NSLog(@"Retained Array = %@",retainedArray);
    NSLog(@"Copied Array = %@",copiedArray);

Output :

array = (
    First,
    Second,
    "Retained Third"
)
2013-12-19 17:15:49.380 RetainVsCopy[2876:c07] Retained Array = (
    First,
    Second,
    "Retained Third"
)
2013-12-19 17:15:49.381 RetainVsCopy[2876:c07] Copied Array = (
    First,
    Second,
    "Copied Third"
)

See, both array and Retained Array are having same contents. This is because both are pointing to same memory/instance/object. Where as contents of Copied Array are different. This is because copy created a separate instance.

Answer 3

In Objective C you will find that each class actually has a structure behind it. The properties are shortcuts which create the value in structure, a getter and a setter. For instance:

@interface MyClass

@property id myValue;

@end

Will create:

@interface MyClass {
   id _myValue;
}

@property id myValue;

@end

@implementation 

- (id)myValue {
    return _myValue;
}
- (void)setMyValue:(id)myValue {
    _myValue = myValue;
}

@end

Now these flags such as retain and copy add additional logic to the setters and getters. Using copy will actually create a setter as:

- (void)setMyValue:(id)myValue {
    _myValue = [myValue copy];
}

Which means that the value must have the copy method implemented. Since your object does not it crashes.

Why to use copy is for safety. This is rarely important for something as strings but it is important for something like an array. So for instance you create a property @property NSArray *myArray; which expects an un-mutable array but the problem is that you can set a mutable array as well: myClassInstance.myArray = [[NSMutableArray alloc] init];. Now 2 modules have the access to the same mutable array. So if the first object starts modifying the array while the other one expects the array to always be the same you may find some issues. For instance MyClass instance may use it as a data source for the table view and at some point the array is mutated but the cells are not added/removed and the table view will cause a crash.

To be honest you can simply leave all of these as default and modify them only when you really need to. The case like above is highly unlikely anyway.