XCode accepts it. But will retain be applied when I internally set the property (no setter outside since readonly but when I initialize the value in a class method) ?
Regards,
Apple92
You might specify (readonly, retain) for a publicly-facing property, and then inside your .m, re-define it as (readwrite, retain) to be able to assign to it privately. I use this pattern myself occasionally.
The reason to do this is to allow you to do #property (retain) in a class continuation or category. If you don't have the retain on the outer property, you will get a warning about the properties being mismatched.
it's also nice as a form of interface documentation
Related
Since, ARC is now a standard for many years do I have to write code like this:
#property (nonatomic, retain) NSString *title;
#property (copy) NSString *subtitle;
Or just simplify it to this?
#property NSString *title;
#property NSString *subtitle;
You asked:
Do I have to specify memory management properties with ARC?
In short, if you want anything other than the default behavior, yes you do. The default behavior is atomic and strong. If you want copy behavior, for example, then you must specify copy. If you want non-atomic behavior, then you must specify nonatomic.
So, let us consider the two title renditions:
#property (nonatomic, retain) NSString *title; // nonatomic
#property NSString *title; // defaults to atomic, strong
The two are different insofar as the first is nonatomic and the latter is atomic. Also, the first explicitly uses retain, which in ARC achieves the same behavior as strong. That having been said, we prefer to use strong (instead of retain) in ARC because we now reason about the reference types, not reference counts.
If you really wanted to simplify that first example, you could remove retain and rely on the fact that object properties default to strong, by default.
#property (nonatomic) NSString *title; // strong (by default), nonatomic
And you would only remove nonatomic if you really wanted to introduce the overhead of atomic accessor methods.
Consider these two:
#property (copy) NSString *subtitle; // copy semantics
#property NSString *subtitle; // strong reference only
These two are different that the former employs copy semantics (providing critical protection against NSMutableString references changing behind its back) and the latter does not.
ARC has default property params.
the following 2 property definitions are the same.
#property NSArray *name;
#property (strong, atomic, readwrite) NSArray *name;
I want to show you an example of one of my header files and get your suggestions on what I could do better giving the situations below.
ARC is enabled
#property (nonatomic, assign) int some_simple_value;
#property (nonatomic, strong) NSMutableArray *someArray;
#property (nonatomic, weak) IBOutlet UIButton *someButton;
#property (nonatomic, copy) NSMutableArray *someArrayCopy
#property BOOL some_bool;
I understand what a lot of the types mean, but I don't know why I would use a given one instead of another in some cases. Also, if I know my object is only accessed by one class, should I not use nonatomic (because there's no worry of multiple threads accessing it, right?)
ANSWER
These answers helped me drastically:
What's the difference between the atomic and nonatomic attributes?
and
Objective-C declared #property attributes (nonatomic, copy, strong, weak)
Well, you could read the documentation! :) But if you want a perhaps more friendly instructive explanation, I've written you one:
http://www.apeth.com/iOSBook/ch12.html#_properties_2
However, before you read that, you should really read about memory management, earlier in that chapter:
http://www.apeth.com/iOSBook/ch12.html#_memory_management
strong and weak are very different indeed; if you understand memory management and ARC, you'll know why.
Whats the difference between this:
#property (nonatomic, weak) id <SubClassDelegate> delegate;
and this:
#property (nonatomic, assign) id <SubClassDelegate> delegate;
I want to use property for delegates.
The only difference between weak and assign is that if the object a weak property points to is deallocated, then the value of the weak pointer will be set to nil, so that you never run the risk of accessing garbage. If you use assign, that won't happen, so if the object gets deallocated from under you and you try to access it, you will access garbage.
For Objective-C objects, if you're in an environment where you can use weak, then you should use it.
If I have a read-only string property, is it necessary to specify strong (or retain) or copy in the declaration? If I don't specify, is one of them assumed?
It seems to me the ownership attribute is only useful when you have a setter.
#property (nonatomic, readonly) NSString *name;
That is mostly correct. For a readonly property, strong, retain, weak, and assign have no effect. But if you also declare the property elsewhere as readwrite (most frequently in an anonymous category in the .m), then the other modifiers need to match.
There are two different methods to declare IBOutlet.
In #interface section as variable:
IBOutlet UIButton *exampleButton;
Below the curve bracket but before #end of .h file as property:
#property (nonatomic, retain) IBOutlet UIButton *exampleButton;
What is the difference between these two methods and where should I use each one? Which method is better and in what cases?
Either one works fine in my experience. What doesn't work is declaring both the instance variable and the property "IBOutlet" -- that seems to really confuse things. If for some reason you want to avoid providing public access to your outlet, you can declare it as an instance variable and simply not create the property. On the other hand, now that the runtime will synthesize instance variables for you, many people are declaring only properties and skipping the explicit instance variable declaration; in that case, you'd obviously declare the property as the IBOutlet.
The #property combined with #synthesize setup the getter and setter methods for your objects. You should define it at least in the interface, and if you decide to create a property from it then you must also synthesize it the .m file.