I recently tried to subclass UITextField and set the delegate to myself (found this trying ti solve my problem: http://www.cocoabuilder.com/archive/cocoa/241465-iphone-why-can-a-uitextfield-be-its-own-delegate.html)
#interface MyObject :UITextField <UITextFieldDelegate>
#end
#implementation MyObject
-(id) initWithFrame:(CGRect) frame
{
if((self=[super initWithFrame:frame]))
{
self.delegate=self;
}
return self;
}
-(BOOL) respondsToSelector:(SEL)selector
{
NSLog(#"responds to selector");
return [super respondsToSelector:selector];
}
// Implement all the missing methods
#end
Calling a method defined on the interface results in an infinite recursion. I don't see anything in the Apple docs that defines how respondsToSelector is supposed to behave in the presence of a delegate.
The docs for respondsToSelector states the following:
You cannot test whether an object
inherits a method from its superclass
by sending respondsToSelector: to the
object using the super keyword. [..]
Therefore, sending respondsToSelector:
to super is equivalent to sending it
to self. Instead, you must invoke the
NSObject class method
instancesRespondToSelector: directly
on the object’s superclass
It seems that this could be the cause for your recursion problem. I don't know if the delegate stuff is even related. Just a guess though.
Related
Initializing in awakeFromNib seems not working.
I have PBManager.m and In ViewController.m I made property for PBManager like
#interface ViewController : UIViewController
#property (strong, nonatomic) PBManager * pbMgr;
#end
And tried to initialize it in awakeFromNib like
- (void) awakeFromNib {
self.pbMgr = [PBManager sharedInstance]; // singleton. would be no problem...
}
and I used it in button action
- (IBAction)btnSendAction:(UIButton *)sender {
[self.pbMgr sendMessage:#"sendMessage" key:#"testKey" val:#"val"];
}
but this self.pnMgr in btnSendAction is null!
But it works when I initialize it in viewDidLoad.
Please tell me what's going on.
Thanks.
You need [super awakeFromNib];
From the documentation:
You must call the super implementation of awakeFromNib to give parent classes the opportunity to perform any additional initialization they require. Although the default implementation of this method does nothing, many UIKit classes provide non-empty implementations. You may call the super implementation at any point during your own awakeFromNib method.
In Swift, super's initializer should be called after all properties of the current class have been initialized. This is however not done for Objective-C init, where super init is called first before initializing properties in the current class.
What issues is Swift trying to prevent by enforcing this? Why is Objective-C able to avoid the issues Swift is trying to prevent?
What issues is Swift trying to prevent by enforcing this?
This is a great question, and Objective-C did not avoid it.
The problem is that while you're inside an initializer method, the object is technically in a partially constructed state. Bryan's post is a great (albeit contrived) example of why. The general issue is that if a super class's initializer invokes a method, a subclass may have overridden this method. That, in and of itself, is not a bad thing. The problem arises if the overridden method assumes that the object is totally constructed.
However, since the object is still in the midst of invoking the initializers, that is not the case. The object is not wholly constructed until the call to [super init] returns and the class of the object executes any of its initialization code.
There's a related problem with dealloc methods: if you invoke methods inside your -dealloc method, those methods may assume that the object is wholly constructed, when in fact it may be partially deconstructed. This isn't as big of a deal under ARC, but it can still lead to some very subtle bugs.
With Swift, the decision was made to avoid these class of problems by enforcing this rule:
By the time you decide to call super, the calling class must have finished any class-specific initialization.
A variant of this rule is:
You may not invoke methods until after you have called super's initializer.
With this rule, you will never run into the problem described above.
ObjC does not avoid anything.
For this ObjC code, it crashed because parent class is trying to access ivar from child class. It can be detected/avoid if the Swift rule is used. i.e. initialize all members before [super init]
#interface Parent : NSObject
#property (readonly) int value;
#end
#implementation Parent
- (id)init {
self = [super init];
if (self) {
NSLog(#"%d", self.value); // call a method, which can be overrided by child class
}
return self;
}
- (int)value {
return 42;
}
#end
#interface Child : Parent
#end
#implementation Child {
int *_valuePtr;
}
- (id)init {
self = [super init]; // call self.value
if (self) {
// to avoid crash, move this line before [super init], but it may have other undesired effect. e.g. when [super init] return another instance
_valuePtr = calloc(sizeof(int), 1);
}
return self;
}
- (void)dealloc {
free(_valuePtr);
}
- (int)value {
return *_valuePtr;
}
- (void)setValue:(int)value {
*_valuePtr = value;
}
#end
I have a certain scenario where I am trying to accomplish more generic approach of using delegate and calling a selector based on what selector is being set.
For example below is the code:
#protocol HttpRequestDelegate
#optional
- (void)testDrive:(NSData*)dataembedd;
#end
- (id)init {
self = [super init];
if (self) {
//Initialize it here.
self.HttpRequestdelegate = self;
}
return self;
}
HttpRequest *apiCaller = [[HttpRequest alloc] init];
NSLog(#"%#",apiCaller.HttpRequestdelegate);
[WLCC_ApiCaller executeAsync:apiCaller.HttpRequestdelegate :#selector(testDrive:) :[NSURL URLWithString:updateUrl] :wlcc_Get];
However at executeAsync call I am trying to call the selector which is test drive like:
[delegate performSelector:#selector(selector) withObject:responseData];
but it gives me an error of unknown selector, however when I notice the reference of the delegate its the same when initialized.
I am trying to utilize delegate perform selector in different class, is there anything else besides that I need to do here?
Thanks.
Define your protocol like this:
#protocol HttpRequestDelegate <NSObject>
There is an NSObject class and an NSObject protocol. All of your protocols should conform to the NSObject protocol. This gives you methods like respondsToSelector: and others.
I suppose it should be; as what it seems that you're implementing the functions in other and try to call from that place which not inherited the delegate and, possible miss that particular function implementation.
Normally, the delegate pattern is used so we can implement the function according to our need (or can say provide callback) but that class must conform that delegate.Have you checked for it?
Please elaborate more about your implementation as I think so many info are behind the curtains like : WLCC_ApiCaller executeAsync,etc.
I have created a class and this class has its own delegate protocol.
Inside that protocol, there's an optional method, declared like
#protocol myClassDelegate <NSObject>
#optional
- (void) myOptionalMethod;
#end
Inside the class I have a call to myOptionalMethod, in the form of
[delegate myOptionalMethod];
but as the method is optional, if I call this method on a delegate that has not implemented the method, it will crash.
So, how do I test to see if the method was implemented before calling it?
thanks.
This is pretty easy.
if([delegate respondsToSelector:myOptionalMethod]){
// You can now call this method without a crash
[delegate myOptionalMethod];
}
-respondsToSelector: is useful for individual methods, as others have posted here. For a stricter interpretation, you can see whether a class was declared as implementing a protocol with the -conformsToProtocol: method:
BOOL isAGrommet = [myObject conformsToProtocol: #protocol(Grommet)];
You should use the respondsToSelector method to determine if the delegate has the relevant method prior to calling the selector on the delegate.
For example:
if([delegate respondsToSelector:#selector(myOptionalMethod)]) {
[delegate myOptionalMethod];
}
I'm trying to implement delegation for a class which should call it's delegate (if any), when special things happen.
From Wikipedia I have this code example:
#implementation TCScrollView
-(void)scrollToPoint:(NSPoint)to;
{
BOOL shouldScroll = YES;
// If we have a delegate, and that delegate indeed does implement our delegate method,
if(delegate && [delegate respondsToSelector:#selector(scrollView:shouldScrollToPoint:)])
shouldScroll = [delegate scrollView:self shouldScrollToPoint:to]; // ask it if it's okay to scroll to this point.
if(!shouldScroll) return; // If not, ignore the scroll request.
/// Scrolling code omitted.
}
#end
If I try this on my own, I get a warning that the method I am calling on the delegate was not found. Of course it was not, because the delegate is just referenced by id. It could be anything. Sure at runtime that will work fine because I check if it responds to selector. But I don't want the warning in Xcode. Are there better patterns?
You could let the delegate be of the id type that implements the SomeClassDelegate protocol. For this, you could in the header of your SomeClass (in your case TCScrollView), do something like this:
#protocol TCScrollViewDelegate; // forward declaration of the protocol
#interface TCScrollView {
// ...
id <TCScrollViewDelegate> delegate;
}
#property (assign) id<TCScrollViewDelegate> delegate;
#end
#protocol TCScrollViewDelegate
- (BOOL) scrollView:(TCScrollView *)tcScrollView shouldScrollToPoint:(CGPoint)to;
#end
Then you can from your implementation, just call the method on the delegate:
#implementation TCScrollView
-(void)scrollToPoint:(NSPoint)to;
{
BOOL shouldScroll = YES;
shouldScroll = [delegate scrollView:self shouldScrollToPoint:to]; // ask it if it's okay to scroll to this point.
if(!shouldScroll) return; // If not, ignore the scroll request.
/// Scrolling code omitted.
}
#end
Following up on the sample code in drvdijk's answer, there could be a problem if there is any chance that delegate could be nil when you call the delegate method.
The return value of a message sent to nil is nil (aka 0.0 aka 0 aka NO), so if delegate is nil,
[delegate scrollView:self shouldScrollToPoint:to]
will return NO, which might not be the desired behavior in your case. It's safer to check first:
if (delegate != nil) {
shouldScroll = [delegate scrollView:self shouldScrollToPoint:to]
}
Also, if you don't want to see a compiler warning when sending messages declared by NSObject to your delegate (such as respondsToSelector:), include the NSObject protocol in your protocol declaration:
#protocol TScrollViewDelegate <NSObject>
- (BOOL) scrollView:(TCScrollView *)tcScrollView shouldScrollToPoint:(CGPoint)to;
#end
Use [NSObject performSelector:]
[delegate performSelector:#selector(scrollView:shouldScrollToPoint:) withObject:self withObject:to];
You won't get the compiler warnings anymore.
Alternatively create a prototcol and declare MyProtocol *delegate in header file.