#property #synthesize - iphone

What do #synthesize and #property do in Xcode? Please provide an explanation in really simple terms?

You asked for simple terms:
#property declares a property in your
class header
#property (nonatomic, retain) NSString *myString;
#synthesize creates your setter and
getter for your property (accessor
methods)
Without synthesize you have to write
your own setter and getter
implemention, like getMyString or
setMyString (capitalize the first
character of your property)
Sam: Just an advice: http://www.cocoadevcentral.com/d/learn_objectivec/ is a pretty solid resource to learn about basics like properties.
Good Luck!

Properties and synthesized accessors are new features in Objective-C 2.0.
When you declare a #property you declare somewhat an instance var. Then you #synthesize accessor methods (i.e. getter and setter) for that property.
There are also #dynamic accessors if you're interested.
You should really do your homework on this. Apple has nifty pdf for that.

Think of all objective-c magic as just a "smarter macro", like a "smarter #define statement"
#property if you notice is always in the h file,
#synthesize is always in the m file.
So in the background
#property (whatever) NSString *myString;
becomes a declaration of 2 methods and a private variable;
void set_myString:(NSString *) str;
(NSString*) get_myString;
declarations in the header file
to make them do something their implementation is added into m file when you type in
#synthesize myString;
which becomes something like
void set_myString:(NSString *)str
{
myString = str;
}
(NSString *) get_myString
{
return (myString);
}
But it's smarter than this
depending on if you say "retain" "strong" or "weak"
it will either just return the pointer to the myString or it will copy the myString into a new object
So all of this is done automatically by a compiler just by reading your declarations.
Which is quite useful and saves a lot of time

By default all our variables are Private so we can't acess out of the class.
if we want to use our instance variable in out of the class.
When you declare a #property you declare somewhat an instance var. Then you #synthesize accessor methods (i.e. getter and setter) for that property.
There are also #dynamic accessors if you're interested.

it simply sets the property's setter variable name in it's own class.
For example lets say I have this: #property (nonatomic, copy) NSArray* viewControllers;
Well if i want to access the setter _viewController i wouldn't set a synthesize variable.
but if i want to access the viewController variable by the name viewController instead of _viewController, I would do #synthesize viewController;.
If I wanted to use it as a completely different name I could do this #synthesize viewControllers = viewControlololer; but that's only setter. As you will notice [self viewControllers] only works and not [self viewControlololer];
So I don't understant why everyone writes sets the "setter and getter" of a property. It doesn't change the getter variable at all... unless that means [self viewController] is aware of viewControlololer (obviously).

Actually properties are synthesized, either implicitly or explicitly. Properties are implicitly synthesized. So there's no need to use synthesized unless you wanna change the name of the variable to something different than _property_name.
There are other use cases, for example if you don't want an instance variable to back your property.
Properties are explicitly synthesized by using the #synthesized directive.
(Answer extracted from the Big Nerd Ranch guide)

Related

Assigning Value to dynamic property causes a crash

