This allows us to unify the code between all platforms.
Also add all the NSAttributedStringDocumentAttributeKey values we haven't bound yet.
There are no changes in the public API, because I'm only changing internal types.
Ref: #14489.
Unify the code for the following constructors:
* NSAttributedString (NSData data, NSDictionary options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
* NSAttributedString (NSUrl url, NSAttributedStringDocumentAttributes options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
* NSAttributedString (NSData data, NSAttributedStringDocumentAttributes options, out NSDictionary resultDocumentAttributes, ref/out NSError error);
These functions use 'ref' arguments instead of 'out' arguments for mobile
platforms (likely due to the generator not having proper 'out' parameter
support when these functions were implemented), so improve to use 'out'
parameters in XAMCORE_5_0 (and macOS, where they already use 'out'
parameters).
Also fix nullability.
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
Unify the code for the following functions:
* NSAttributedString.GetData[FromRange]
* NSAttributedString.GetFileWrapper[FromRange]
These functions use 'ref' arguments instead of 'out' arguments for mobile
platforms (likely due to the generator not having proper 'out' parameter
support when these functions were implemented), so improve to use 'out'
parameters in XAMCORE_5_0 (and macOS, where they already use 'out'
parameters).
Also fix nullability.
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
The 'initWithFileURL:options:documentAttributes:error:' was deprecated in iOS
9, and a new alternative (initWithURL:options:documentAttributes:error:) was
added. At the time, we implemented automatic detection of the current OS, and
would choose one version or the other depending on which was available.
We won't support anything below iOS 9 anymore, which means that keeping the
backwards-compatible constructor is useless, so just remove the corresponding
code and expose the new alternative directly.
On another note, this constructor uses a 'ref NSError' argument instead of an
'out NSError' on mobile platforms (likely due to the generator not having
proper 'out' parameter support when this constructor was implemented), so
improve to use 'out' parameters in XAMCORE_5_0 (and macOS, where it already
uses 'out' parameters).
Ref: https://github.com/xamarin/xamarin-macios/issues/15216
* Set NSImageRep DrawInRect hints as nullable
* Add nullable attributes to NSString DrawAtPoint/DrawInRect/StringSize
* Fix xtro test failure
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Also remove the Unscaled field, it's removed from the headers, and it was
deprecated before the earliest macOS version we support.
Also also fix a few xtro issues.
* [Xcode13.2] Bump to Xcode 13.2 RC (#13497)
* [Xcode13.2] Bump to Xcode 13.2 Beta 2
Breaking changes addressed for legacy
* HomeKit
* CallKit
* CoreLocation
* [xcode13.2] Bump to Xcode 13.2 RC and apply feedback
* [AppKit] Fix missing Notifications
* Fix xtro
* [xcode13.2] Bump versions and use stable Xcode 13.2
* [monotouch-tests] Make TestAddingByComponents work on the last day of the year
Happy New Year!!
* NO BOM PLZ!
There are numerous checks that don't make much sense to report for deprecated
API, so skip those. This also required updating a few .ignore and .todo files.
This requires a small change to the generator since `Selector.FromHandle`
can return `null` but it does not means the invoked API can (and we are
interested in the later).
Fixed up existing API returning potentially `null` `Selector`, IOW adding
the missing `[NullAllowed]` on them and updating xtro.
* A lot of availability attribute updates.
* Some conditional "#if !__MACCATALYST__" in manual binding files.
* xtro updates.
* Misc other minor tweaks.
* [AppKit/UIKit] Merge the definitions of NSTextLayoutOrientationProvider.
It looks like this might be a breaking change for macOS, but the macOS
definition had only a [Model] attribute, which won't make the generator
generate any public API.
* [AppKit/UIKit] Merge the definitions of NSTextContainer.
* [AppKit/UIKit] Merge the definitions of NSExtendedStringDrawing.
* [src] Share the NSTextStorage[Delegate] implementations between AppKit and UIKit.
* [AppKit/UIKit] Merge the definitions of NSCollectionLayoutAnchor.
* [AppKit/UIKit] Merge the definitions of the NSCollectionLayout* classes.
* [AppKit/UIKit] Merge the definitions of NSDataAsset.
* [AppKit/UIKit] Merge the definitions of NSShadow.
* [AppKit/UIKit] Merge the definitions of NSTextTab.
* Update xtro.
* [src] Share [I]NSCollectionLayoutVisibleItem implementation between AppKit and UIKit.
* [src] Share several NSLayout* implementations between AppKit and UIKit.
Native headers show it's null_resettable.
```objc
/// If set, the receiver will inherit the appearance of that object, as well as use KVO to observe its effectiveAppearance for changes. Typically this is used for child windows that are shown from a parent window or specific view. Defaults to NSApp.
@property (weak, null_resettable) NSObject<NSAppearanceCustomization> *appearanceSource API_AVAILABLE(macos(10.14));
```
Figure out if
* we're missing enum values (easy to workaround, but annoying for developers)
* we expose enum values that are not defined natively (potential bugs)
reference: https://github.com/xamarin/xamarin-macios/issues/7527
backport of #9691 with additional macOS and xcode12.2 fixes
* [Submission] Fix all the selectors that apple warns about. (#9268)
We have noticed the following message from Apple when performing
submissions with Xamarin.iOS:
> ITMS-90338: Non-public API usage - The app references non-public
> selectors in WcBc.iOS: behaviorTypes, convolutionState,
> discoverAllContactUserInfosWithCompletionHandler:,
> discoverAllContactsCompletionBlock,
> discoverUserInfoWithEmailAddress:completionHandler:,
> discoverUserInfoWithUserRecordID:completionHandler:,
> discoverUserInfosCompletionBlock, displayContact, drawableResizesAsynchronously,
> encodeToCommandBuffer:sourceImage:convolutionState:,
> encodeToCommandBuffer:sourceImage:destinationImage:state:,
> getProperty:onChannel:responseHandler:, hasProperty:onChannel:responseHandler:,
> initWithEmailAddresses:userRecordIDs:, initWithMIDIEntity:dataReadyHandler:,
> initWithZoneID:options:, initWithZoneID:subscriptionID:options:,
> isPublicDatabase, mouseUpAction, newDrawable, propertyChangedCallback,
> removeAllAppearanceStreams, replaceTextStorage:, retrieveConnectedPeripherals,
> retrievePeripherals:, setDiscoverAllContactsCompletionBlock:,
> setDiscoverUserInfosCompletionBlock:, setDrawableResizesAsynchronously:,
> setEditedMask:, setMouseUpAction:, setMovieControlMode:,
> setProperty:onChannel:responseHandler:, setPropertyChangedCallback:,
> setSocketFamily:, setTemporaryAttributes:forCharacterRange:, setUserRecordIDs:,
> sourceOffset, subscriptionOptions, takeBackgroundColorFrom:, takePasswordFrom:,
> temporalAntialiasingEnabled, userRecordIDs. If method names in your source code
> match the private Apple APIs listed above, altering your method names will help
> prevent this app from being flagged in future submissions. In addition, note
> that one or more of the above APIs may be located in a static library that was
> included with your app. If so, they must be removed. For further information,
> visit the Technical Support Information at http://developer.apple.com/support/technical/
All of them have been removed but without a break in the API excep
"initWithMIDIEntity:dataReadyHandler:" wich does look like an error on
Apples side.
Empty stubs are used as much as possible except on those cases in which
a handler is called or an output variable should be modified (buffer,
out param) to minimize the users surprise at runtime.
We have noticed the following message from Apple when performing
submissions with Xamarin.iOS:
> ITMS-90338: Non-public API usage - The app references non-public
> selectors in WcBc.iOS: behaviorTypes, convolutionState,
> discoverAllContactUserInfosWithCompletionHandler:,
> discoverAllContactsCompletionBlock,
> discoverUserInfoWithEmailAddress:completionHandler:,
> discoverUserInfoWithUserRecordID:completionHandler:,
> discoverUserInfosCompletionBlock, displayContact, drawableResizesAsynchronously,
> encodeToCommandBuffer:sourceImage:convolutionState:,
> encodeToCommandBuffer:sourceImage:destinationImage:state:,
> getProperty:onChannel:responseHandler:, hasProperty:onChannel:responseHandler:,
> initWithEmailAddresses:userRecordIDs:, initWithMIDIEntity:dataReadyHandler:,
> initWithZoneID:options:, initWithZoneID:subscriptionID:options:,
> isPublicDatabase, mouseUpAction, newDrawable, propertyChangedCallback,
> removeAllAppearanceStreams, replaceTextStorage:, retrieveConnectedPeripherals,
> retrievePeripherals:, setDiscoverAllContactsCompletionBlock:,
> setDiscoverUserInfosCompletionBlock:, setDrawableResizesAsynchronously:,
> setEditedMask:, setMouseUpAction:, setMovieControlMode:,
> setProperty:onChannel:responseHandler:, setPropertyChangedCallback:,
> setSocketFamily:, setTemporaryAttributes:forCharacterRange:, setUserRecordIDs:,
> sourceOffset, subscriptionOptions, takeBackgroundColorFrom:, takePasswordFrom:,
> temporalAntialiasingEnabled, userRecordIDs. If method names in your source code
> match the private Apple APIs listed above, altering your method names will help
> prevent this app from being flagged in future submissions. In addition, note
> that one or more of the above APIs may be located in a static library that was
> included with your app. If so, they must be removed. For further information,
> visit the Technical Support Information at http://developer.apple.com/support/technical/
All of them have been removed but without a break in the API excep
"initWithMIDIEntity:dataReadyHandler:" wich does look like an error on
Apples side.
Empty stubs are used as much as possible except on those cases in which
a handler is called or an output variable should be modified (buffer,
out param) to minimize the users surprise at runtime.
* Reduces code duplication.
* Makes the macOS versions thread-safe (the iOS versions have been thread-safe
for years: 2c6a5303a7).
* A few parameters names were different in the definitions; I chose to keep the ones in Xamarin.iOS, since they looked better.
* Xamarin.Mac had two methods, SetTextBlocks and SetTextLists, in place of an actual property override (for the mutable setter), this was fixed to be an actual property overload, and compat methods were implemented.
* xtro needed an update to cope with multiple static methods for the same selector.
* [AppKit] NSTextView allows passing nil to PasteAsPlainText and PasteAsRichText.
This is documented in Apple's documentation, their headers, and even proved
experimentally.
* Update xtro.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [AppKit] NSTextView allows passing nil to PasteAsPlainText and PasteAsRichText.
This is documented in Apple's documentation, their headers, and even proved
experimentally.
* Update xtro.
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
* [UIKit] Partial update to Xcode 11 Beta 1, 2 and 3 - Part 2 of ?
Missing bindings for
* NSDiffableDataSourceSnapshot
* UICollectionViewDiffableDataSource
* UITableViewDiffableDataSource
due to a registrar issue git generics.
* Update src/UIKit/UIFont.cs
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update src/uikit.cs
* More feedback
This also disables
* FloatRangeTest.Equals
* FloatRangeTest.ManagedVersusNative
due to https://github.com/xamarin/maccore/issues/1885
* [UIKIt] Start fixing `UITextWritingDirection` situation
But the complete fix is for another time https://github.com/xamarin/xamarin-macios/issues/6573
Alex Soto
Rolf Bjarne Kvinge
Chris Hamons
Marius Ungureanu
Curtis Wensley
Alex Soto
Manuel de la Pena
Rachel Kang
Sebastien Pouliot
monojenkins
Pramit Mallick