So I'm creating a new file, a subclass of a UIViewController via the Xcode wizard that pops up through new > file.
I'm naming the file "747ViewController" and it spits out the .h/.m files fine.
However inside the files, the interface and implementation names are odd:
They show up as #interface _47ViewController : UIViewController and #implementation _47ViewController
Are you not allowed to start with a number or something? Should I leave it or rename it to what I want it? Thanks
That's correct: just like in C and C++ your identifiers can not start with a number. The workaround from Xcode is correct: Unlike Java, the source file name and the class name do not have to be the same.
Related
I have an objective-c class that uses swift classes. It all works fine.
I wanted to import the objective-c class into a swift class, so I added its header file to the bridging header. All the sudden I got an error the Projectname_swift.h file is not found.
Any ideas how to resolve this issue?
Is it actually possible?
a circular reference has been created, making it so the Swift code is unable to compile (which leads to the canary error stating that the _Swift.h file is not found).
i have provided a more in depth answer to a similar questions here and here.
long story short, the documentation explicitly says not to this:
To avoid cyclical references, don’t import Swift code into an Objective-C header (.h) file. Instead, you can forward declare a Swift class or protocol to reference it in an Objective-C interface.
Forward declarations of Swift classes and protocols can only be used as types for method and property declarations.
in order to make your code compile again you will need to remove the #import "Projectname_Swift.h" line from the offending Objective-C header. ideally you can simply move the import statement into your .m file, however if you need to publicly expose the Swift class in your ObjC header, then you must forward declare it using #class SomeSwiftClass;.
Let the Xcode build the bridge file from Objective-C to Swift.
Create a temporary directory elsewhere. In there, you create a dummy Xcode Swift project, give the project name the same as your existing Current Project Name.
Then add new file, Objective-C (.m file). The XCode will prompt you to create a bridge header file, click on the create bridge file (the right most button).
Now you locate the header file location in Finder. Then drag into your Current Project of Interest, don't forget to checked the copy file if necessary option. Add necessary #import '.....' in the header file.
You should be good. If everything works fine, delete the dummy project.
Clean derived data. and then #import "ProjectName-Swift.h" in your objective c files.
Go to
Build Settings->Objective-C Generated Interface Header Name
and set the value to YourModule-Swift.h (this is usually already set, this is the filename you need to import on .m file #import "YourModule-Swift.h"
Go to Build Settings and search for "Defines Module", set both values to YES
Create a class in swift with prefix of #objc for example
#objc class mySwiftClass{...}
Build the project again
it will be better if you use error syntax or screen shot. you can simply try this
1. Goto your project on top of right navigation
2. select build settings from middle pain.
3. search for Objective-C bridging header
4. just below this you will find "Generated interface HeaderName"
5. add correct address of your swift file
6. clean and build the project.
Every so often I'll start a little 'helper class' and find that I can cover my needs entirely with C functions (although these functions may often have ObjC within them, maybe return type or some args of NSDictionary* or whatever..), and so i'll delete the #implementation and #interface and there is no class there at all, just .h and .m files..
What is the best practice, ought I change my .m file to a .c file? Or is this impossible/difficult with ObjectiveC types in there? Is there any benefit to using a different file type that I'm unaware of or is what I'm doing just fine? (I only develop for OsX and iOS, and entirely with xCode, at least for now.)
thanks for your time :)
When you make a Command Line tool using Xcode it gives you a .m file for your code despite the fact that the initial file is not a class implementation file, so it may be best to follow this pattern (this is also true for the main file in other projects).
If you select a file in Xcode and have the right hand bar open you can let Xcode know how to parse that file. So if you've got ObjectiveC in your .c file you can change the Parse type from a C file to an ObjC file and it will all work correctly.
When I try to create a .m file from the file menu, it prompts me for choosing a template from the several types mentioned - Objective-C class, Objective-C category, Objective-C protocol, etc.. Which one should be preferred?
I am fairly new to Objective-C as well as Xcode, so pardon me if this question is too obvious.
You may have to add Objective-C class and rename the new.m alone
to match your old.h and remove the newly added new.h file.
Create a new Objective-C class and copy your code from old.h to new.h file
Update as per comments: I see you are trying to add .m for the MAC sdk library, which is not possible.
You may have to consider using Categories extending the existing class methods.
What is “category
Customizing Existing Classes
If you want to create just an empty .m file, you can do so following these steps (Xcode 5.1.1):
In your Xcode project, go to File --> New --> File...
Select Other --> Empty
Click on Next
Type a name for your file and be sure to finish it with extension .m
Click on Create to save it
I created a new Xcode project (iOS application, Tabbed Application).
Now I'm seeing one sample code that Xcode generated for me (that I did not touch at all) and of course, it works on the iPhone simulator.
I am going through the code and though I'm seeing references to the .h files, I do not see any reference in any of the created files to .m files. (as in
#import "MRTAppDelegate.h"
#import "MRTFirstViewController.h"
#import "MRTSecondViewController.h"
Does the compiler just process whatever .m files you add to the project? Is there a list where they are all accounted for?
p.s. As it is obvious I also have little Objective C background, whatever I could carry from my university C classes.
if you go to build phrases -> compiled sources all the .m as specified there.
You're right on the basic assumption that Xcode will link the header and implementation for you. Just make sure you're added the .m file to your build sources and Xcode will do the rest.
You're also always going to #import the header file, and not the implementation file, in other classes.
I have a strange XCode project compilation issue. I have a subclass of UIViewController called HelpViewController that is created the same way as several other similar classes I have for adding to a UITabBarController.
When compiling I get the error; HelpViewController undeclared (first use in this function) when I try and create an instance to add to the tab bar.
If I rename the class to GuideViewController (*.h, *.m, *.xib filenames; all occurances in .h and .m; #import "*.h" and * alloc) the compilation succeeds but if I rename it back to HelpViewController it fails again with the same error.
I looked for HelpViewController in the dev docs but couldn't find anything to suggest it is a reserved name. Why might this particular class name be causing the error?
Sounds a lot like a #import is missing or incorrect. But it looks like you've covered that. Make sure you do a clean of the project (or delete the build directory), it could be old artifacts getting in the way.
Turns out I'd got my XCode project in a mess. When I deleted my *ViewController class at some point I had selected to only delete the references and not move the files to the trash as well. This removed the reference for the File Owner's outlet for view which could be seen as a warning in Interface Builder. The lack of a correct view reference prevented the ViewController being used (A View Controller is also a View). Since the files were still present in the file system (but not shown in the XCode project) they compiled badly. I deleted the files and selected to move them to the trash and then recreated them from scratch.