Why is UIResponder inputAccessoryView atomic?

Question

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 the inputView property) should redeclare [the inputAccessoryView] property as readwrite and use it to manage their custom accessory view.

1. After redeclaring inputAccessoryView, must I then @synthesize it? Doing so seemed to be the only way to get it to compile, but I want to use Apple's inputAccessoryView ivar, not synthesize my own.
2. Can I redeclare inputAccessoryView as nonatomic?
3. If I cannot redeclare inputAccessoryView as nonatomic, then must I always to access inputAccessoryView with self.inputAccessoryView, i.e., via the property instead of directly accessing the ivar, in order to preserve thread safety?

Answer 1

1. 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.

2. I don't think so; this wouldn't be compatible with the superclass declaration.

3. 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 a UIView, and there's no way for the setter to retain and release UIViews 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.