I noticed a strange thing in sample code downloaded from apple dev center. the sample code is Footprint: Indoor Positioning with Core Location. There is no #interface and #end in AAPLMKMapRecRotated.h file. But it works well in simulator. Can anyone explain why? Thanks!
"#interface" and "#end" are necessary wherever you want to declare the interface to an Objective-C class. If you don't declare the interface of an Objective-C class in your header, it's obviously not needed. If you declare interfaces of three Objective-C classes in your header, you'll need it three times. If you declare the interface of an Objective-C class in a .m file, so nobody outside that file can see it, then you put it into the .m file.
#interface ... #end declare a ObjC class.. Not all .h file nor all Apple API rely on ObjC, a lot of C is used thorough their framework (CoreAudio, CoreMidi, CoreGraphic, GrandCentralDispatch...) in those framework .h file are classic C header used as such and therefore no #interface .. #end...
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Private Method Declaration Objective-C
I assumed in objective-c class methods need to be declared either in the .h file which makes them publicly visible or in the .m file using class extension to make it more private.
I thought without first declaring the method, xcode would complain, however I add a method to my main AppDelegate class without declaring it, and everything works fine.
What part have I confused, should I be declaring all methods of the class or is it okay not to if the method will only be used by that class and no where else??
You declare methods anyway. Either in .h file
#interface ViewController : UIViewController
-(void)myMethod;
#end
or in private interface in .m
#import "ViewController.h"
#interface ViewController ()
-(void)myMethod;
#end
Declaration of all class methods is not necessary in .h file.
Declare only those methods in .h file which you want to make publicly accessible to others.
Objective C is very dynamic language, and it resolves methods at runtime. That's why we're sending messages to objects and not invoking methods (like for example in C++). So if compiler doesn't see method declaration it doesn't mean that object can't find it at runtime.
So you can actually define ObjC methods everywhere you want (in any file or even in different libraries). Ones the program is compiled and linked ObjC runtime can find all of them.
I get the feeling that this is a very stupid question, but I cannot find an answer anywhere. I've created a new class in an XCode project called "Word", with its own .h and .m files, which inherits from NSString, and has its own declared instance variable, method, etc. How do I access it within the viewcontroller.h and .m files? I though it would just show up in the little suggestion box in XCode, like the pre-made classe, but it doesn't. How do I use my new class?
#import "Word.h"
I will note that subclassing NSString is extremely uncommon and almost never what you mean to do. You probably meant to have Word have an NSString property.
in your .h, at the top type #import " then start typing Word.h. It should autocomplete if the .h and .m files are in your project correctly.
You just need to add the following to your ViewController.h
#import "Word.h"
I'm currently taking the Stanford CS193p iPhone and iPad application development course ( http://itunes.apple.com/itunes-u/ipad-iphone-application-development/id473757255 ) and in the second lecture I got stumped when he connected the buttons of the calculator to the .m file, he connected the display label (that shows the value on the calculator) to the .h file...
My understanding of the whole implementation and header file thing was that you declare the class members in header and say what they do in the implementation, which is why this doesn't make sense to me...
any help would be greatly appreciated
It is possible in Objective-C for a .m file to contain methods for a class that the .h file for the class doesn't declare. In fact with the Categories feature of the language there can be more than one .h and .m that define all the methods for a class.
As far as what can be connected, the keyword IBOutlet marks properties or variables and IBAction marks action methods. These are just hints for the editor; all of the "connections" are set up at runtime automatically.
I've started a new iOS 5 project and noticed something new at the top of each .m file
#import "HomeViewController.h"
#interface HomeViewController ()
#end
#implementation HomeViewController
#synthesize ...
Is this extra #interface ... required if I have a separate .h file?
Why did this not show up in pre iOS 5 projects?
Can I use this instead of having a separate .h file?
What is the best practice for this going forward?
That's a class extension. You can use it to make declarations that you don't want to be in the .h file.
This was used by many developers, even before, who manually added the extension in the .m file. So I guess Apple included this in the template because it is widely used and is considered a good practice.
In fact, the .h file should only be used to make declarations that are going to be used from other files. You may have to declare some properties, methods or constants that will only be used inside the .m file. For those declarations, it is better to make them in the class extension.
So to answer your questions:
Is this extra #interface ... required if I have a separate .h file?
No, it is not required but is a best practice.
Why did this not show up in pre iOS 5 projects?
Even if this was a commonly used practice, it was not included in the template.
Can I use this instead of having a separate .h file?
No. The class extension doesn't replace the .h file where you have to declare the "public" interface of your class.
What is the best practice for this going forward?
You should put in the class extension all the declarations that don't need to be visible outside of the .m file.
The interface section in the implementation file allows you to declare variables, properties, and methods that are private, meaning that they won't be seen by other classes.
No, it's not required at all. But I use it as much as possible and only make public those things that other classes need to see.
I'm trying to learn some of the basics of developing OS X apps with XCode and Objective-C, but I am already running into problems.
I have a project I made from a while back which worked very well for me, however, when I try to replicate the results I had last time, I run into numerous errors.
I have two files, a .c and a .h named "AppDelegate"
in AppDelegate.h:
#import <Cocoa/Cocoa.h>
#import <WebKit/WebView.h>
#interface AppDelegate : NSObject {
IBOutlet WebView *gameFrame;
}
#end
then, in AppDelegate.c:
#import "AppDelegate.h"
#implementation AppDelegate
-(void)awakeFromNib
{
}
#end
In IB, there is an NSObject named 'AppDelegate' and its class is 'AppDelegate'.
However, when I try to run this, I get 11734 errors...
When I click on the error icon at the bottom of the XCode window, it lists a bunch of code that seems to be involving NSStrings, but I cant make any sense of it...
Also, within my code, the
#end
line in both the .c and the .h are highlighted with an error saying:
'Expected identifier or '(' before '#' token.'
I don't understand what XCode is tripping up on when it tries to compile, I don't see any logical place for a '(' to go and I don't think I left anything unidentified.
Any help would be appreciated.
That's because that isn't valid C code.
You named your module file AppDelegate.c, which indicates that it contains source code written in (more or less) pure C. But it does not: You wrote a class interface and implementation in Objective-C, which is a superset of C (all C is valid Objective-C, but not all Objective-C is valid C—in particular, classes aren't).
For this, you must name the module file AppDelegate.m (or anything else, as long as it ends with .m; naming it after the class is a convention worth following). The .m suffix indicates a module (usually containing a class implementation) written in Objective-C.
So, just rename your module file from AppDelegate.c to AppDelegate.m. Make sure you do this in Xcode, not the Finder: If you do it in the Finder, Xcode will only care that there is no longer a file named AppDelegate.c; it won't notice the rename.
For your convenience in creating future classes, Xcode provides a template in the “New File” panel for creating subclasses of certain Cocoa classes; your AppDelegate should be a subclass of NSObject, and templates are also provided for NSView, NSDocument, UIView, UIViewController, and a few others. The files created by the template will already have the correct extensions.