What is the difference between these #import declarations?

I am going to send a mail from my application and I have added the MessageUI framework. In the sample code from Apple they write this:

#import <MessageUI/MessageUI.h>
#import <MessageUI/MFMailComposeViewController.h>

What is the difference between those, and whats the "slash" doing there开发者_运维百科?

---

The slash basically is saying the the .h file is in the framework of the framework named before the slash.

The difference between the two is that by using /MessageUI.h> you are doing the same as importing every single class in the framework. When you use /MFMailComposeViewController.h> you are only implementing one class in the framework. Therefore no other classes will be available apart from the class imported.

---

#import <MessageUI/MessageUI.h>
#import <MessageUI/MFMailComposeViewController.h>

What is the difference between those, and whats the "slash" doing there?

the toolset adds support for frameworks, as well as defines the search paths (e.g. for headers and linking) for frameworks, given the build settings.

a framework defines a Headers/ directory.

using this, framework paths may be resolved/discovered when separated using the path separator (/).

with apple's frameworks, the first idiom #import <FRAMEWORK_NAME/FRAMEWORK_NAME.h> is the common way to include a framework's common declarations via inclusion of the (majority of the) framework's public headers. in many cases, it will include all of the framework's public headers, but there are some exceptions. using this idiom in your program is generally best, as it insulates you from the headers' internal dependencies, which are likely to change across releases.

the second form is like the first, in that they both specify a specific header to include. it's different in that you are explicitly including a specific header - in most cases, this means you are including only a portion of the framework's headers (when the framework's master include is structured the apple way). many libraries are not designed to be used in this manner - the compiler may encounter undeclared types (as an example). in this case, you must include the header's additional dependencies if a build error is encountered.

there are several reasons why you may prefer the first form, the primary reason is ease of maintenance. considerate framework maintainers will include exactly what is necessary for the framework's headers to be included without error.

there are a few more reasons why you may choose the latter form:

• language differences: the framework may use multiple languages. depending on the language/dialect being compiled, including the entire framework may obviously introduce build errors.
• you only need a portion of the framework's declarations visible to external translations: specifying the header you need to be visible reduces your build times and dependencies.
• compatibility and minimal dependency: say you have written a library which targets multiple platforms (e.g. osx and ios). your library may use different frameworks/apis. specific inclusion can minimize the number of issues/dependencies, or you can selectively include what is necessary.