The JavaVM framework contains a sub-framework, JavaNativeFoundation framework. This sub-framework contains a header file, JNFRunLoop.h, that I need.
According to Apple documentation:
#import <Framework_name/Header_filename.h>
In both cases, Framework_name is the name of the framework and
Header_filename is the name of a header file in that framework or in
one of its subframeworks.
#import <JavaVM/JNFRunLoop.h> does not work (JavaVM/JNFRunLoop.h file not found).
I tried adding the sub-framework headers to the header search path, and while this allows me to import it, it gives a compile-time error which is mentioned in the documentation:
The umbrella header files and the subframework header files contain
preprocessor variables and checks to guard against the inclusion of
subframework header files.
I ultimately need to do this:
[JNFRunLoop performOnMainThreadWaiting:YES withBlock:block];
which won't work until I can import that header file. Any ideas?
The authors of the library have put that guard on purpose. Are you sure you are doing the right thing?
If the library allows modifications the right way would be to take it and adapt it to your needs.
If you need a quick and dirty way to call that method, you can try to declare it inside your ".m" file like so:
#interface JNFRunLoop
+ (void)performOnMainThreadWaiting:(BOOL)w withBlock:(void (^)(void))b;
#end
(it must match to how it is declared in JNFRunLoop.h in terms of name and parameter types)
After this declaration it becomes available for calling. Note that this won't work, if the library requires some special initialization steps, or if that function name is mangled in their binary or not present their.
Related
I have a Swift project and have add a cocoapod, which is written in Objective-C. It has header and implementation files. From what I understand, to use/import these files into my Swift files, I need to add a bridging file.
I found this site describing how to do this manually, since the Objective-C files are already part of my project (from the cocoapod).
http://www.learnswiftonline.com/getting-started/adding-swift-bridging-header/
1.) Navigate to your project build settings and find the “Swift Compiler – Code Generation” section. You may find it faster to type in “Swift Compiler” into the search box to narrow down the results.
2.) Next to “Objective-C Bridging Header” you will need to add the name/path of your header file. If your file resides in your project’s root folder simply put the name of the header file there.
I don't have a Objective-C Bridging Header in that section and it doesn't appear you can add new entries there.
I'm using Xcode 7.3.1. Anyone have some idea how this should be done?
Are you sure you looked at the correct Build Settings section, search with the keyword Swift compiler - General in the search field as describe below and then you can find it.
You need to create the header file first. It is a regular Objective-C header file and should be named <Your app or framework name>-Bridging-Header.h. For any Objective-C headers you want Swift to know about add an import statement to the newly created header file. Then follow your previous steps.
There is also a hidden header that gets created for you called <Your app or framework name>-Swift.h. If you need to access any Swift classes from an Objective-C file import this header.
I added some Obj-C code (the excellent Expressions) to my Swift project using Xcode's Add files... but it did not ask me if I wanted to make a bridging header. So I made one myself in the Obj-C code's group, edited it to #import the single header I needed, and made sure that file was referenced in the Swift Compiler in Build Settings. I then looked through the Obj-C code and made sure the .m files were in the target - they were, and they're listed in Compile Sources.
The header in question contains this:
#interface NSNumber (Expression)
+ (NSNumber *)numberByParsingExpression:(NSString *)expression;
+ (NSNumber *)numberByParsingExpression:(NSString *)expression withVariables:(NSDictionary *)varDictionary;
#end
Now I am trying to call this code using the same basic syntax as this post:
let result = NSNumber.numberByParsingExpression(f.1)
along with several variations on the theme. But it won't compile, "Type 'NSNumber' has no member 'numberByParsingExpression'".
Did I miss a step here?
According to https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
You can create a bridging header yourself by choosing File > New >
File > (iOS, watchOS, tvOS, or OS X) > Source > Header File.
You’ll need to edit the bridging header file to expose your
Objective-C code to your Swift code.
In your Objective-C bridging header file, import every Objective-C
header you want to expose to Swift. For example:
In Build Settings, in Swift Compiler - Code Generation, make sure the
Objective-C Bridging Header build setting under has a path to the
bridging header file. The path should be relative to your project,
similar to the way your Info.plist path is specified in Build
Settings. In most cases, you should not need to modify this setting.
Any public Objective-C headers listed in this bridging header file
will be visible to Swift. The Objective-C functionality will be
available in any Swift file within that target automatically, without
any import statements. Use your custom Objective-C code with the same
Swift syntax you use with system classes.
If you already did this correctly, and it still isn't working, try deleting the projects derived data, and clean building your project.
Ok, this turns out to be an Xcode peccadillo.
When you create the header file within the group, it actually places it physically in the source folder. So in my case the header was created in /project/subproject/.h although it appeared within Xcode to be part of the base folder, /project/.h.
So in fact there were two headers, one in the right place with nothing in it, and another in the wrong place that was the one that was being edited within Xcode. So you have to look at the file inspector to make sure it placed the bridging header in the right place!
What is the general rule for using an #import in a header file, as opposed to using an #import in a source file?
By #importing a header you create a dependency. As a 'general rule' it's good to minimise dependencies.
There's more to it than just placement of #imports. Few remarks:
Put as little definitions/properties/imports/... in your headers as possible; ergo, move as much as possible to the source file. A header is the public API of your module/class, you want to keep it as clean/to-the-point as possible. This avoids all kinds of dependencies that are actually not necessary.
It's often sufficient to add #class ClassYouNeed; (typically just below the #imports you do really need) instead of #import "ClassYouNeed.h". This is when just that class is used as a type, and no other definitions from ClassYouNeed.h. Typically you'd add #class ClassYouNeed; in the header and then do the full #import ClassYouNeed.h in the source file, because in the source file you typically need more than just the class/type. The compiler will sort things out for you.
In a header file, import only headers which are needed for the header file itself (the interface) and not for the implementation. Within the source file (the implementation) import the respective header file and any other headers which are needed only for the implementation.
This way, when the outside world includes your header, it will only expose what's relevant to its interface and not what's relevant to the implementation.
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.