I just updated my Parse frameworks, which now include Parse.framework, ParseUI.framework, ParseFacebookUtils.framework, and ParseCrashReporting.framework. After importing these frameworks into my swift project and importing the following statements into my bridging file:
#import <Parse/Parse.h>
#import <ParseFacebookUtils/PFFacebookUtils.h>
#import <ParseCrashReporting/ParseCrashReporting.h>
#import <ParseUI/ParseUI.h>
I am getting errors that PFImageView does not have a member named loadInBackground(), although loadInBackground with a completion block works. Similarly, PFObject does not have a member named 'deleteInBackground()', althought .delete() works.
Is anyone else having a similar issue with the new Parse iOS SDK? Am I missing something here, or does this seem like a bug with Parse/Xcode? I've tried cleaning, building, and deleting the derived data for my project multiple times with no luck. Please let me know if there is not enough information provided. Thanks for the help.
Try deleteEventually() instead.
Related
I'm migrating from Obj-C to Swift and have just migrated from PSGameScene.h and PSGameScene.m to GameScene.swift.
When I build the app, I get an error stating that PSGameScene isn't a recognised symbol.
GameScene.swift is added to the "compile list", I've tried adding GameSCene-swift.h to the source, but it doesn't see it..
Where am I going wrong?
I can confirm that both the bridging header and the .swift file area added to the compile scheme.
In the .h and .m files, it does recognise the class, and when I imoprt trying to use (GameScene-swift.s it complains that the file isn't there...
I'm. little lost...
Any posters would be helpful...
Cheers,
A
Sounds like you want to use your new Swift class in Objective-C, check out this answer about how to mix and match the two in the same project.
The gist is: import the generated -Swift.h header in your .m file that you want to use the Swift class on (you can't import it in a .h, check the above answer for more):
// SomeImplementationFile.m
#import "ProjectName-Swift.h"
You can double check the name of your -Swift.h header in Build Settings / Objective-C Generated Interface Header Name.
The issue turned out to be related to the build settings. As defines module was set to NO, it didn't like the import. When the DEFINES_MODULE (defines module) setting was set to YES it all clicked into place.
This probably happened as it related to an old project which spans back to Xcode 4 days. It appears that the newer releases of Xcode don't take into account some settings.
Thanks for the answers..
I have a bridging header in my project (named "Antoine Bellanger-Bridging-Header.h" if this helps) and then when I import my first framework
#import "SWRevealViewController.h"
everything works.
But when I import the second one
#import "Flurry.h"
I have two errors :
Flurry.h file not found
Swift Compiler Error : Failed to import bridging header "/Path"
I would like to know if the compiler error could be caused by the first error ?
Thanks in advance for your help.
EDIT : I have tried this with another project and I have the same error. May it come from the Flurry files ?
#BC_Dilum : Flurry.h is a file that I want to import and from the documentation of the site, it should be included like that. See https://developer.yahoo.com/flurry/docs/analytics/gettingstarted/ios/
Okay I found the solution. I just made a mistake and #BC_Dilum was right by adding
#import "Flurry/Flurry.h"
and not just #import Flurry.h
I've read a lot of questions and answers that deal with a similar issue, but I have yet to find a solution. If anyone could shed some light, that would be wonderful.
I created a Swift project and now I want to combine it with some Objective-C. My "failed to import bridging header" only occurs when I attempt to #import my Chartboost.h file. So, as long as I don't have anything in my bridging header file, Xcode finds it and gives me no issue. But once I add this:
#import <Chartboost/Chartboost.h>
I get the error along with 38 other errors saying "Swift Compiler Error - Function definition not allowed here".
I've correctly imported my framework. And my framework search path is correct. And it's only when I import the Chartboost framework. UIKit and Foundation work fine.
Here is what I did leading up to the issue....First, I created a new Obj-C file and then clicked "Yes when Xcode gave me a pop-up asking if it could configure a bridging header. This created "FunFacts-Bridging-Header.h"
Then I made sure Objective-C Bridging Header path was correct under Swift Compiler - Code Generation.
I even put in a very specific path /Users/me/Desktop/FunFacts/FunFacts-Bridging-Header.h
and it still says "Failed to import".
I've also set Defines Module to "Yes" (because I heard that may help). And my product module name is FunFacts.
Why is FunFacts-Bridging-Header.h failing to import when I try to add #import ?
I answered this in another post: Chartboost integration issues with XCode 6.1
EXPLANATION:
It seems like some pods and libraries don't bother importing the basic frameworks as they expect your code to already have them. This doesn't work with Swift as the way to import frameworks changed.
All you need to do is to add the frameworks needed in your bridging header file.
ANSWER:
It depends on what errors the compiler throws.
If it complains about NSObject, NSString, etc... you need to add
#import <Foundation/Foundation.h> in the top of your bridging header file.
If it complains about UIView, UIButton, etc... you need to add #import <UIKit/UIKit.h> in the top of your bridging header file.
I figured out 2 solutions!
1) This isn't the prettiest way to do it, but I copy and pasted all my code from my Chartboost.h file into my Bridging-Header.h file instead of importing . This worked. But I knew there was a better way, so I kept hunting...
2) The correct solution, I believe, is what I did next. My project's (not target) Framework Search Paths was empty. So, I went ahead and added the path to the Chartboost SDK like so: /Users/me/Desktop/Apps/SDKs/Chartboost
Now it builds and runs with no problem and I didn't have to copy and paste everything into the bridging header. All that was needed was
#import <Chartboost/Chartboost.h>
If anyone is having a similar issue, just read what I did in my question, and then follow it up with this answer.
Had a nearly identical issue and found a solution that worked for me.
My problem was that the Bridging Header was not in ALL my targets.
It was in my project but not my UnitTest target. So I added it to by my UITest and UnitTest and it started working without issue.
The problem like your's puzzled me.
But I found a solution.
#import <Foundation/Foundation.h>
You should put this code (↑) before your code.
This is just my solution (↓).
#import <Foundation/Foundation.h>
#import <Chartboost/Chartboost.h>
Good luck!
This is how I solved it (and works!):
Create yourProjectName-Bridging-Header.h file at the root of your project
Include in that file the .h of the classes you want to expose and use into your swift project
Go to yourProject->Build Settings->Search Paths, and set to Yes the "Always Search User Paths" key.
Set "User Header Search Paths" to your project root path.
That's it.
Apparently, Xcode miss out on third party folders when they are copied into your project
I am on Xcode 6.3 , swift 1.2.
The answer is really very simple.
Make sure you are adding your bridging header path in SWIFT_OBJC_BRIDGING_HEADER under the target section instead of the project section.
If you use CocoaPods this could save your time.
1) The first what you need to do is to check your Podfile it will be like:
target 'YourProjTests' do
inherit! :search_paths
end
target 'YourProjUITests' do
inherit! :search_paths
end
2) Open baseproj configuration and set for test targets correct Pods-Proj.debug , see attached image:
If you have these lines in you bridging header:
#ifndef Bridging_Header_h
#define Bridging_Header_h
#endif /* Bridging_Header_h */
Just delete them, it will solve the problems of Foundation and UIKit.
One case is that if import <Chartboost+Extention/Chartboost+Extention.h> ,
The right way is to import <Chartboost**_**Extention/Chartboost+Extention.h> ,
Just because Pod build will change the framework name of Chartboost+Extention into Chartboost_Extention
I'm having this weird issue when building my project. The problem is as follows:
My friend and I are working on a project and we're exactly using the same xcode, cocos2d and box2d versions.
His project compiles (builds) fine while mine gives this error when I do:
cassert file not found.
I took a copy of his xcode.project but no problems whatsoever.
I hope this code summarizes better what I'm trying to say:
GameLayer.h
#import bla bla //the usual required files
#class myOwnClass1;
#class myOwnClass2;
myOwnClass1 *test1;
myOwnClass2 *test2;
Now I wanna include the GameLayer.h in either myOwnClass1.h or myOwnClass2.h using #import but it would give me the error!
If I did #class GameLayer; no problems at all.
The thing is in my friend's project he's doing the #import without the error, which is super weird (at least for me)
Advice?
P.S. I know that changing the .m to .mm would solve it but, again, in my friend's project he's using the .m
I guess there is a mismatch of compiler settings between your project and your friend's.
In short: cassert is a C++ header file; you definitely need a C++ compiler to compile it.
Now, my guess is that in your friend's project, the GameLayer.m file is marked as a C++ file, though it has got a .m extension.
To verify that, open your project's (and your friend's) project.pbxproj file in a text editor and look for the GameLayer.m file. You will get this kind of entry:
347F5D94158BA4840058BC21 /* main.m */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.objc; path = main.m; sourceTree = "<group>"; };
as you see, the lastKnownFileType key says sourcecode.c.objc: this identifies an Objective-C file. If you see sourcecode.cpp.objcpp, that means objective c++.
Hope this helps clarifying it.
For some reason it turned out that creating a new project from scratch solved the problem, I'll mark this as the correct answer for now unless someone else has another opinion.
Here is how I fixed the issue. Cleaning up and recreating the project didn't seem to be a good idea for me.
There are a couple of answers on the web for this issue but they in each didn't help me solve the problem. One is on SO at
cassert file not found but i use Box2d template and the other is on cocos2d-iphone forum,
http://www.cocos2d-iphone.org/forums/topic/cannot-include-box2d-cassert-file-not-found-despite-every-file-being-mm/
Combining the two suggestions kind of worked for me -
Rename all YOUR (not cocos2d or box2d files, just your project files) from .m to .mm
Make sure that on each of the files, on the right pane, “Type” option is set to “Default – Objective C++ Source”
There was another issue for me specifically, may not be an issue for you, I was using the following signature for CCLabelTTF
CCLabelTTF *title = [CCLabelTTF labelWithString:#"Hello" dimensions:CGSizeMake(720.0f, 880.0f) alignment:UITextAlignmentLeft fontName:#"Arial" fontSize:34];
This is deprecated and caused errors all over the place. I am now using the following slightly modified version and the errors fixed -
CCLabelTTF *title = [CCLabelTTF labelWithString:#"Hello" dimensions:CGSizeMake(720.0f, 880.0f) hAlignment:kCCTextAlignmentRight fontName:#"Arial" fontSize:34];
My most recent writeup of this fix can be found at - http://indiangamer.com/how-i-fixed-the-cocos2d-box2d-include-file-not-found-error/
I'm helping on an iOS project with lots of methods and definitions common to many different classes in the AppDelegate. So, in each of those classes, in the .h file, I use #import "AppDelegate.h". This works fine until I need access to one of those classes that already imports the AppDelegate into another class that imports AppDelegate. At this point, I get a Duplicate Interface Definition error for AppDelegate.
Ok, so that seems fair. I'm already importing AppDelegate into a file that I'm importing, so AppDelegate is getting imported from two different places. So I remove the AppDelegate line, and everything is fine.
But what happens when I need to import two classes that both need to import AppDelegate?
I have a very specific problem that I'm trying to wrap my head around, and I know it is being caused by something that has to do with this, but I'm not sure what. So I'm hoping if I figure out how I'm supposed to be handling this sort of importing, and sort everything else out, and hope that this solves my problem. So to put this in more concrete terms:
I have ClassA.h, ClassB.h, and ClassC.h. All have #import "AppDelegate.h". When I need to use #import "ClassB.h" in ClassA, I remove the #import "AppDelegate.h" line from ClassA. Everything works smoothly. But what happens if I also need to #import "ClassC.h" into ClassA, and but ClassB and ClassC NEED to have the #import "AppDelegate.h"?
EDIT:
I tried the exact scenario I described above in a clean project, and it built fine, so there is something else at play. But what I can say with certainty is that when this issue came up previously with this project, it was a duplicate interface definition of AppDelegate, and when I removed the #import "AppDelegate.h" line, the error went away, and I still had access to the AppDelegate.h methods and enums through other imported files.
The best prevention and cure for this is to follow some guidelines on when to import from a header file. As a general rule, never import from an Objective-C header except in these cases:
You need to extend a class declared in another header.
You need to declare conformity with a protocol declared in another
header.
You need to refer to a non-class, non-protocol type defined in another header in the public methods and / or properties. To refer to protocols and classes, forward declare them with #class or #protocol, like #class ClassFromOtherHeader;
Every other #import should go in your implementation. My recommendation is to start moving all your #import statements out of headers and into the implementation files according to these rules. Start with the files you think are at the root of the problem and move outward. This will fix your problem and give you the side benefit of clearer code and faster build times.
For me none of the above answers were helping, nor did the answer given here work.
What fixed it for me was closing Xcode, going to ~/Library/Developer/Xcode/DerivedData and deleting all of the derived data associated with this project. After that I reopened the project and it was working fine.
Hope that helps someone!
In my case, none of the solutions mentioned fixed the issue. Xcode was reporting a duplicate interface for a class I rewrote in Swift. Somehow it kept pulling in the Objective-C header file for a class that wasn't directly referenced in the project.
I opened the Terminal, cd into the project directory, then ran the following to track down any files that were including the class header:
grep -nr ProblemClassName.h .
It turned out that the bridging header included an obsolete file that wasn't even referenced in the project navigator. That in turn was importing the header files referenced in the Xcode error, that were also not included in the Xcode project navigator. Now I know to not rely only on the Xcode project navigator for files referenced by the error.
tl;dr Double check the bridging header to ensure that all files that are imported there should be there and are not importing headers that are in-turn importing the problem headers.
I found that a project had a subproject and instead of referencing the includes in the subproject with the proper syntax:
#import <SubProject/Filename.h>
It was directly importing them
#import <Filename.h>
This was only possible because the path of the subproject was included in the "header search paths" of the main project - which is the wrong way to do business. So I deleted it from there.
The subproject should copy the needed included files in its "build phases - copy files" section (which was already happening actually), and the proper form of import that uses the Subproject/Filename.h syntax should be used.
Fwiw I started getting this seemingly at random - for me the fix was to do Product->Clean and it magically went away.
For me, I forgot to include parenthesis in interface definition in m file.