Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[net6-ios] UIKeyboard.BoundsUserInfoKey member is missing in Preview 12 #13885

Closed
jeromelaban opened this issue Jan 26, 2022 · 6 comments
Closed
Labels
need-info Waiting for more information before the bug can be investigated
Milestone

Comments

@jeromelaban
Copy link

Description

Similar to #11237, the following member is present in xamarinios10 but is not present in net6.0-ios:

UIKeyboard.BoundsUserInfoKey

Environment

6.0.200-preview.22055.15 and VS 17.1 Preview 4.

@rolfbjarne
Copy link
Member

UIKeyboardBoundsUserInfoKey has been deprecated by Apple for over 12 years, and their site says "Use UIKeyboardFrameBeginUserInfoKey or UIKeyboardFrameEndUserInfoKey instead."

Is there any reason you can't use those values instead?

@rolfbjarne rolfbjarne added the need-info Waiting for more information before the bug can be investigated label Jan 26, 2022
@rolfbjarne rolfbjarne added this to the .NET 6 milestone Jan 26, 2022
@jeromelaban
Copy link
Author

We certainly can. I'm mentioning this because it's a breaking change from net6 APIs, and that increases the overall burden of migrating to net6.

@rolfbjarne
Copy link
Member

Ok, I'm going to close this since there's an alternative to the API in question (and recommended by Apple).

Also, there will be numerous breaking changes in .NET: #13087

@jeromelaban
Copy link
Author

This is not particularly reassuring for the rest of the changes... Let's hope it'll not make migrating to .net6 too difficult for the rest of the ecosystem as a result.

For this particular change, even if it's deprecated in UIKit, the member is still present and works. Forcing downstream refactoring is implying lots of feature changes your dependents.

@rolfbjarne
Copy link
Member

If there's a compelling reason for a particular API we've removed, we're certainly open to add it back. In this case it seems somewhat extreme to keep an API that been deprecated for over a decade, and for which there's an alternative.

@jeromelaban
Copy link
Author

jeromelaban commented Jan 26, 2022

I still think the deprecation duration is not relevant in most cases. If Apple does not remove the API, I think .NET shouldn't either.

The code I'm dealing with here has been using this API for around 7 years, and has been working properly ever since.

@ghost ghost locked as resolved and limited conversation to collaborators Apr 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
need-info Waiting for more information before the bug can be investigated
Projects
None yet
Development

No branches or pull requests

2 participants