Objective-C: Simple question about header file declarations

The point of a header file in any C-language is to separate implementation from the available methods. That is, you define the template of the class in the header file so that someone using your code can just be like "oh ok I want to use this and this method and now I know how to instantiate an object of this class". It's all about abstraction. :-)

I guess it is just to make two files, one for public API(.h) and your logic and implementation in (.m) to hide from other people. also property tag helps to make getters and setters for your variable.

you use @property in header file and than @synthesize it in implementation which will let you access thru getters and setters.

More reading on,

http://developer.apple.com/library/mac/#referencelibrary/GettingStarted/Learning_Objective-C_A_Primer/_index.html#//apple_ref/doc/uid/TP40007594

FYI you can do something like this too, But not recommendable

#import <UIKit/UIKit.h>

@interface FileSystemDemoViewController : UIViewController {

    UITextView *actorListBox;
    NSArray *dataToShow;
}

@property (nonatomic, retain) IBOutlet UITextView *actorListBox;
@property (nonatomic, retain) NSArray *dataToShow;

-(IBAction) covertToAscending:(id)sender;
-(IBAction) covertToDescending:(id)sender;

@end

@implementation
...Your implementation here...
@end

Above all code is in .m file, Implementation.

again NOT RECOMMENDABLE

Happy coding

Why separate .h and .m files?

Historically, in C, when you included a .h file, it was almost literally equivalent to pasting the file into the file that included it. Effectively, all your declarations were repeated in every file that used them. That's ok, in C you can repeat declarations all you want, as long as they don't change. However, repeating definitions would result in multiple copies of a function and general brokenness. Therefore you couldn't include the whole code of a module, only its declarations.

I think Objective-C is actually smarter, and you could if you want have no .m files at all, and put all the code in .h files. You could also define a class only in a .m file and have no .h file, but you couldn't really make a whole project like that, since nothing would be able to access anything else.

However, it's still good practice to separate declarations from definitions. It's like having a menu at a restaurant instead of having to go back into the kitchen and see what's cooking. The .h file is a short summary of how other modules can make use of a module's contents.

Why some instance variables have properties and some do not?

Correct, part of it is that instance variables aren't automatically available to other classes. Properties by default are. However, not necessarily. You can make a property private.

Another thing you get with properties is automatic memory management. If you use the retain attribute, when you assign a value to a property, the value's retain count is increased, and the previous value's retain count (if any) is decreased. It's very convenient and avoids goof-ups. Even if other classes don't access the instance variable, it's useful. If you don't use properties, you have to make sure you do the appropriate retain and release instructions within your instance methods to avoid leaking memory. There are other automatic behaviors you can get on properties too, like locking or copying.

Lastly, you can get built-in behaviors with property attributes and the @synthesize keyword, but you can also decide not to use the @synthesize keyword, and write custom getters and setters for your properties. Those can do fancy things, like update related instance variables whenever a property is changed.

As noted, the original reason for .h and .m files is that C compilers process each source file in isolation, then connect the dots between them only when they come to link. There therefore needs to be some mechanism by which declarations can propagate — so that each file individually can be checked for compiler errors and warnings — but definitions remain in a single place — so that the linker can ensure common resources end up in a common place.

As of the modern runtime, the distinction between .h files and .m files is better thought of as the difference between the interface and the implementation. The interface is something you publish for everyone to see. The implementation is something that's for the knowledge of that class only. Your only contract with the outside world is that defined by the interface.

Objective-C, like most object-oriented languages, adopts the concept of getters and setters for object properties. Objects don't have access to the instance variable of other objects, they instead ask "what's this value?" or "please set the value of that to this". Prior to Objective-C 2.0 you had to write getters and setters yourself, which introduced a whole lot of repetitious boilerplate code. The initial purpose of @property was to declare getters or setters in the interface. @synthesize is used to generate the default implementation for something declared as an @property.

As of the new runtime, there's no need to declare instance variables in the interface, you can keep them entirely within the implementation. So, for example:

SomeClass.h:

@interface SomeClass: NSObject

- (void)doSomeTask;

@end

SomeClass.m:

// declare a category with some unexposed properties
@interface SomeClass ()
@property (nonatomic, assign) NSMutableArray *arrayForMe;
@end

@implementation SomeClass

@synthesize arrayForMe; // you can now use the property self.arrayForMe,
                        // even though you didn't declare a backing
                        // instance variable

- (void)doSomePrecursorTask
{
    // ...
}

- (void)doSomeTask
{
    // as a fact of implementation, I need to do something else
    // first. Because it's an implementation specific, I don't
    // want to put it in the declared interface

    [self doSomePrecursorTask];
    // ...
}

@end

The new runtime is available on iOS, Lion and 64bit Snow Leopard. As a matter of good practice, it probably makes sense to keep instance variables out of header files now. Just put the public interface in there and think of them as a way to formalise and communicate. I would expect that instance variables in the header are going to look as old fashioned as NSEnumerator very quickly.