Usage of #import -- General guidelines for using #import in very large projects (ObjC)

Question

Where do #import my headers and implementations?
Are there rules regarding what I should do?
Is there a way to import everything in a single header file?

Answer 1

Given "General guidelines for using #import in very large projects.".

Well, Objective-C is much like C and C++ in this regard. Stuffing all your #includes/#imports into your headers will introduce a lot of unnecessary dependency, which adds a lot of time to your build. So further information may also be sought in topics on C and C++ dependencies.

Where do #import my headers and implementations?

Typically, you should write #import only where physical dependency exists. Since every objc object is reference counted and your properties/ivars do not typically need to exist in the header, #imports are far lower than C++.

Robin van Dijke outlined the common cases of physical dependence in his answer (+1).

Are there rules regarding what I should do? Is there a way to import everything in a single header file?

Well, it depends on the size of your project. Some people add all frameworks they use to the PCH (Pre-Compiled Header). Some people put the most frequent ones in the PCH, and some people don't use PCH files at all. The longer the build times and more complex the project, the less the PCH should include.

If you are working on "Very Large" projects, you should probably not add more than Foundation to your PCH.

Another common mistake is that some people will use the PCH so they need to type less (pretty much). The problem with that is their project's common includes/headers change, and when that happens, the target must be entirely rebuilt.

Also, if you can avoid #importing frameworks/libraries in your headers, you can save a lot of build time.

Adding #imports to headers increases causes dependencies to spread even further. It's easy for tons of unrelated code/frameworks which only need to be visible to a few source files to be actually visible to a high percentage of your source files.

Finally, you should really try to keep headers which change often out of other headers.

The big takeaway is that you should:

• separate your programs based on features
• favor forward declarations over #import. the compiler must know names, but the import is often needed only when you create/message the object.
• try to keep your dependency-heavy implementations in the *.m file.

Every once in a while, it can help to review the preprocessed output of some of your source files -- to see what is actually #imported -- the results can be quite surprising.

Notes:

• The PCH must be generated for every language in your project.
• Compile sources based on their needs; e.g. If you have C programs, don't compile them as ObjC.
• As your project's complexity increases, the gains to be made by dividing by targets (e.g. static libraries, modules, dividing your tests logically...) will increase. Structuring dependent targets correctly with low dependency is a large topic in itself. It can really help you build and test at higher frequencies when structured correctly (also important if you use continuous integration or have several developers). Like header dependencies, if you don't consider this from the start, old problems can take a lot of man-hours to correct (after it's already grown to be unbearably slow).

Answer 2

Just for kicks - I'm going to add a few "basic tenets" - that although are not as detailed as what has been said already - can sometimes help understand the overall "process".

Implementation.m files are never (as far as I know) #import'ed - that is what the compiler "is doing" when it "compiles".

Any header you want ALL compiled (.m) files to "know about" can go in the .pch file. I usually also stick directives shared across all classes, i.e. #import <Cocoa/Cocoa.h>, etc in there - so I don't have to look at them in every file.

If you are going to reference a previously undeclared class in a header file, i.e. AppDelegate.h

@property (nonatomic, strong) HTTPServer *http;

you can #import "HTTPServer.h" at the top of that file (or even in the.pch`)... but it is usually better to reference the "forward class" as follows...

 @class HTTPServer;
 @interface AppDelegate : NSObject  ➜ ...

and then #import "HTTPServer.h" in AppDelegate's .m file. The main reason that you need access to the header file... is to call methods and work with properties, etc of an instance of that external class within your own class's "scope". This is why you can "get away with" simply "mentioning" the @class in your header - you're not actually doing anything with it yet.

The only other thing to consider - and this probably isn't the case if you're building a standalone application - but when building a framework, or a bundle, etc… in which YOUR classes will be referenced in an "API-kind-of-way"… You would want to add a "Copy Files" phase to your build process which would allow "others" to "know about" your classes, via your "Public Header" files. In such a case... you can simply expose a header file which imports the forward declarations needed for your class, for other people to #import. This is how you are able to access all the classes in an "Umbrella Framework", such as <Foundation/Foundation.h> with a single #import... It has exposed the headers that it "makes available" in that first `.h' file.. á la...

#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>

If you ever used compiler before Xcode, the way to think about it is that any header you need to import are the same as an "Include" -I directive on the commandline. Given a header file src/headers/header.h and a source code file source.c which has an #include "header.h" statement.. the compile command would be

gcc -Iheaders/ source.c -o executable

You can learn about what is actually happening when you compile something in Xcode by navigating to the "log navigator" and Xcode and checking out all the steps.

Answer 3

First read this official site That may be helpful for you.

It is similar like , #include Statement In the C language,

Basically #import statement has two Defination,

1) #import "headerFile.h" // This statement is use for Import any header file in current file (UIController)

2) #import<FramWorkName> // This statement basically use for add any framework in current file (UIController)

For use any file any where in your Project then add your file (#import "fileName.h") in .pch file. It is Prefix headers are compiled and stored in a cache, and then automatically included in every file during compilation. This can speed up compilation, and lets you include a file without adding an import statement to every file using it. They are not required, and actually slow compilation whenever you change them. This file is available in your project with .pch file extension.

Such Like:

#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
    #import "MyFile_Name.h"

Your can also use PROTOCOL for to define methods that are to be implemented by other classes.

For More information about, How to create POTOCOL, here is Best example with detail.

Answer 4

The following conventions can be used:

Use #import in your header file when - You subclass the imported class - You use a protocol from the imported header file - You use other C datastructures (enum, struct) from the imported header file

Example:

#import "SuperClass.h"
#import "Protocol.h"

@class SomeOtherClass

@interface Subclass : SuperClass <Protocol>
    SomeOtherClass _instanceVariableToOtherClass
@end

Otherwise use @class in the header file

For all other cases, use #import in the .m file.

Note: #import "class.h" is in fact the following:

#pragma once
#include "class.h"

So it takes care that every class is only imported once to prevent include cycles/loops.