Avoiding compiler warnings when doing message forw

2019-02-24 01:21发布

问题:

I created a class that wraps a UITextView and adds some ui elements. I want the new class' API to be identical with UITextView, so I use message forwarding (listing below) to relay messages between the wrapped text view and the delegate.

The irritating thing is that the compiler issues warnings for method invocations on instances of my forwarding class. For example, an error will be generated for the following line:

[aMyTextView setContentOffset:CGPointZero animated:YES];

So I am forced to declare and create "manually forwarding" implementations for these methods, which defeats the whole purpose of using message forwarding.

- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated
{
    [_textView setContentOffset:contentOffset animated:animated];
}

I know the usual way of getting around this is to use one of the performSelector: methods, but this is a) cumbersome when some arguments are not NSObjects (although Erica Sadun's extensions are a big help), b) again, completely contrary to the intention of creating a transparent wrapper.

(Subclassing UITextView is also out of the question, because I need to insert views below the text view.)

Is there a way to get around this?

Listing of all relevant parts of the class:

@interface MyTextField : UIView<UITextViewDelegate>
{
    UIImageView*                        _border;
    UITextView*                         _textView;
    UIButton*                           _clearButton;
    NSObject<UITextViewDelegate>*       _delegate;
}

@implementation MWTextField
. . . 
// Forwards messages in both directions (textView <--> delegate)
#pragma mark Message forwarding

// Protocol messages will only be sent if respondsToSelector: returns YES
- (BOOL)respondsToSelector:(SEL)aSelector
{
    if ([_delegate respondsToSelector:aSelector])
        return YES;
    else
        return [super respondsToSelector:aSelector];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
{
    // First, try to find it in the UITextView
    if ([_textView respondsToSelector:selector])
    {
        return [_textView methodSignatureForSelector:selector];
    }
    // Then try the delegate
    else if ([_delegate respondsToSelector:selector])
    {
        return [_delegate methodSignatureForSelector:selector];
    }
    else
    {
        return [super methodSignatureForSelector: selector];
    }
}

- (void)forwardInvocation:(NSInvocation *)invocation
{
    SEL aSelector = [invocation selector];

    if ([_textView respondsToSelector:aSelector])
    {
        [invocation invokeWithTarget:_textView];
    }
    else if ([_delegate respondsToSelector:aSelector])
    {
        [invocation invokeWithTarget:_delegate];
    }
    else
    {
        [self doesNotRecognizeSelector:aSelector];
    }
}
. . .
@end

回答1:

Declare a category that provides the method declarations of the methods you are forwarding:

@interface MyTextField (ImGonnaLetYouFinishButFirstImForwardingThese)
... methods you want to forward here ...
@end

No need to provide an @implementation.

Note that this is a fairly atypical pattern. Not fairly, very. There should be no reason why you can't subclass. You say Subclassing UITextView is also out of the question, because I need to insert views below the text view, but that isn't true.


If I subclass UITextField, all I can do with the other views is to add them as subviews, which means they will be on top of the text field. I guess I could modify drawRect:... Is that what you would suggest? Or what do you have up your sleeve there?

If you need a group, create a UIView subclass that manages the various subviews appropriately, no forwarding necessary. Then you can order the views however you like.

Forwarding is used extremely rarely. Down that path lies madness. It really sounds like your design is a bit in the weeds, but there isn't enough information to really say anything more specific.



回答2:

Simple solution is to use dynamic typing and declare aMyTextView as id, the warnings will go away.