为什么 UIResponder inputAccessoryView 是原子的？
我将 inputAccessoryView 用于 UIViewController 的自定义子类之一，它是 UIResponder 的子类。
-[UIResponder inputAccessoryView] 的 Apple 开发人员类参考指出：
想要将自定义控件附加到 系统提供的输入视图（例如键盘）或自定义输入 视图（您在
inputView属性中提供的一个）应该将 [theinputAccessoryView] 属性重新声明为readwrite并使用它来管理其自定义附件 查看。
- 重新声明
inputAccessoryView后，我必须再@synthesize吗？这样做似乎是编译它的唯一方法，但我想使用 Apple 的 inputAccessoryView ivar，而不是合成我自己的。 - 我可以将
inputAccessoryView重新声明为nonatomic吗？ - 如果我无法将
inputAccessoryView重新声明为nonatomic，那么我必须始终使用self.inputAccessoryView访问inputAccessoryView，即，通过属性而不是直接访问ivar，以保持线程安全？
I'm using inputAccessoryView for one of my custom subclasses of UIViewController, which subclasses UIResponder.
The Apple Developer Class Reference for -[UIResponder inputAccessoryView] states:
Subclasses that want to attach custom controls to either a
system-supplied input view (such as the keyboard) or a custom input
view (one you provide in theinputViewproperty) should redeclare [theinputAccessoryView] property asreadwriteand use it to manage their custom accessory
view.
- After redeclaring
inputAccessoryView, must I then@synthesizeit? Doing so seemed to be the only way to get it to compile, but I want to use Apple'sinputAccessoryViewivar, not synthesize my own. - Can I redeclare
inputAccessoryViewasnonatomic? - If I cannot redeclare
inputAccessoryViewasnonatomic, then must I always to accessinputAccessoryViewwithself.inputAccessoryView, i.e., via the property instead of directly accessing the ivar, in order to preserve thread safety?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您必须自己为该属性提供 setter，除非 UIResponder 公开
setInputAccessoryView:方法。如果您有权访问底层 ivar，您可以自己编写一个 setInputAccessoryView: 方法来设置它。但在这种情况下，您无权访问它，因此您必须自己创建一个。我不这么认为；这与超类声明不兼容。
我不明白为什么这个属性不是
非原子，因为从非主线程调用（几乎）UIKit 中的任何内容都是无效的。特别是，此属性是一个UIView，setter 无法在非主线程上安全地保留和释放UIView。换句话讲，如果从后台线程调用 setter，则代码无论如何都会被破坏。如果仅从主线程调用，则可以直接访问 ivar。因此，您没有理由不能直接访问 ivar。
Yes, you'll have to provide a setter for the property yourself, unless UIResponder exposes a
setInputAccessoryView:method. If you had access to the underlying ivar, you could just write a setInputAccessoryView: method yourself which sets it. In this case, though, you don't have access to it, so you'll have to create one yourself.I don't think so; this wouldn't be compatible with the superclass declaration.
I don't understand why this property is not
nonatomic, since calling (nearly) anything in UIKit from a non-main thread is invalid. In particular, this property is aUIView, and there's no way for the setter to retain and releaseUIViews on a non-main thread safely.In other words, if the setter is being called from a background thread, the code is broken either way. If it's only called from the main thread, you can access the ivar directly. So, there's no reason you can't access the ivar directly.