This question already has answers here:
When should I use #synthesize explicitly?
(7 answers)
Closed 8 years ago.
I am having some difficulty understanding what objects are supposed to be synthesized. For example:
#interface DoSomething : UIView
#property (strong, nonatomic) UIColor *frameColor;
#property BOOL toggleScrollability;
- (void) changeBackgroundColorOfView;
#end
In the .m file, which of these three items should be synthesized? Is there any disadvantage if I try and synthesize them all? In general, what is the rule of thumb for what objects you are supposed to synthesize?
The first two are properties; the third is an instance method. #synthesize applies only to properties.
However, if you're building for iOS 6 or newer, you don't need to synthesize at all. The compiler has handled this automatically for the last few years now.
You can only synthesize properties, so you won't be able to write #synthesize changeBackgroundColorOfView.
Since XCode 4 I think, you don't have to use #synthesize anymore. The compiler automatically add it when it needs to be and you can access it by adding a _ before the name of your property.
In your example, you will access the frameColor property as _frameColor if you are in the DoSomething class, doSomethingInstance.frameColor if not.
But, you can always add it yourself if you want to rename your property for internal stuff.
See Apple's reference.
Related
This question already has answers here:
How to make a real private instance variable?
(7 answers)
Closed 8 years ago.
How exactly should attributes be declared if they are needed to be private and the language supports automatic getter/setter method creation?
Is the only way to override the automatically created getter or setter as needed?
In the top of the .m (implementation) file:
// Private category on your class, declared at top of implementation file.
#interface MyClass ()
#property (nonatomic, copy) NSString * privateString;
#end
#implementation
...
#end
These "private properties" are visible only within your implementation.
Please note that ObjC has no facility for runtime access restriction. Other objects can still call your private getters and setters if they want to (although this will generate compiler warnings).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iOS: must every iVar really be property?
I really would appreciate if somebody could explain to me why some properties are defined in the interface statement and some as #property ones.
#interface PlacesParser : NSObject
{
NSMutableArray *arrPlaces;
TBXML *tbxml;
}
#property(nonatomic,retain) NSMutableArray *arrPlaces;
-(void)loadRecords:(NSString *)records;
-(void)traverseElement:(TBXMLElement *)element;
#end
In my example we got "arrPlaces" as #property
and "arrPlaces" within the interface.
The thing in the interface is not actually a property, it is just a plain old instance variable. The #property statement is what makes it a property (giving you the setters and getters). You used to need both, but you don't anymore. If you want your field to be a property with those generated methods, you can leave out the initial field declaration.
What is the difference between ivars and properties in Objective-C
This thread really opened my eyes. Great explonation to my question.
I saw this code snippet on the Internet (http://iphonedevelopment.blogspot.com/2008/12/outlets-property-vs-instance-variable.html):
#import <UIKit/UIKit.h>
#interface MyViewController : UIViewController {
UILabel *myLabel;
}
#property (nonatomic, retain) IBOutlet UILabel *myLabel;
#end
My question is...When #synthesize is called isn't the UILabel instance variable created automatically? What is the point of creating the instance variable in the header file.. Can you get away with just the #property?
When #synthesize is called isn't the UILabel instance variable created automatically?
Yes.
What is the point of creating the instance variable in the header file.
Personal preference. Some developers (like me) prefer to see a complete picture of the state of a class. It helps to see what instance variables are available, as well as check that all instance variables are released correctly.
It's also a relatively new feature. Older code wouldn't expect automatically-generated instance variables.
Can you get away with just the #property?
No, you need to #synthesize to get an automatically generated instance variables A property value that's generated programmatically would not map directly to any instance variable.
#synthesize will create the instance variable but you will not be able to see it in the debugger which can be downright inconvenient.
Consider filing a bug with Apple about this.
Yes you can get away with just the #property in Objective-c 2.0.
see: Do declared properties require a corresponding instance variable?
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Synthesized property and variable with underscore prefix: what does this mean?
The usage of Objective-C properties has always felt awkward to me. It's one of the "I know how to use them, but I'm not always sure why I'm using them." kind of things and recently I've been seeing a lot of this:
// in .h file
#interface MyObject : NSObject
{
id _coolIvar;
}
#property (assign) id coolIvar;
#end
// in .m file
#implementation
#synthesize coolIvar = _coolIvar;// <- whats the point of that.
#end
So what is the point of declaring an ivar with an underscore and then using #synthesize to access it, Opposed to just declaring the #property with the same name as the ivar?
Side Question:
I've noticed that this convention has been becoming increasingly more popular since blocks started becoming the preferred approach for async callbacks opposed to the target/selector approach. Is that a coincidence or does the above #property declaration convention play nicer with block scopes?
It's preference.
It's also my preference to not declare the variables twice and just let them be synthesized like:
// in .h file
#interface MyObject : NSObject
#property (assign) id coolIvar;
#end
// in .m file
#implementation
#synthesize coolIvar = _coolIvar;
#end
The two reasons I like to use the _ prefix is
I know when I am going through an accessor and when I am accessing the variable straight.
If it makes sense for me to call an ivar address it is more than likely that inside a method a similar variable would also be logically called address. If my ivar does not have an _ prefix then my local address will mask the ivar address.
I also like how xcode will autocomplete vaiables starting with an _ when you start typing your #synthesize myVar = _...
NB
You may run into the odd name clash (I have only once) but the warning that the complier gives you makes it a pretty easy spot and simply changing the name is a quick win.
#isaac touched on not declaring ivars so that they are not publicly advertised but does not explain how/why. Basically you can declare #property's in a class extension to still give you the benefits of the #synthesized getter/setter but without making your public API look ugly.
Your previous example would look like this (if you wanted coolIvar to not be publicaly advertised):
// in .h file
#interface MyObject : NSObject
#end
// in .m file
#interface MyObject () <-- Like a category but with no name
#property (assign) id coolIvar;
#end
#implementation
#synthesize coolIvar = _coolIvar;
#end
I use the _ivar construct to make sure that I don't access the ivar directly (by mistake) when I really intend to go through the accessors.
With the modern runtime (iPhone applications and 64-bit programs on Mac OS X v10.5 and later) the ivar declaration is no longer required. So your code is reduced to:
// in .h file
#interface MyObject : NSObject
#property (assign) id coolIvar;
#end
// in .m file
#implementation
#synthesize coolIvar = _coolIvar;
#end
Per #Monolo's answer, the _ivar is a good failsafe to make sure you don't inadvertently access the ivar directly. Remember, the #property and #synthesize is there to replace boilerplate code - without it you'd have to code getter and setter accessors.
There are a couple benefits to differentiating ivars from property accessors.
One is described by Monolo - it prevents mistakingly accessing an ivar when what you intended to access was a property.
Another is that in theory it guards against collisions - cases where you might name an ivar identically to another ivar that's beyond your implementation (ie, a superclass ivar name).
There are different thoughts on best practices, but lately I've read in several places I consider reliable that the best practice is actually to no longer to declare ivars at all in your interfaces (ivars are created implicitly via the property declaration).
Some people don't like "implicit" - but there are material benefits: Not declaring them avoids advertising ivars that aren't really public. It also goes even further in avoiding collisions - because in theory when a property is synthesized and the ivar generated, it will do so without introducing a convention that may itself collide with a private ivar naming convention (as may be the case with preceding or trailing underscore).
Preference. Some people like to prefix instance variables with a underscore (so one can easily tell if one is referencing a ivar, or a variable in a more local scope), and some don't.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
#property #synthesize
Explain the working or purpose of synthesize
Basically, #synthesize automatically generates the getters and setters based on the #property declaration.
synthesize used with property.When you declair a property in .h file then you need to synthesize that in .m file.
#synthesize creates getter and setter for your property.If you do not synthesize the property then you can use property.(it gives crash).
var=self.yourProperty (calling getter). simmiler to var=[self getYourProperty];
self.yourProperty=var (calling setter). simmiler to [self setYourProperty:var];
without synthesize you cant use the setter and getter.