if i want to create a helper method in my .m file. its call it -(void) helpMeDoSomething... etc. do i need to declare the function prototype in the .h file like in c/c++ or just declaring it in the .m file is enough
Neither C, C++, nor Objective-C require function declarations to be in the header file. They simply have to be declared before they are used, and the definition in the .m file can serve as the declaration.
In order for other classes to see the method, its signature must be in the header file. If you are using the method in the same class that it is defined in, it does not need to be in the header file.
Put the prototype in the .h file if you want to make it available to be called from code in other files. You can put it in the .m file if it will only be called from inside that one file.
As in C/C++, you can declare it in your .m file as long as you declare it before you use it, and as long as you don't need it somewhere else.
Related
I wonder does it make any differences? If its declared in our m file, is it allocated again(thus comsuming extra and redundant memory) each time we uses or both ways mean the same thing and so doesnt make any different which file I declared it?
The only difference is the scope of the variable. A variable declared in the header file would be available to all methods within the class. A variable declared within a method is only accessible within that method.
As far as memory goes, in general there is no difference between having your variable declared in the header file or in the .m file.
If you declare UIImagePickerController.h in *.h, whenever you import *.h in your other classes then UIImagePickerController.h will also get imported there unnecessarily.
Difference is scope if you use in .h should be present for everyOne if in .m should present for the function and if you declare in .m with #interface() it should be private.
I had this problem with import statements with my own classes using forward declarations to fix that. I have a method that uses type CTFramesetterRef. So I needed to add the CoreText framework. If I declare the method in my .h file, do I just
#import <CoreText/CoreText.h>
in my .h file and not my .m file. Are there any hard and fast rules for this? Sometimes I see code that has it in the .m, sometimes in the .h. To me it seems like what I see is declare it in the .m if you can, if you have to put it in the .h, put it there instead, and if you can use a forward declaration for a class, then do that. Just not sure what the proper way to do things are. Thanks.
"declare it in the .m if you can, if you have to put it in the .h, put it there instead, and if you can use a forward declaration for a class, then do that." - I would say this is the proper way to do that.
Its kinda general question. What difference it make if we create instance of UIViewController in interface (.h) file and declare it as property and use it in implementation (.m) file to push it on current view than that of creating instance in implmentation file itself and push it on current view in UINavigationcontroller ?
Regards,
Sumit
In Interface i.e. .h file we are just having declaration of the variables and that are only the references to the class and NOT the INSTANCE... Please understand the difference between reference and instance both are different. When declaring in .h file we are agreeing that we are going to use that variable in our .m file. And we can instanciate it... Also other 2 answers are also having its own points....
Usually you define your UIViewController in .h as a field of your #interface because you may need to access it in more than one point or it can be useful, for you, to keep a pointer to that controller. If you don't need this you can simply define it in .m, use it and then release (or autorelease) it.
There are a few differences. By making it a property the code generated will have some retain/release logic built in.
Also, by declaring the field and property in your .H file, the member is effectively "public" and visible now from other classes. If you only have the member defined in your .M file, it is only accessible within your own class.
When and what methods should be declared in the #interface section of a class? As I understand, methods that describe what your class does should be declared in the #interface section, but other "helper" methods should not be declared. Is this a correct understanding from my side?
One way is to declare the instance methods in .h file. And, declare the private methods inside the .m, using a Category.
For example, in MyOwnClass.h file.
#interface MyOwnClass
- (void)aInstanceMethod;
#end
And, inside your MyOwnClass.m file, before the #implementation block,
#interface MyOwnClass (MyPrivateMethods)
- (void)aPrivateMethod;
#end
You usually should add your methods to the .h file when you want an external class to have access to it (public methods).
When they're private (only used internally by the class) just put them in your .m file.
Anyway, it's just a pattern. As Objective-C works with messages, even if you don't set a method in your .h file an external file can access it, but at least your auto-complete won't show it.
You should declare all your methods in your .h
The tip from EmptyStack is nice but it's just a tip.
If you don't intend to ship your binary as an SDK, you don't really need it.
Objective-C doesn't have (yet) private methods.
i declared a variable in .m file i want to access that variable in another .m file how to do it?
If you don't want to make your variable an iVar for some reason then you can declare your variable in 2nd file to have external linkage:
// 1.m
int myInt;
// 2.m
extern int myInt; // this is the same myInt as in 1.m file
Make it an instance variable of the class and you must synthesize the variable.
Then you can access this variable in another class by
classObject.variableName;
In your .m file:
<objectType> *object;
In its .h file:
extern <objectType> *object;
Now just including .h files wherever you need this variable will do.
Caution: If this variable is not of primitive type, you must retain this object somewhere. The object must be alive in the program (you can retain it in applicationDelegate to ensure this). Gave me a headache since I thought it would live for the whole program's life.