Closed dsmitchell closed 2 years ago
There is some history here: https://github.com/xamarin/xamarin-macios/blob/f2f41334f4d5c773ebccd0763c1aec515c7ac1c6/src/uikit.cs#L5957-L5962
Looking further back, I ran into https://github.com/xamarin/maccore/commit/0e8057086362f7f9f22b68b9d174e8568b11bf7b. This is from when the source code was private, but this is the commit message:
UITextInputTraits: ignore Apple's optional settings, and force the methods as required
While this does not match Apple's definition, the situation is this:
* Client code expects to be able to call the methods in this
class, and since a lot of them are properties and we lack
extension properties, we do not have a way of surfacing the API.
* There is no public code that adopts this protocol on GitHub,
or anywhere that I could find, it is as far as I can tell a
protocol that is accessed, but never implemented.
For our users, the downside is that we would be forcing them to
implement more methods than they would have wanted to when adopting
the IUITextInputTraits C# interface (UITextInputTraits protocol) by
forcing a number of methods to be implemented.
But this basically does not seem to happen in the wild, so the risk of
annoying someone is minimal, while the benefits are large.
This is from August 2014, so things have obviously changed since then.
The problem is that changing this now is not possible, since it would be a breaking change, and we need a very good reason to do breaking changes (this doesn't fulfill those requirements).
However, we might have a chance to do breaking changes in the future, so I'm keeping this open so that we can evaluate at that time if we can/want to do this change or not.
Thanks for the quick update. While this case may be mostly benign, there are examples in macOS/iOS where not marking optional methods and properties correctly would lead to undesirable behavior with the underlying framework.
For example, NSFetchedResultsController will assume you want to enable change tracking the moment your class implements at leasts one of four particular optional methods in NSFetchedResultsControllerDelegate. If those had been marked incorrectly (thankfully they're not) you'd be stuck dealing with a datasource that wants to change the UI when the rest of your code may not
Yes, we know that some API really must be optional, since its presence is checked at runtime and can cause difference in behavior, so with any new bindings we'll bind it correctly. In this particular case the binding is almost 5 years old, and at that time our support for protocols wasn't as complete as it's today, so we had to find non-optimal solutions in some cases.
On another note, Apple has also changed the required-ness of API, making previously required API optional (and vice versa), and in that case we can't update our bindings since it would be a breaking change (work is in progress to fix this, but it requires updates to the runtime and the C# compiler, so it takes a while to complete).
Steps to Reproduce
Expected Behavior
When implementing IUIKeyInput in a custom UIControl, I expect not to be forced to implement placeholders for all members of IUITextInputTraits
Actual Behavior
I am required to implement placeholder values, and force the OS to query my class for values I do not intend to override
Note that by forcing me to implement these members, NSObject's respondsToSelector will also return 'true' instead of 'false', which means that the OS, subclasses of my class, or other code that examines the class, may behave differently as a result
Environment
Build Logs
No build logs necessary to see this problem
Example Class