Fix numerous issues with NSLayoutManager[Delegate]:
* The classes are available in both AppKit and UIKit, but the bindings are
duplicated (unsuccessfully) in both appkit.cs and uikit.cs. So create a new
xkit.cs that is shared between XI and XM, and put a shared version of the
bindings there.
* Bind everything that hasn't already been bound (or deprecated by Apple).
* Methods that take a nullable NSRangePointer has been bound with three overloads:
* A protected overridable (exported) method that uses IntPtr.
* A public method without the parameter.
* A public method with the parameter typed as 'ref NSRange'.
This makes sure the native method can be overridden if needed, while at
the same time making it possible to call without providing the nullable
parameter.
* Fix numerous ugly bindings:
* There's a great nint/nuint confusion for parameters referring to
'character index' and 'glyph index'. XI seems to prefer nuint, while XM
seems to prefer nint. Standardize on nuint, since that's how Apple
created them.
* Many methods have names than sound like Objective-C. Fix them all,
either right away when possible, or for XAMCORE_4_0.
* Several parameter names have been modified to comply with our naming
guidelines (no abbreviations).
Fixes https://github.com/xamarin/xamarin-macios/issues/4740.
The added `SecTrustSetSignedCertificateTimestamps` API existed in older
versions of the OS so I kept the Xcode headers availability (instead of
current SDK version).
* [CoreFoundation, ObjCRuntime] Add DispatchBlock APIs, in particular those that surface QOS
* Make the struct readonly
Co-Authored-By: migueldeicaza <miguel@gnome.org>
* Make the field read-only
Co-Authored-By: migueldeicaza <miguel@gnome.org>
* Add Qos to the list of accepted words
* To add a finalizer that can dispose the object, turn this into a class,
rather than being just a wrapper around the native handle.
* Fix copyright.
* Fix whitespace issues.
* Adjust visibility of existing DispatchBlock method we don't want to make public
* Refactor a bit.
* Make DispatchObject inherit from NativeObject to avoid some code duplication.
* Put all P/Invokes in BlockLiteral.
* Simplify block code somewhat.
* Sprinkle [BindingImpl (Optimizable)] where needed.
* Add both constructors and static Create methods to create DispatchBlocks.
* Add an explicit operator to get an Action delegate from a DispatchBlock, and
an Invoke method to directly call said delegate.
* Add a few convenience API:
* Wait with a TimeSpan overload.
* Cancelled property.
* Notify with an Action overload.
* Add some DispatchQueue overloads to make DispatchBlock actually usable.
* Seal DispatchBlock.
Users shouldn't subclass DispatchBlock.
* Add tests.
* DispatchBlockFlags is native-sized (nuint).
* Fix a few more nint issues.
* Add availability attributes.
* Fix introspection tests.
* Fix xtro.
* Fix xammac tests.
Even if 'supportedVideoFormats' is static the type is abstract.
> Important
> ARConfiguration is an abstract base class, so its implementation of
> this property always returns an empty array. Read this property from
> the configuration subclass you plan to use for your AR session, such
> as ARWorldTrackingConfiguration or ARFaceTrackingConfiguration.
https://developer.apple.com/documentation/arkit/arconfiguration/2942261-supportedvideoformats?language=objc
and this behave differently in Objective-C (than .net) as every (static)
method will be different (and not a single implementation like C#).
The existing implementation (as a property) calls `ARConfiguration`
implementation which simply throws a (native) exception
> NSInvalidArgumentException Reason: Supported video formats should be called on individual configuration class
The solution is to obsolete the property (can't be subclassed in .net
since it's static) and add, only on the subclasses, a method that
call the 'supportedVideoFormats' selector on the current (not base)
type.
Added unit test to detect the addition of newer subclasses - since they
will also need to expose this method.
reference: https://github.com/xamarin/xamarin-macios/issues/5347
Basic fix that does not require a breaking change.
It's _basic_ as it does not fix the performance comments made inside
the issue. Those are different (not a bug, an enhancement) and I'll
file a separate issue to track this.
Reference: https://github.com/xamarin/xamarin-macios/issues/5132
The response object does not have all the cookie values, instead we must
rust the cookie storage which can be used to retrieve ALL the cookies
for a task.
The header value has to be created manually because the native objects
do not expose a valid way to get the header. Tests have been added to
ensure we return the same as the managed client.
Fixes https://github.com/xamarin/xamarin-macios/issues/5148
* Make it clearer when a timeout happens that a timeout happened by asserting
exactly that.
* Don't assert after getting the (unexpected) result from the network request,
since asserting will throw an exception, which will be caught and stored,
and then later in the test we assert that an exception was thrown. So
asserting just after a successful network request effectively hides any
failures, since we're now passing because of the assertion exception. Ops.
- Fixes#4698: CGAffineTransform.Scale does not work like Swift's .scaledBy(x:y:)
(https://github.com/xamarin/xamarin-macios/issues/4698)
- 'Scale' monotouch-test now covers the new overload for the new multiplication order.
- Changed the Scale test's values so we have different values for 'x0' (it was always 0 before) and so it matches the test case from the bug report.
* Same fix for Rotate and Translate
* [UIKit] UIGestureRecognizer, support a way of unsubscribing without creating cycles
This now tracks all the uses of AddTarget with delegates by recording
the Token/Selector pair and making `Dispose()` release all the linkage
as well as providing an enumerator that can be used to get all the
registered Action handlers - this can then be used with .First() and
then passed to `RemoveTarget`.
This addresses https://github.com/xamarin/xamarin-macios/issues/4190
This initial patch is here for discussion of the approach, want to
review and test this before we merge.
* Simplify code a little bit.
* Add test.
* [tests] Add an NSAutoreleasePool to make GestureRecognizerTest.NoStrongCycles happy on 32-bit.
Fix numerous issues with NSLayoutManager[Delegate]:
* The classes are available in both AppKit and UIKit, but the bindings are
duplicated (unsuccessfully) in both appkit.cs and uikit.cs. So create a new
xkit.cs that is shared between XI and XM, and put a shared version of the
bindings there.
* Bind everything that hasn't already been bound (or deprecated by Apple).
* Methods that take a nullable NSRangePointer has been bound with three overloads:
* A protected overridable (exported) method that uses IntPtr.
* A public method without the parameter.
* A public method with the parameter typed as 'ref NSRange'.
This makes sure the native method can be overridden if needed, while at
the same time making it possible to call without providing the nullable
parameter.
* Fix numerous ugly bindings:
* There's a great nint/nuint confusion for parameters referring to
'character index' and 'glyph index'. XI seems to prefer nuint, while XM
seems to prefer nint. Standardize on nuint, since that's how Apple
created them.
* Many methods have names than sound like Objective-C. Fix them all,
either right away when possible, or for XAMCORE_4_0.
* Several parameter names have been modified to comply with our naming
guidelines (no abbreviations).
Fixes https://github.com/xamarin/xamarin-macios/issues/4740.
The structs MTLQuadTessellationFactorsHalf and
MTLTriangleTessellationFactorsHalf are wrong as per the header
definition:
```c
typedef struct {
/* NOTE: edgeTessellationFactor and insideTessellationFactor are interpreted as half (16-bit floats) */
uint16_t edgeTessellationFactor[4];
uint16_t insideTessellationFactor[2];
} MTLQuadTessellationFactorsHalf;
typedef struct {
/* NOTE: edgeTessellationFactor and insideTessellationFactor are interpreted as half (16-bit floats) */
uint16_t edgeTessellationFactor[3];
uint16_t insideTessellationFactor;
} MTLTriangleTessellationFactorsHalf;
```
We set the arrays size to be the correct one.
Fixes https://github.com/xamarin/xamarin-macios/issues/4611
* Add tests that ensure that the size of the managed structs is the same
as the native ones.
The values used have been checked against a native app compiled on 32
and 64 (iphone 5 and iphone X).
* Avoid `ArgumentNullException` in default/empty `SecProtocolMetadata.PeerPublicKey`
* Add two `SecProtocolMetadata.CreateSecret` API - disabled as the current tests (incomplete?) crash in unit tests
* Add basic unit tests for `[Sec|NW]ProtocolMetadata`
* Update xtro
This means less (duplicated) manual code, which means less errors, which also
means we're now getting some new members that previously weren't duplicated
correctly.
Fixes https://github.com/xamarin/xamarin-macios/issues/4183.
* Move `NLTag` to static class (instead of enum) since it's not used in API, except along NSString. Fixes https://github.com/xamarin/xamarin-macios/issues/4774
* Add new member to `NLLanguage` to avoid `ArgumentNullException` when it has not been evaludated (API returns `null`), see unit tests;
* Add `[Params]` to `NLTagger` constructors so they are easier to use (no need to create the array in source);
* Fix `GetTag` so it returns (`out`) the `NSRange`, it's natively a `NSRangePointer`;
* Fix `GetTag[s]` API with changes to `NLTag` de-enumification;
* Add unit tests
- Fixes#4441: [generator] Binding with return value of Class [] do not do the right thing
(https://github.com/xamarin/xamarin-macios/issues/4441)
- Turns out the logic to put INativeObjects into NSArrays was already in place. We simply needed to add the missing (IntPtr handle, bool owns) overload to `Class`.
- Uncommented AppKit `registeredImageRepClasses` since it was using `Class []`. Tested locally and it works fine.
- Reimplemented `Foundation`'s `NSSecureUnarchiveFromDataTransformer` and its test which were also using `Class []`.
AVMediaTypeTimedMetadata has been obsoleted since iOS 6 but was totally
removed (returns null) in iOS 12.
Adjust test and provide a (better) deprecation warning for developers.
We have a test for CGFunction, and in iOS 12 the behavior changed where
previously the CGFunction was invoked immediately when rendering, it's now
retained and only called later.
This is troublesome for the test, because it disposes the managed CGFunction
when it thinks it's completed. Since the function is invoked way later, the
test now crashes. Ops.
The obvious fix is to change the test to dispose the CGFunction later. This
falls flat when finding out that "later" is undetermined. Native code retains
the CGFunction, and can do whatever it wishes with it until it's released, and
there's no way to know when that is.
OK: what about not disposing the CGFunction, and letting the GC do its job?
This also falls flat, because there's a circular reference between the native
CGFunction and the managed wrapper, preventing any of them from being released
automatically by the GC. The only way to break the circular reference is to
dispose the managed wrapper.
So, can we fix the circular reference? Unfortunately not, because we can't
monitor the native CGFunction's retain count, which is required in order to
switch the native->managed link between weak and strong according to the
retain count.
This leaves one solution (that I could come up with at least): make sure
everything works fine after disposing the managed wrapper.
This involves a few things:
* Only break the native->managed connection (the 'gch' GCHandle) when the
native CGFunction is freed. This is accomplished by using the API provided
by Apple for exactly that purpose (the 'release' callback field in the
'CGFunctionCallbacks' struct).
* Use a static variable for the 'CGFunctionCallback' struct and its contents.
This solves another potential problem: the GC could have collected the
delegate to the 'EvaluateCallback' function at any point.
* Don't null out the 'evaluate' delegate in Dispose. This leaves the user with
no way to break a potential circular reference through that delegate (since
it will never be null), so provide a property that makes it possible for
users to explicitly null out the delegate ('EvaluateFunction').
* Only call the 'evaluate' callback if it's not null.
This also has the additional advantage that test (and any customer code
running into the same issue) works without modifications.
Some of the tests fail because the assert is looking at the wrong iOS
version. Looking at the API definitions:
* UIStackView - Available in iOS 9, not iOS 8.
* AudioServicesPlayAlertSoundWithCompletion - Available in iOS 9, not
iOS 8.
All the other tests reported in the issue pass.
Issue: https://github.com/xamarin/xamarin-macios/issues/4437
* [CoreGraphics] Add CGPDFArray.Get* overloads that take a nint index, since the CGPDFArray.Count property returns nint.
This makes the following code work:
for (var i = 0; i < array.Count; i++)
array.GetInt (i, ...)
* Don't add [MonoPInvokeCallback] to Mac code.
* [CoreGraphics] Rename CGPDFArray.ApplyBlockCallback to ApplyCallback.
Since the fact that the method is implemented using a block is not relevant
for managed code.
This also makes the method named like an equivalent method in CGPDFDictionary.
* [CoreGraphics] Change CGPDFArray.Apply to take an 'object' as the info parameter instead of IntPtr.
This makes it nicer for managed code.
* [CoreGraphics] CGPDFArray.Apply: resolve the iterated object to the actual CGPDFObject type.
* [CoreGraphics] Add an CGPDFDictionary.Apply overload that resolves the iterated object to the actual CGPDFObject type.
This method was previously only available in Classic, so I just reintroduced
it with a few changes to make the API nicer (which isn't a breaking change
since we're not building Classic anymore).
* [tests] Add test for CGPDF types.
* [tests] Don't run the new tests unless the SDK was part of Xcode 10
* [CoreGraphics] Add first batch of Xcode10 APIs, added an enum that we did not surface before
* [xcode10] CoreGraphics support
* Fix whitespace/formatting and add comma after last enum value.
* Make CFPropertyList follow normal INativeObject creation pattern.
* Make CFPropertyList.AsData return the error as a tuple.
* Fix CFPropertyList.AsData to not leak.
* CFPropertyList.Value: use Runtime.GetNSObject so that we don't accidentally create duplicate wrappers for the same native object.
* [CoreGraphics] Update to beta 5.
* Update xtro definitions.
* Add tests.
* Don't compare value type with null.
* Use PascalCase for named return tuples.
* [CoreFoundation] Make CFPropertyList enums native and fix code accordingly.
* [tests] Fix fetching 64-bit int to actually fetch a 64-bit int and not a nint.
* [tests] Teach introspection's ApiCMAttachmentTest about CFPropertyList.
The default `Message` property is not every helpful. Better information
is available inside the `Error` property but it's not general (nor cross
platform) when dealing with exception.
Include unit tests (on an existing test checking NSError values)
https://github.com/xamarin/xamarin-macios/issues/4133
Unify the code to detect frameworks that aren't supported in the simulator (we
had switches in two places, now this data is stored per framework).
Also remove some of the Metal frameworks for some of the platforms from these
lists (since they're now available in the simulator in some cases), which
fixes#4422.
It also seems CoreAudioKit is now available in the simulator (it wasn't in the
first Xcode 7 beta, but apparently added in a later beta. This made our
exclusion incorrect, but we never noticed).
https://github.com/xamarin/xamarin-macios/issues/4422
- Updated some ARReferenceObject APIs based on their (better) Swift names. Breaking changes but on new APIs.
- Update ARReferenceObjectTest for device (center and extent have real values on device).
- Reuploaded an arobject file from Beta 3 just in case because of: "ARReferenceObject and ARWorldMap data generated using iOS 12 beta 2 or earlier isn’t compatible with beta 3 or later. Please rescan your objects to generate new ARReferenceObject and ARWorldMap data."
[tests] Run Xamarin.Mac tests on Mojave, and add more Xamarin.Mac tests.
* Add more Xamarin.Mac tests: introspection, link sdk, link all and xammac_tests.
* Fix TextureAtlasTest.Empty to not crash due to Apple not liking null callbacks. (#4003)
* Run Xamarin.Mac tests on Mojave as well, even though the build OS is an earlier OS (High Sierra).
* Fix many version checks to be based on Xcode version instead of iOS version.
* Added/fixed a few expected values according to platform version to match behavior in older macOS versions.
* Convert it into a MM8027/MT8027 error (with documentation).
* Add information about the selector and managed method that triggered the error.
Now the problem reported in issue #4254 shows up as:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
> Additional information:
> Selector: popoverController:willRepositionPopoverToRect:inView:
> Method: UIKit.UIPopoverController+_UIPopoverControllerDelegate.WillReposition(UIKit.UIPopoverController, CoreGraphics.CGRect ByRef, UIKit.UIView ByRef)
instead of just:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
which makes it much easier to understand, track down, and fix/work around,
both for customers and ourselves.
* [ObjCRuntime] Make Class.GetHandle not handle byref types. Fixes#4254.
This is a regression between d15-6 and d15-7: it's an unindented consequence
of the changes required to link away the dynamic registrar.
This unindented consequence is non-obvious: it made Class.GetHandle
successfully look up byref types, since we're now using metadata tokens to
look up a Class from the managed Type, and it turns out the metadata tokens
are the same for byref types as the corresponding non-byref type, so
Class.GetHandle treats them identically.
This was not the behavior for Class.GetHandle in d15-6, and other code relied
on this behavior (in particular calling isKindOfClass: in Runtime.GetNSObject
with a nil class returns false, and we'd end up in a different code path that
would not try to create the managed peer with a byref type).
So make sure Class.GetHandle doesn't change its behavior compared to d15-6 by
special-casing byref types to return IntPtr.Zero.
Fixes https://github.com/xamarin/xamarin-macios/issues/4254.
* Move byref check earlier to get identical behavior when the dynamic linker is optimized away.
Also add checks for pointer and array types for the same reason.
Creating a new NSString doesn't always lead to creating a new NSString, which
will obviously cause trouble.
The scenario is:
* An NSString with the value @"Bye" is added to an NSDictionary, with the same
string as both the key and the value.
* The (managed) string indexer is used to try to get the value back. The
string indexer would call 'new NSString ("Bye")', which would create a new
managed NSString, and maybe a new native NSString (or maybe it would re-use
an existing NSString). Then the handle of this NSString would be passed to
the native API, and the same handle would come back as the result (since the
same string is both the key and the value). We'd call Runtime.GetNSString on
the returned handle, get back the same managed instance that was created
just before the call to the native method. Finally, just before returning
this managed instance from the indexer, we'd dispose it... since it was
created in a 'using' block. Then we'd return a disposed NSString object from
the indexer. Ops.
The fix is to not create a managed wrapper for the NSString handle we need to
pass to the native API, but create and free the native NSString object without
using a managed wrapper.
I obsoleted `GetProjectPoint` in favor of `Project` because of the introduction of `Unproject` (which made me realize the naming was wrong) and based on the API doc https://developer.apple.com/documentation/arkit/arcamera/2923538-projectpoint?language=objc.
The `CGPoint` returned is the projection of a point. An other naming option would have been `GetProjectedPoint` but I think `Project` is closer to the original and clear enough. You project/unproject something onto something else and you get the projection back.
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
* [Compression] Ensure we use the correct lonking flags for older versions. Fixes#4129.
Libcompresison was added after iOs 9.0, TvOS 9.0, Mac 10.11 and Watch
2.0. We want to use weak in those older platforms.
Fixes issue https://github.com/xamarin/xamarin-macios/issues/4129