This is the as to what I am trying to implement in this program
#interface settings : CBLModel
#property (copy) NSString* foo;
- (instancetype) initInDatabase: (CBLDatabase*)database withAllValues:(NSDictionary*)gameDic ChannelId:(NSString*)chann_id;
In .m file I am using this...
#implementation settings
#dynamic foo;
- (instancetype) initInDatabase: (CBLDatabase*)database
withAllValues: (NSDictionary*)gameDic ChannelId:(NSString*)chann_id
{
NSParameterAssert(gameDic);
self = [super initWithNewDocumentInDatabase: database];
if (self) {
self.foo=#"value";//this is where it crashes
}
return self;
}
-(void)setfoo:(NSString *)foo{
foo=[foo copy];//tried doin this but the value is not assigned
}
I am trying to set value of a dynamic property which results in the crash.. I need to use dynamic as I want to reflect it on server and using synthesize doesn't do that.
First of all, your property is in lowercase foo, and the dynamic declaration
in uppercase Foo. This could be a cause for problems. But assuming that this
was just a typo,
#dynamic foo;
tells the compiler that it should not synthesize getter and setter methods for the property.
It is a "promise" that the required accessor methods will somehow be provided at runtime.
Since you don't provide a setter method,
self.foo = #"abc";
must crash at runtime.
So unless you have a definite reason, you can just remove the #dynamic declaration,
and the compiler will synthesize getter, setter, and instance variable, if necessary.
A better answer might be possible if you explain what you are trying to achieve.
Remark: If your custom setFoo: goes into an infinite loop then you probably use the
property setter inside the setter method, instead of accessing the instance variable directly.
A simple example:
-(void)setFoo:(NSString *)foo
{
// wrong: self.foo = [foo copy];
_foo = [foo copy];
}
UPDATE: The above answer was written before I knew that "settings" is a subclass of
"CBLModel" from "Couchbase Lite". I do not have experience with that framework, but from
reading the documentation it seems to me that #dynamic foo; is indeed correct in this case,
and setFoo: should not be implemented in the subclass, because
the Couchbase framework creates the necessary accessor methods at runtime.
The only possible error I can see is that the custom initializer should call
self = [self initWithNewDocumentInDatabase: database];
instead of
self = [super initWithNewDocumentInDatabase: database];
Try to change #property(copy) NSString* foo; with #property (nonatomic, strong) NSString *foo;
#dynamic property indicates that implementation of setter and getter will be provided by some underlying code in runtime. It is commonly used in NSManagedObject subclasses of Core Data. There is no underlying code to manage your #dynamic properties if your object is a subclass of NSObject, so you are responsible for implementing setters and getters. Change #dynamic to #synthesize to let the compiler create appropriate setter and getter for you.
UPD: As of the latest compiler you may omit #synthesize as Martin R said.

Why should we declare variables for #property

I am newbie in Objective. As I read many tutorial, #property has a variable for a type, the same variable is declared in #inferface too. Is this needed?
Example
#interface MyInterface : NSObject
{
NSInteger myVaribale;
}
#property(retain) NSInteger myVariable;
Here myVariable is declared in both place.
since iOS 4, you can write
#interface MyInterface : NSObject {
}
#property(assign) NSInteger myVariable;
#implementation MyInterface
#synthesize myVariable;
#end
Meaning you can omit the NSInteger myVaribale in your interface declaration as long as you synthesize it in the .m (the synthesize will create setter, getter and instance variable)
A drawback is that you won't see the value of myVariable in Xcode's debugger.
As a note, the redeclaration of the ivar's type in the #property statement can also be useful if you want to declare the property as the immutable type of the ivar's, for instance:
#interface MyClass : NSObject
{
NSMutableArray *myArray;
}
#property (retain) NSArray *myArray;
In this instance, the ivar is actually stored as an NSMutableArray, so it can be altered during the object's lifecycle.
However this is an internal detail and if you don't want to "advertise" is as being mutable (changeable), you can make the type of the property the immutable type – in this case an NSArray.
Although this won't actually stop other code using the returned array as mutable, it is good convention and notifies other code that it shouldn't treat it in this way.
It's not an inconvenience but more a basic concept of objc: A class can have member variables. In OOP you normally define getter and setters for member variables which should be available to the outside. In objective-c you are encouraged to define getters/setters at any time (if they should be private, put their declarations into a private interface). To simplify this task, objective-c uses properties which are not more than a abbreviation. Additionally there are things like key-value-coding and -observing which are enabled by properties, but basically, they are just abbreviations for getters and setters.
Conclusion: Inside of #interface you declare members, outside methods including getters/setters (properties).

General Programming Question about properties, assign, retain, and declarations

