I'm doing some reorganizing of a semi-large project and I'm not sure the best way to go about it. I cannot decide where to use my #imports <...> across multiple files. I have a "Settings.h" style header that contains a lot of #define's needed by many of my classes. Should I be #importing everything needed by a class into its header? Or should I not import anything into the header and use #class definitions, then save the #import for the actual class.m files?
If this is unclear, let me know and I'll try to reiterate.
Where possible, prefer #class over #import in header files.
Result: faster builds and less likely to creaty circular dependencies (A imports B, B imports A).
You can also create a header file that #imports commonly used headers or those headers that are commonly used together, so that you don't need to #import each header individually.
Related
So I think I have this kinda clear, based on this blog post and my experiments:
what's included by #import MyPod; is the auto-generated MyPod-umbrella.h header, which imports all the public headers according to the Podspec
the auto-generated module map also permits explicit import of those and only those same public headers
what's included by #import <MyPod/MyPod.h> header is a MyPod.h header that I still need to make, but it can import anything I choose that's in the module map
What I was hoping to achieve, however, was that the header for either #import or #import to include most but not all of my pod's public headers. I'd like one of my public headers contain optional declarations that are normally omitted, to only be included manually from the few .m files that need it. But it seems to not be possible when code uses #import since the includes in that umbrella header always matches all the public headers.
Specifying a custom module map is possible and would work, but doing that seems to precludes the benefits of auto-generated map & umbrella header.
Would it be kosher to do some macro & #ifdef tricks to skip the contents of my "optional" header when included by the #import but then use the contents if that header is pulled in again with an #include? This sounds ugly, but is it my only option?
I found problems with all the #ifdef tricks I attempted when using framework cocoapods, though I'm sure they'd work when not. But I don't really want to be biased against frameworks and would like a solution for both.
So to take another approach, I found its not hard for a project to access a pod's private headers! See here and here (that last tip is for Swift, but I'm sure the right #import will work in Objective-C too).
So in my cocoapod I'm going to make the optional header private, and then rely on my users to use those methods to access it if desired.
I've read that the rule is to not #import or #include anything in .h files. Is that really true, though?
Just today I've run into two separate occasions where I had to do it, one where I import a header file that contains a typedef enum because my method stubs use it as parameters and another where I have to import a header file to declare delegatation.
What's the actual rule for these types of situations? Is it sometimes okay to do so – and if not, how can I do it differently?
There's no hard rule, but sometimes you do have to do it. You will also need to do if you inherit from something or need the protocol declaration.
In general I would restate the rule as "use forward declarations of #class and #protocol whenever possible."
If you've read such a rule, that rule is wrong. You can include (and import, which is just a safer way of include) things into your header, if that's something required for the interface declaration. Otherwise save it for the implementation files.
If ClassA depends on ClassB such that a consumer of ClassA is certainly going to need to import ClassB in order to make use of ClassA, I would prefer header imports over forward declarations.
Learning Objective-C and other c based Languages I learned that you should put the #includes and the #imports in the header file. And the #class goes there as well. Recently looking at example code from apple and other sources around the web the #class is in the header and all the imports are in the implementation file.
Which is correct? Are there reasons for both? Also why do you need to provide the #class declaration if you are importing the header file.
Neither case is "more correct", there are definitely reasons for both behaviours. For example, think about the case where you have two classes, each which has a reference to an object of the other type:
ClassA.h:
#interface ClassA : NSObject
{
ClassB *b;
}
ClassB.h:
#interface ClassB : NSObject
{
ClassA *a;
}
This code won't compile - you have a circular dependency in these headers. The solution is to forward declare the required classes using the #class directive.
A situation where you might prefer the #import directive in the header file might be if you have some common code besides just a class name that you care about in the other header - maybe C style functions or enumerated types or something.
Learning Objective-C and other c based Languages I learned that you should put the #includes and the #imports in the header file.
no - not in c based languages. you should put them in the implementation files where possible. you can't always create a zero-dependency header, but you should minimize it.
c based languages take a long time to compile, especially when the dependencies and includes are very complex, or there are unnecesary includes (introducing more dependency, coincidentally).
And the #class goes there as well. Recently looking at example code from apple and other sources around the web the #class is in the header and all the imports are in the implementation file. Which is correct?
use forward declarations (#class NAME;, #protocol NAME;, struct NAME, class NAME;`, etc.) wherever you can.
Are there reasons for both?
including in the header is the lazy way, it slows down your build times and introduces a lot of dependency. it's convenient because you don't have to write as many include/import declarations, but it's not considerate for people who must use your programs.
Also why do you need to provide the #class declaration if you are importing the header file.
if the class interface is already visible (has been included already, or another file has declared it), you do not need both . you'll need the interface visible if you intend to use the type (apart from some very trivial cases).
you certainly won't be excited to correct the mistake once your build times have grown slow -- it's best to learn and implement using the right approach. if you've not developed a complex c project, then you'd likely be very surprised to learn how much time is lost while compiling.
if you expect that your programs will never become nontrivial, and will be never shared or reused, then do whichever you prefer.
good luck!
After several months of coding in Objective-C, I completely understand when I need an #import, how import statements cascade (ripple?), and when to use forwarding classes. I do not know how to aggregate imports to get them inside of <> instead of in quotes (although maybe that's just for frameworks)...
The problem is that I'm making a huge mess. I come from Java (and the heavy-handed IDE), so I just add imports as I see fit. Sometimes I add them to the interface, but since that's usually not necessary, I just add them to the top of the .m in question.
Today I started thinking: there must be some rules of thumb on how to organize this stuff. In fact, since Objective-C is a C superset, there are rules of thumb for everything, but I don't know them. How should I organize my imports? Particularly:
When should I import in the .m?
When should I import in the .h?
Should I create .h files just for the sake of importing them (i.e., header files that just have imports in them)? If so, any hints on organizing that?
This is just a general idea of what I'm trying to figure out.
The <....> syntax is indeed just for frameworks. That doesn't mean you shouldn't create a framework to contain the core logic of your application though. Often this is a useful thing to do if you:
a) Need to provide support for loadable bundles that want to invoke aspects of your application logic (the bundle links to the framework, so does your application)
b) Write multiple apps that share the same core logic
Your question is somewhat subjective and you will get developers who argues both ways, but a convention I follow is:
Never import class definitions in the .h file, unless you are subclassing it. Use forward #class directives for everything in the .h.
Only import class definitions into a .m as you find you need to use that class in the implementation.
Generally speaking, the .h does not need access to the class definition of its ivars, method arguments or return values. It only needs to know that they are classes, which is what #class allows you to do. It does need access to the class definition of anything you're subclassing, adding a category to, or (obviously) implementing a protocol for.
Forget about whether <...> is for frameworks or what. <...> checks the system header search path, while "..." checks the current dir in addition to. One thing to remember however, is that the <CoreFoo/CoreFoo.h> declaration is handled a little differently on the apple platform, but only as it relates to apple frameworks: CoreFoo.framework/Headers/CoreFoo.h is matched to CoreFoo/CoreFoo.h
When imports are inside <> instead of quotes, all this means is that you are importing something from a framework. In fact, when doing this, the import is typically in the style
#import <Foundation/Foundation.h>
The first Foundation, before the slash, is the name of the framework in question, and the second one is just a header file in that framework. That header file is just something like
#import <Foundation/NSObjCRuntime.h>
#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>
...
#import <Foundation/NSURLHandle.h>
including every file from that framework. You can do this too, and isn't a bad idea for components that need multiple imports (although in that scenario, you may want a separate public interface)
For the other stuff, following the rule of thumb that you want stuff to know about as little as possible, you only want to put the import in the header file if it's necessary (like for an ivar or superclass) but really it's a matter of taste.
I have an idea on how to do this, but I want to make sure I do it right....
I have five data classes. When I use one I typically use all of them (but not always).
Each class has a separate header file. I am getting sick of linking in each header file separately.
What is the best way resolve this issue?
Create a new header file called "DataFiles.h". Inside that, have your five #import statements. Then whenever you need the file classes, just #import "DataFiles.h".
Beware of circular dependencies.
(This is how Cocoa, Foundation, UIKit, CoreData, etc all behave. Notice that you just #import <Cocoa/Cocoa.h>, which imports everything else. Open up Cocoa.h and take a look)