Difference Between Declaring a Variable Under @Implementation And @Interface Under .m file

Question

I have been learning Objective-C for awhile. From what I learned, I know that when you declare a variable inside @interface in the .h file, the

Answer 1

When you declare the property in the @interface MyObject (){} you are declaring it in what's called an annonymous or class category. Because it's declared in the .m file, it's only visible within that file (no other classes can see it). However, you could have just as well declared this category in your .h file, in which case, it would be visible to other classes.

Declaring NSInteger intData inside the @implementation part of your class isn't actually declaring an instance variable. It's declaring a global variable, which means there is a single instance of it that is shared by your whole application, or, if you'd like to look at it this way, all instances of your class (since it is the only one aware of this global variable).

Answer 2

First off, you're not declaring a variable; you're declaring a property. A property is backed by an instance-variable, but it also adds methods. Here's an explanation of the places to put variables:

@interface MyClass : NSObject {
    NSInteger i ;
}
@end

This is a place to put an instance variable on your class. It is only accessible by methods of your class and categories. (Sidenote: it CAN be made accessible externally, but that's not a recommended practice)

Another example:

@interface MyClass : NSObject
@end

@implementation MyClass {
    NSInteger i ;
}
@end

This is also an instance variable, but is only accessibly by methods written inside that block. (Sidenote: it can be accessed by digging through the class definition, but that's not a recommended (or common) practice)

Another example:

@interface MyClass : NSObject
@property NSInteger i ;
@end

Is the same as:

@interface MyClass : NSObject {
    NSInteger _i ; // you are not allowed to access it by this variable
}
- (NSInteger) i ;
- (void) setI:(NSInteger)value ;
@end

This is a property people are allowed to get and set. You use that variable in your methods or in other methods as:

NSLog ( @"The value is %i" , self.i ) ; // if it's your instance method
NSLog ( @"The value is %i" , object.i ) ; // if it's object's instance method

Another example:

@interface MyClass : NSObject {
    NSInteger i ;
}
@property NSInteger i ;
@end
@implementation MyClass
@synthesize i ; // Causes the property to line up with the ivar by the same name.
@end

Is the same as:

@interface MyClass : NSObject {
    NSInteger i ; // you ARE allowed to use this since you defined it
}
- (NSInteger) i ;
- (void) setI:(NSInteger)value ;
@end

Here, you can use the getter/setter methods or the instance variable itself. However, you should generally use the methods because you [implicitly] declared them atomic so they have threading synchronization. If you want to make it NOT do threading (and speed it up, as long as you're not going to use it in a multi-threaded environment):

@property (nonatomic) NSInteger i ;
@property (nonatomic,readonly) NSInteger i ; // only makes a getter method

I'd recommend avoiding this for a while and use the straight properties because it'll help you avoid a lot of common mistakes. Unless you profile your program and determine that this is a cause of a performance loss, you should probably simply use the properties.

Another example:

@interface MyClass : NSObject
@end

@implementation MyClass
NSInteger i ;
@end

This is NOT an instance variable. It is a global variable that happens to have been written inside your @implementation scope.

See above for how to turn this into an instance variable (i.e. putting it in braces).

One more note:

Declaring a property like this:

@interface MyClass ()
@property NSInteger i ;
@end

Doesn't make it private. However, it is hidden in a file that people generally can't access so the compiler doesn't know a property exists.

Other functions elsewhere in your code CAN still call:

[yourObject i] ;

To get the value of that property - but they have to know it's there first.

Addendum to answer a question in the comments:

Properties are, by default, atomic. It doesn't necessarily follow the strict definition of atomic (this is a can of worms I suggest you not look at right now), but has the same effect: threads are guaranteed to see a complete and up-to-date value, regardless of when another thread writes to it. It generally does this when it synthesizes the getter/setter methods:

- (NSInteger) i {
    @synchronized(self) {
        return i ;
    }
}
- (void) setI:(NSInteger)value {
    @synchronized(self) {
        i = value ;
    }
}

If you instead specify nonatomic, it'll synthesize these:

- (NSInteger) i {
    return i ;
}
- (void) setI:(NSInteger)value {
    i = value ;
}

If your property is atomic, then you shouldn't ever access the ivar directly. Doing so violates the threading protection you gave it to begin with. (Sidenote: there are cases where you can, but wait until you become more familiar with threading/synchronization before you attempt it.)