So I'm not to up on Objective-C so I apologize if this is a basic question but I can't seem to find someone with my exact problem.
I added the JBChartView(written in Objective-C) Cocoapod to a Swift project. The chart is good to go and fully up and running. However I then added some other separate Objective-C files and when trying to import a file from JBChartView it can't be found. What gives, I can access this Objective-C library from Swift files but not Objective-C files. Any ideas?
Below is everything I have tried.
#import "JBChartView.h"
#import <JBChartView/JBChartView.h>
You don't really give us much to go on here, but if you're able to import the framework successfully using Swift, then the framework is probably defining a module. In this case, you can just take the import statement you're using in Swift, add a # to the beginning of it and ; to the end of it and you've got a module import for Objective-C. So, if the import in Swift looks like:
import JBChartView
then you can do this in Objective-C:
#import JBChartView;
The mechanism is the same in both cases, so if one works, the other should too.
Related
I have project which is written on Swift but some part of project is written on Objective-C++ for integration with C++ library. My .mm files don't see Swift classes. I have done all steps from Can't use Swift classes inside Objective-C but still can't fix it. Auto-generated "project-Swift.h" generates with errors. I've tried to delete pieces of code in which error occurred and it worked well, but this "project-Swift.h" regenerates every time when I clean the project. Here is screenshot with errors link. Thanks.
This looks like you're not including the headers that define the missing symbols, like NSViewController, before including your bridging header.
I know at first glance, you will say this is a duplicate question that has been asked by lots of people. However, after doing some research, I think my situation is different from previous ones.
I am having this "failed to import bridging header" error when I tried to import objective-C files(that also import other files) into swift through bridging header. For example:
Person is a class written in objective-c, in the header and implementation files of this class, it also imports other local objC classes like "Animal", and also some pod frameworks such as "firebase".
When I tried to import this kind of class in bridging header, xcode reports the error of "failed to import bridging header". But when I import a simple objective-C class that does not import other files, everything is fine.
My guess is my objectiveC files rely on some third party frameworks and also some internal classes. When I import these kinds of files, I do not import all the necessary classes this targeted file uses?
So what might be the solution for this issue? The project I am working on is an objC based one, so most of the project are done in objC. Is it possible to import everything into the bridging header at once so that I can grab anything I want in the swift file?
Thank you so much! Having been stuck in this for half a day :(
Well, I want to know how to move some parts of framework from objective-c to swift without big pain
Ok, as far as I know:
1) Any project not a framework.
You make Swift-Bridging-Header.h or CatsAndGuns-Bridging-Header.h and put in it many import items.
You assure yourself in Build Settings -> (Search Swift) -> Objective-C Bridging Header. And put here your name.
Also check Packaging -> Defines Modules -> Yes
2) Framework
Well, you want to develop framework with mix objective-c and swift together.
And here you have pain: you can't use bridging headers in framework targets.
So, you come to google or documentation and start to read. Documentation
Ok, now you feel free and gorgeous about your knowledge, but.. you still don't know how to do it.
Create umbrella header and name it: YourProjectName-Swift.h. CatsAndGuns-Swift.h, ok.
Make it visible to framework level, so, navigate to right bar and put target membership -> your_framework_target (CatsAndGuns.framework in my case, of course) -> Public
And everything should be ok? remember to put every import as: #import <CatsAndGuns/Rocket.h>
Ok, let's check Rocket.h file in our framework. it is a Project-visible file, so, can it be accessed via in umbrella header (oh, module-swift.h) or not?
Now I have:
No bridging header in project ( as i understand from answer )
Manually created umbrella header with project-visible Rocket.h: #import <CatsAndGuns/Rocket.h>
errors in swift class that it can't see objective-c declarations.
Product module name without spaces.
In my understanding, it will be possible to work with Obj-C classes from Swift and write test cases much more quickly, and see the results in a playground project.
Does *.playground support including just a single class, like an .m/.h pair?
How does it work? Do I need to compile this class separately, or is it done automatically?
Unfortunately, a pure playground allows to import only Cocoa framework (for now, at least).
If you want to import other modules, you need to create a playground file inside an existing project. That way, the underlying Swift code inside the playground can access your symbols.
Reference: Does swift playground support UIKit?
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.