I've realised that that I have like 4 or 5 related .h files that I have to import at few places. It seems reasonable to create a one .h file, add all imports to it and then only import one new file instead of 5.
First of all, is this a common practice? Or is there a nicer way?
In Xcode, when I try to do so using File -> New -> File... -> Source -> Header File the newly created header holds this:
#ifndef MyProject_MyProjetCommonHeader_h
#define MyProject_MyProjetCommonHeader_h
#endif
Not sure why these preprocessor commands needed. And it doesn't recognise (autocomplete) any headers when I try to use #import. Am I doing it wrong?
Yes you could import all the header files into MyProjectCommonHeader.h file.
#import "Header1.h"
#import "Header2.h"
And then to use Header1.h and Header2.h in another file just import MyProjectCommonHeader.h in the desired files.
The #ifndef commands are explained nicely here http://www.cprogramming.com/reference/preprocessor/ifndef.html
Related
Say I have a ton of small classes that I want to import all at once, is there a way to define a file that is literally just a list of imports and then only import that one file instead of having a long list of imports for each class?
Your suggestion will work fine: you can create a header file, and put #import "..." directives in it. Then you can include that header in all your files as needed.
Xcode provides an even better solution - the file called Prefix.pch. Instead of creating your own header, put the #import directives there. The result would be that all your files will implicitly include the files that you import in Prefix.pch - you wouldn't even have to import them.
In my project I have a requirement to create separate file for all constants that i am using in separate classes in the same project.
I seen some examples but they are saying about creating in '.h' file and again they are implementing them in '.m' files. But i need only '.h'file to create all constants and i have to use all those constants by importing that '.h' file in every class of my project.
ADD a new file.
Right click on the file inspector
choose New File
The pop up window select ios>C and C++>HeaderFile[Figure]
Give name Constants
Add #define OK #"OK"
Go to View Controller include file in header #import "Constants.h"
OR Define in pch file ,so that all View controllers can access the file
In viewDidLoad NSLog(#"%#",OK);
You can create .h file and use #define to create constants and then include your file to prefix file of your project. Though I prefer to use extern constants which you declare in .h file and define in .m file. This help to track possible warnings in your code at compilation time.
You've pretty much answered your own question, to the point where I'm not sure exactly what you're asking - you can just create a header file (.h) with your constants, and import it into your other classes. You don't need to create a corresponding implementation (.m) file. If you're using your constants throughout your code you could import them in your prefix header and have them automatically available.
My project has been increasing in size and I'm a little confused about where should I #import header files.
There are 3 main locations where I can import headers:
The .pch file (prefix)
The .h file (header)
the .m file (implementation)
I don't care if the compiler takes more time to compile the files, all I care is that the end product is as fast as possible and uses the least amount of memory.
So, my questions are:
If most files need a specific header, is it ok to add it to the .pch file, or is it more efficient to add it to just the required files?
Should imports be done in the .h or .m file? I know I must add it to the .h file if i'm going to declare it there, but if I don't need to declare it in the .h file is there a problem of leaving the import there?
No, it is not ok to include it into the .pch file. This file is precompiled to every module in the project. Read about it here.
Read this question and answer.
Put your imports in your .m whenever you can. If you are using a class in your .h use #class to forward the declaration, then #import in your .m. The only time you should import in your .h are protocols that you implement or superclasses.
Is there a difference between importing something (e.g. #import "JSON.h") into the header file versus the implementation file?
If you #import it in the header, then everything including that header gets it. You may find that useful, in that you don't have to #import it again in other places, but my preference is to #import things only where necessary, to minimize dependencies and make builds faster.
I think if you do it in the header file, you save your self some trouble later on in case you reference a class which is defined in the imported file.
In other words, if you import "JSON.h" in the header file, and there's a JSON class (hypothetically) that you will use in your header file (in the interface), then it would save you from having to do the #class directive at the top. Then your implementation file will also be fine since it would import the header file, which itself imported the "JSON.h" file
Basically I think it would be neater and would be more like objective-c if you import the required files in the interface file (.h). As you've probably noticed, interface files are usually short and concise, allowing you to get a quick glance at what a certain class is about and what it does. If you import your files there, you can also see what files/classes it relies on more easily, saving the implementation file (.m) for the actual 'meat'.
In reference to this related question on stackoverflow:
If you create a constants file, how do you "link" to it in your target, so you don't have to
#import "Constants.h"
in every file you use constants?
You really should be using #import "Constants.h" every place you want to use the constants within it; Objective-C is a C-based language.
Furthermore, you aren't "linking" to it either when you put an #import directive in your code or if you put one in your prefix file. In both cases, the contents of the file are included in the text stream fed to the compiler by the preprocessor.
Finally, you shouldn't generally add random things to your prefix file. (Panagiotis Korros referred to this as "your pre-compiled header file," but that's slightly incorrect; your prefix file is used to generate the pre-compiled header file.) If you keep your build settings consistent across projects, and use the same name for your prefix files across projects, Xcode will actually cache and re-use the precompiled versions for you very aggressively. This is defeated by putting project-specific contents in them.
You can put the import line in your pre-compiled header file.
That is the .pch file named after you application name.
When I use the constant in more file inside my application, normally I use the .pch file (find it under "Supporting Files" folder).
Into my .pch file I insert the constant, for example:
static const int NAME_CONSTANT = 200;
and use NAME_CONSTANT into all file inside my project without import never file because the .pch is pre-compiled header file.