I was going through the AVCam project from WWDC and I'm curious about the following code. I thought you were supposed to declare an object, then #property (nonatomic,retain), then synthesize.
The Demo code does it a little differently, I'll post some code (just a sample), anyone know what this does and when you should use it? Can anyone explain its significance and when to use it?
#interface AVCamCaptureManager : NSObject {
#private
// Capture Session
AVCaptureSession *_session;
AVCaptureVideoOrientation _orientation;
// Identifiers for connect/disconnect notifications
id _deviceConnectedObserver;
id _deviceDisconnectedObserver;
}
#property (nonatomic,readonly,retain) AVCaptureSession *session;
#property (nonatomic,assign) AVCaptureVideoOrientation orientation;
#property (nonatomic,readonly,retain) AVCaptureAudioChannel *audioChannel;
#property (nonatomic,assign) NSString *sessionPreset;
in the implementation file:
#interface AVCamCaptureManager ()
#property (nonatomic,retain) AVCaptureSession *session;
#property (nonatomic,retain) AVCaptureDeviceInput *videoInput;
#property (nonatomic,retain) AVCaptureDeviceInput *audioInput;
#end
#implementation AVCamCaptureManager
#synthesize session = _session;
#synthesize orientation = _orientation;
#dynamic audioChannel;
#dynamic sessionPreset;
#dynamic focusMode;
- (id) init
{
#property (nonatomic,readonly,retain) AVCaptureSession *session;
This is a property that is readonly externally. Internally, it will have a setter that retains the new value.
#property (nonatomic,assign) AVCaptureVideoOrientation orientation;
This is a property that does a simple assignment to store the new value (since you can't -copy or -retain primitives).
#property (nonatomic,readonly,retain) AVCaptureAudioChannel *audioChannel;
This is a property that is readonly externally. Internally, it will have a setter that retains the new value.
#property (nonatomic,assign) NSString *sessionPreset;
This is a property that does a simple assignment to store the new string value. This is normally not a good idea, unless you're only allowing pre-defined constants for the presets. When dealing with NSString properties, you generally want them to be copy unless you have a good reason against it.
In the implementation file:
#property (nonatomic,retain) AVCaptureSession *session;
#property (nonatomic,retain) AVCaptureDeviceInput *videoInput;
#property (nonatomic,retain) AVCaptureDeviceInput *audioInput;
These are used in conjunction with the properties declared in the header, except now it's readwrite. By declaring the version in the header as readonly, anyone using the class will not have access to the setSession: method. We re-declare this property internally so that we can have access to the setter (and the setter retains the new value). Also, if the property is not present in the header, the user won't know it exists, but we'll still be able to use it internally.
#synthesize session = _session;
#synthesize orientation = _orientation;
This means you want the compiler to generate the appropriate setters and getters for the session and orientation properties, and that you want those properties to store their values in the _session and _orientation instance variables, respectively.
#dynamic audioChannel;
#dynamic sessionPreset;
#dynamic focusMode;
This means that the implementations for the setters and getters will be provided at runtime. You usually don't use #dynamic properties yourself, other than the ones provided by the Core Data framework.
In this code, the session property is defined as readonly outside of the class and readwrite inside the class. By overriding the session property in an unnamed category before synthesizing it, a set accessor will also be synthesized, but the header file says it is readonly so other classes don't know about the set accessor. The category also defines two new properties which are not visible to other classes at all.
The retain and assign keywords tell the compiler how the accessor methods should work. Retain means that the set accessor should retain the value of the property, and the assign keyword tells it to set the property without retaining it. There is also copy, which copies the value and is often used to make sure a mutable value isn't set. The default is assign, but the compiler will issue a warning if nothing is specified for an object property.
Can you explain what you're confused about here? My only guess is you are confused about audioChannel and sessionPreset, as they have no ivars and are declared #dynamic (there's also focusMode, but I don't even see a #property declaration for that in the code you pasted).
In any case, I expect that if you read the rest of the code you'll find that there are getters for -audioChannel and -sessionPreset that have been written, as well as a setter for -setSessionPreset:. Assuming that's the case, then the #dynamic declarations are completely unnecessary. #dynamic is only necessary to tell the compiler that the methods will exist at run-time; if they exist at compile-time then you don't need any directive whatsoever.

When would a instance variable be used and when would a property be used?

In a header file such as this, when would an instance variable be used and when would a property be used?
Do they have to have the same name?
#import <UIKit/UIKit.h>
#class BlueViewController;
#class YellowViewController;
#interface SwitchViewController : UIViewController {
YellowViewController *yellowViewController;
BlueViewController *blueViewController;
}
#property (retain, nonatomic) YellowViewController *yellowViewController;
#property (retain, nonatomic) BlueViewController *blueViewController;
#end
A #property declaration simply creates accessor methods for an ivar. So properties don't really have names, only the accessor methods do; and these don't have to have the same name as the ivar. In fact, they don't even have to have a corresponding ivar.
You can change the names of the methods using the getter and setter decorators like this:
#property (assign, getter=isValid) BOOL valid;
Now, as I said, a #property declaration simply creates accessor methods for an ivar. So you use properties when you want accessor methods. Here are a few reasons why you might want accessor methods:
Encapsulation (a property might be advertised as a different type than the ivar, or might not even have an ivar)
Related state changes (change another ivar or invoke a method when an ivar is modified)
You can use the retain decorator and #synthesize the property to get much simpler memory management
You can use atomic decorator (or simply not use the nonatomic decorator, since properties are atomic by default) to create atomic properties
Here's an example to demonstrate points 1 and 2:
#interface Foo : NSObject {
#private
int flags;
// Humpty and Dumpty are mutually exclusive
BOOL humpty;
BOOL dumpty;
}
#property (nonatomic) BOOL flagA;
#property (nonatomic) BOOL flagB;
#property (nonatomic) BOOL humpty;
#property (nonatomic) BOOL dumpty;
#property (nonatomic, readonly, getter=isClean) BOOL clean;
#end
#implementation Foo
#synthesize humpty, dumpty; // Synthesize the getters, but provide the setters
- (void)setHumpty:(BOOL)value {
if(value && dumpty)
dumpty = NO;
humpty = value;
}
- (void)setDumpty:(BOOL)value {
if(value && humpty)
humpty = NO;
dumpty = value;
}
- (BOOL)flagA {
return flags & 0x01;
}
- (void)setFlagA:(BOOL)value {
if(value)
flags |= 0x01;
else
flags &= ~0x01;
}
- (BOOL)flagB {
return flags & 0x02;
}
- (void)setFlagB:(BOOL)value {
if(value)
flags |= 0x02;
else
flags &= ~0x02;
}
// Making this a property doesn't really make sense
// but I'm just trying to demonstrate what you can do
// with properties
- (BOOL)isClean {
return flags == 0;
}
#end
You want to use the properties for all your external access to provide encapsulation, it's up to you whether you want to use them internally though, i think it's a matter of taste.
By using the properties from outside of your class you can for example do some lazy loading and it becomes a lot easier to make any potential API changes by providing deprecation warnings in the getters/setters.
They can have the same name, although they don't have to. Indeed, it's not required for the externally-visible property to correspond exactly to a single instance variable at all. Such a correspondence is expected if you're going to #synthesize the accessor methods, but there are quite legitimate reasons for creating the methods manually and making them do something other than just getting/setting a matching ivar.
Instance variables are normally not accessible from the outside world, so all external access has to be via the property methods. (It is possible to declare ivars #public, but this is rarely a good idea.)
From within the object, whether you access as properties or instance variables depends on what the properties actually are and what you're doing with them.
For simple synthesized properties it is common to use the accessors (either explicitly using [self setXxx] or using the dot notation as self.xxx) except within dealloc (and possibly init, depending on who you ask).
In more complex cases, you really have to think about what it is you are trying to achieve. But if you've gone to the trouble of making them properties you probably want whatever functionality is encapsulated in the accessor methods to be called most of the time.
At any rate, read the properties documentation to get a better understanding of what's going on.

Object as a data member in Objective C

From what I have experienced it seems as if objects cannot be shared data members in objective c. I know you can init a pointer and alloc the object in each method but I cannot seem to figure out how one can say define a NSMutableString as a data member and allow all of the methods to use and modify its data as in c++. Is this true or am I missing something?
To define an instance variable (member), edit your .h file:
#interface MyClass : NSObject {
// ivars go here
NSObject *member;
}
// methods go here
#end
Then, in your .m file, from any instance method (one which begins with -), you can access this variable.
- (void)doThingWithIvar {
[member doThing];
}
If you want to access the variable from outside the object itself, you'll need accessors. You can do this easily with Obj-C properties:
#interface MyClass : NSObject {
// ivars go here
NSObject *member;
}
// methods go here
#property (nonatomic, retain) NSObject *member;
#end
And in the .m:
#implementation MyClass
#synthesize member;
// ...
#end
The #synthesize line creates getter/setter methods for the ivar. Then you can use property syntax:
MyClass *thing = ...;
NSLog(#"%#", thing.member); // getting
thing.member = obj; // setting
(Note that I specified (retain) for the #property; if your member isn't an Objective-C object you won't want that. And if your property's class has a mutable counterpart, you'll want (copy) instead.)
It sounds like you want to synthesize (create getter/setter methods) a property for a member variable. I just found this cheat sheet, go down to the section called, "Properties", should give a quick overview.
Other than that Apple's documentation should give you more info.