子类化 UIWebView 不被接受吗？ [关闭]答案

【问题标题】：Is subclassing UIWebView frowned upon? [closed]子类化 UIWebView 不被接受吗？ [关闭]
【发布时间】：2011-02-03 23:54:13
【问题描述】：

我听说过关于是否允许创建 UIWebView 的子类的各种说法。有人可以将我链接到任何阐明这种或另一种方式的文档吗？

【问题讨论】：

标签： iphone cocoa-touch uiwebview subclassing

【解决方案1】：

Apple 在这方面的消息褒贬不一。

文档确实说不要像 BoltClock 所指出的那样进行子类化。然而，WWDC 2011 的一篇演讲 Rich Text Editing in Safari on iOS 建议进行子类化。它似乎是添加自定义 UIMenuItems 的唯一方法。

来自幻灯片：

// For your UIWebView subclass:
- (void)bold:(id)sender {
    [self stringByEvaluatingJavaScript:@”document.execCommand(‘Bold’)];
 }
 - (BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    if (action == @selector(bold:))
    return YES;
    return [super canPerformAction:action withSender:sender];
}

我需要在我的应用中使用复制和粘贴以外的其他功能，因此我将进行子类化。

【讨论】：

我自己的解释是，Apple 不希望我们覆盖 UIWebView 的复杂功能，例如 HTML 解析、页面布局渲染和 CSS 处理。这当然可以理解。另一方面，覆盖canPerformAction:withSender: 来控制选择弹出菜单（UIResponderStandardEditActions 等）似乎无害且合适。例如：this Question，禁用选择/剪切/复制命令。

【解决方案2】：

在UIWebView 参考的Subclassing Notes 下，它说的是：

子类化注释

UIWebView 类不应被子类化。

它没有说明原因。我猜是为了维护底层 WebKit 控件的完整性之类的，我不知道。

【讨论】：

我可以自己猜测他们为什么会这样做，我知道他们从来没有拒绝过我提交的子类 UIWebView 的应用程序，我觉得这样做比我做的一些黑客更好'已经看到人们这样做以避免这样做。（例如，在我的情况下，我对 UIScrollView 委托消息感兴趣，获得这些消息的唯一其他方法是深入研究 UIWebView 的子视图，因为那是私有土地，所以更加危险）。关于是否应该遵守这一点的任何想法？