I'm trying to understand the Informal protocols, until now I know that Informal protocols are a kind of Category, but, why delegators don't have a category name?
Example:
#import <Cocoa/Cocoa.h>
#class FileSystemNode;
#interface AppController : NSObject { // Where is the Category ????
#private
IBOutlet NSBrowser *_browser;
FileSystemNode *_rootNode;
}
#end
Thanks.
Informal protocols are not "a kind of category".
If a class conforms to a protocol (for example #interface MyClass <MyProtocol>) it is guaranteed that you can call all methods on that class that are required by MyProtocol. (Unless the class doesn't really implement them [the linker can't know that because of dynamic binding], which is a programming error and a lie, but that is usually not the case.)
Categories on the other hand allow you to take an already existing class and extend it with new methods (for example adding a removeAllSubviews method to the already existing NSView class).
So, categories and protocols are quite the opposite of each other.
Related
#import <UIKit/UIKit.h>
#protocol myProtocol <NSObject>
-(void)aMethod;
#end
#interface ViewController : UIViewController
#property (weak) id<myProtocol> dSource;
#end
I am trying to get a firm grip on Obj-c protocols, I am reading apple doc to study, few things are not clear to me. Below are the points from doc:
The pie chart view class interface would need a property to keep track of the data source object. (The code above, we mostly declare protocol this way, when I have protocol declared in my class why need a tracking object, Or protocol can be defined in independent class? and for that we need tracking object?)
By specifying the required protocol conformance on the property, you’ll get a compiler warning if you attempt to set the property to an object that doesn’t conform to the protocol.
If you attempt to call the respondsToSelector: method on an id conforming to the protocol as it’s defined above, you’ll get a compiler error that there’s no known instance method for it. Once you qualify an id with a protocol, all static type-checking comes back; you’ll get an error if you try to call any method that isn’t defined in the specified protocol. One way to avoid the compiler error is to set the custom protocol to adopt the NSObject protocol.
I dont understand this question
Correct, the property requires that the property is an id which
conforms to your property, if you try to set it to something else
the compiler rightly complains
This is because respondsToSelector: is a method on the NSObject
protocol, so you can either have your protocol extend NSObject
(standard), or you could declare the property as
NSObject
I came from front-end development, so MVC and OOP still give me some head shakes. Just to explain to you I send like 500 dicionaries (with 100 parameters) to a nodejs server. The problem is that I has creating ivars for each parameter and each dicionary. Now I want to create some classes like a person class, in the same header file that I have my syncronization class for example. I can make something like this on the header:
#import <Foundation/Foundation.h>
#import "GCDAsyncSocket.h"
#class GCDAsyncSocket;
#interface socketDelegate : NSObject<NSStreamDelegate>
{
NSInputStream *inputStream;
NSOutputStream *outputStream;
NSMutableArray *messages;
GCDAsyncSocket *socket;
dispatch_queue_t connectionQueue_;
}
- (void) initNetworkCommunication;
- (void) sendMessage:(NSArray *)message:(int)numberOfContactsToSend;
#end
#interface personInfo: NSObject
#property (nonatomic,weak)NSString*firstName;
#property (nonatomic,weak)NSString*lastName;
#property (nonatomic,weak)NSDictionary*dicToSendWithConctactInfo;
#end
But in the implementation I don't know how to handle the multiple classes. Like I've a method inside the "socketDelegate" class that needs to use the person class, but it's not available inside it.
What's the best way to implement this?
To answer your immediate question, you can just forward-declare personInfo at the top of the file before socketDelegate:
#class personInfo;
Usually you just put each public class in its own implementation and header files, and each implementation file includes the header files of all the classes it uses. The header files usually just need to forward declare the classes they refer to (as you are doing with #class GCDAsyncSocket;. However, it doesn't make sense that you are both importing #import "GCDAsyncSocket.h" and forward-declaring. From what you are using it for here, you don't need the import. However, to properly use GCDAsyncSocket, you will need to implement GCDAsyncSocketDelegate protocol, which will require you to import the header; however, you should probably implement that protocol as part of a "class extension" inside the implementation file).
You only need to import the header of something in your header if you are subclassing a class, or implementing a protocol that is declared in the header. For all other uses (i.e. using the class or protocol as part of a pointer type), you can simply forward-declare it. (And for implementing a protocol, you can do that in the implementation file with a "class extension" if you don't need people to know you're implementing the protocol.
Different classes should, typically, be in different files. Once PersonInfo (please capitalize class names) has it's own PersonInfo.h and PersonInfo.m, then you simply add
#import "PersonInfo.h"
to the header file above to be able to reference PersonInfo from your SocketDelegate class (again, please capitalize class names).
I am wondering why there is twice #interface. One in class.h and other in class.m. For example:
TestTableViewController.h:
#import <UIKit/UIKit.h>
#interface TestTableViewController : UITableViewController
#end
and (automatically generated) class.m i find:
#import "TestTableViewController.h"
#interface TestTableViewController ()
#end
#implementation TestTableViewController
... methods delegated from UITable delegates
#end
So my question is, what the #interface TestTableViewController () in the .m file is about. Why it is there? Do I need it?
Thanks in advance
The second #interface directive is in the implementation file (.m) -- you can infer from it that it's meant for declaring stuff that the creator of the class didn't want to expose to the user of the class. This usually means private and/or internal methods and properties. Also note that there are two types of doing this. The one (which you see here) is called a "class extension" and it's denoted by an empty pair of parentheses:
#interface MyClass ()
This one is particularily important because you can use this to add additional instance variables to your class.
The second one, called a "category", is indicated by a non-empty pair of parentheses, enclosing the name of the category, like this:
#interface MyClass (CategoryName)
and it's also used to extend the class. You can't add instance variables to a class using categories, but you can have multiple categories for the same class, that's the reason why it's mainly used to extend system/framework classes for which you don't have the source code -- so a category, in this sense, is the exact opposite of the class extension.
The second "interface" defines an extension for the "TestTableViewController" class, which is not visible to someone who only imports the h file. This is the de-facto way for creating private methods in objective C.
In there you can declare private methods and properties that you only want to use in your class, but not expose to other classes.
The interface in the TestTableViewController.h file is the declaration of a class extension. There are 2 round brackets that show this. The syntax is the same as for writing a category for a class. But in this case it's used to declare some sort of private methods the author does not want to expose in the header file
A normal category interface looks like this:
#interface TestTableViewController (Your_Category_Name)
- (void)doSomething;
#end
And the corresponding implementation:
#implementation TestTableViewController (Your_Category_Name)
-(void)doSomething {
// Does something...
}
#end
In your example there is no category name specified, so it just extends the class and you can implement the method in the normal implementation.
Normally this technique is used to "hide" methods. They are not declared in the header file and are not visible if you only import the .h file.
I am watching the Stanford University iPad and iPhone application Developments course video. The instructor says in the video we can control-drag an UI object to the implementation files to create an action. But in this way the method will not declare in the header file. Does this mean it is ok to implement methods in the .m file but not declare in the .h file?
Depends on how you define "ok" :-)
Objective-C uses dynamic method lookup and does not really enforce access ("private", "public", etc.) specifiers. So you don't need to declare any method in a header file.
However you will end up fighting the compiler as it does do a fair amount of type-checking unless you persuade it not to, and you'll lose by doing so.
You are not required to declare in the header file all methods in the implementation. But if not in the header file obviously you cannot reference them by literal name in another file, nor can you "forward reference" them in the implementation file.
(Note that this is not that different from regular C, but is different from methods of a class in C++.)
It's "OK" to not declare methods in the header yes, under certain circumstances. For instance, if using ARC then the compiler generally needs to know the method signature so it can do the right thing. But basically all it means is that wherever you're using the method, it must already know about the method you're calling.
Since you're talking about Interface Builder, that's slightly different in that it will know about all methods since it can "see" the whole context of your header and implementation files and know that a method exists. i.e. in my terminology above, the method has been defined before it's used.
With regard to defining before use, the general accepted approach is to either:
Define a method in the interface file (.h). e.g.:
MyClass.h
#interface MyClass : NSObject
- (void)someMethod;
#end
MyClass.m
#implementation MyClass
- (void)someMethod {
// do something
}
#end
Define a method in a class continuation category. e.g.:
MyClass.h
#interface MyClass : NSObject
#end
MyClass.m
#interface MyClass ()
- (void)someMethod;
#end
#implementation MyClass
- (void)someMethod {
// do something
}
#end
I have a category on NSDate and it would be convenient if it could implement a protocol I previously created. Is this possible? what's the correct syntax for this?
Yes, that's possible. The syntax is:
#interface NSDate (CategoryName) <ProtocolName>
#end
#implementation NSDate (CategoryName)
#end
Here's Apple's documentation on the topic.
It's also possible to do this using a class extension. I very much like this to privately conform to delegate protocols. Doing so hides the implementation detail of being some delegate of some class from the public interface and removes the dependency from the header.