Fix these warnings:
src/Foundation/NSUrlSessionHandler.cs(71,57): warning CS3001: Argument type 'NSUrlSessionConfiguration' is not CLS-compliant
src/Foundation/NSUrlSessionHandler.cs(89,14): warning CS0618: 'NSUrlSession.FromConfiguration(NSUrlSessionConfiguration, NSUrlSessionDelegate, NSOperationQueue)' is obsolete: 'Use the overload with a 'INSUrlSessionDelegate' parameter.'
When debugging watchOS apps on device, we wait forever [1] for a connection to
be established to the IDE (iOS apps wait for only 2 seconds, but that's
because the app will be killed after a while, which we avoid on watchOS by
attaching the native debugger).
Unfortunately our error handling was not quite optimal, which meant that if
the connection to the IDE failed, we'd wait forever instead of launching the
app without attaching the debugger.
So improve this, by printing "Waiting for connection to the IDE..." messages
while trying to connect, and printing detailed log messages if the
connection attempt fails (as well as terminating the wait and launching the
watch app).
[1] In this case forever technically means "1 hour".
Instead of a generic `MT0000` caused by an exception reading the magic
numbers of the binary framework file.
This was caused be uncompressing an archive, with a symlink, into a
file system that does not support symlinks (on Windows).
ref: https://github.com/xamarin/xamarin-macios/issues/5028
This method is called back from iOS (or tvOS) so there's no managed
reference pointing to it. However we know that if it's (private inner)
type is present it's because the callback (from native) is possible so
we can preserve the method conditionally (to the type presence).
https://github.com/xamarin/xamarin-macios/issues/5024
Unce upon a time we used a separate mono submodule for watchOS support, to make
development of watchOS support easier (we referenced mono/master, to avoid
backporting fixes for watchOS support through various release branches in
mono).
This only worked until our watchOS support became stable, since then we had to
start using a stable version of mono for watchOS support.
This means that our build support for using a separate mono clone for watchOS
support is no longer needed; and in any case it's broken because of build
changes done later.
- 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
* Refactor type map to have a separate flag field for each type instead of magic location in the array.
Refactor the type map to have a separate flag field for each type instead of a
magic location in the array. This simplifies some code, but also allows us to
introduce more flags in the future (which becomes increasingly complex if the
location in the array is to determine yet another value).
This has neglible performance impacts.
* Add a UserType flag for registered types, and use it to improve the performance for is_user_type.
Reflection in the Objective-C runtime is apparently quite slow, so try to
avoid it by computing the information we need for determining whether a
particular Objective-C type represents a user type or not in the static
registrar.
We store this information in a flag for the type in question in the type map,
and use a binary search to search the type map when needed.
This provides a significant improvement, in particular in the dontlink
scenario (probably because there are many more Objective-C types in the app,
which made Objective-C reflection slow). In fact, it somehow made the dontlink
scenario so fast that it's faster than the linkall scenario (which also
improved, but not nearly as much). While quite inexplicable, it's a consistent
result I've seen over multiple test runs.
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 refers to PR #5013.
Fix 3 refers to PR #5016.
Fix 4 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 172 ms | 148 ms | 24 ms (14%) | 329 ms (69%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 201 ms | 146 ms | 55 ms (27%) | 592 ms (80%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | After fix 4 | Improvement from fix 3 to fix 4 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 31 ms | 29 ms | 2 ms ( 6%) | 69 ms (70%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 43 ms | 28 ms | 15 ms (35%) | 169 ms (86%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 4 (the last) of multiple fixes for #4936.
The total speed-up is 69-86% (3-7x faster).
Using reflection to find these constructors is computation-intensitive, so
cache the results.
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 refers to PR #5013.
Fix 3 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | Improvement from fix 2 to fix 3 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 172 ms | 52 ms (23%) | 305 ms (64%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 201 ms | 176 ms (47%) | 537 ms (73%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | After fix 3 | Improvement from fix 2 to fix 3 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 31 ms | 11 ms (26%) | 67 ms (68%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 43 ms | 48 ms (53%) | 154 ms (78%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 3 of multiple fixes for #4936.
Cache the Class -> System.Type lookup in an array.
I could also have used a dictionary, but there are a couple of disadvantages
compared to the array approach:
* A dictionary would require a lock every time it's read/written to. The array
is created at launch, and after that we don't have to care about thread
safety because it's safe to do the slow lookup multiple times.
* Its memory requirements would be higher with more elements (in particular
since we'd not only need to store the Type instance, but also a boolean
determining whether it's a user type or not).
* It's ~1% slower (probably due to the lock).
Numbers
=======
Test case: 004283d7b6
Fix 1 refers to PR #5009.
Fix 2 is this fix.
iPad Air 2
----------
| Configuration | Before | After fix 1 | After fix 2 | Improvement from fix 1 to fix 2 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 477 ms | 481 ms | 224 ms | 257 ms (53%) | 253 ms (53%) |
| Release (dont link) | 738 ms | 656 ms | 377 ms | 279 ms (43%) | 459 ms (62%) |
iPhone X
--------
| Configuration | Before | After fix 1 | After fix 2 | Improvement from fix 1 to fix 2 | Cumulative improvement |
| ------------------- | ------ | ----------: | -----------: | ------------------------------: | ---------------------: |
| Release (link all) | 98 ms | 99 ms | 42 ms | 57 ms (58%) | 56 ms (57%) |
| Release (dont link) | 197 ms | 153 ms | 91 ms | 62 ms (41%) | 106 ms (54%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 2 of multiple fixes for #4936.
Our type map has two sections: first come all the wrapper types, then all the
custom types. This means we need to sort these two sections separately, since
code elsewhere depends on this split in order to determine if a type is a
custom type or not.
We also need a minor modification in the array of skipped types, since it
contained indexes into the type map, which won't be valid after is has been
sorted. Instead store a type reference for the actual type in the array, and
use that to search the type map for the corresponding Class. This is a little
bit slower, but the results are cached in a dictionary, so it'll only happen
once for each type.
The performance is slightly slower when the type map has very few entries, but
that is repaid many times over when the number of entries go up.
Numbers
=======
Test case: 004283d7b6
iPad Air 2
----------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ------------: |
| Release (link all) | 477 ms | 481 ms | -4 ms (-0,8%) |
| Release (dont link) | 738 ms | 656 ms | 82 ms (11%) |
iPhone X
--------
| Configuration | Before | After | Improvement |
| ------------------- | ------ | ------ | ----------: |
| Release (link all) | 98 ms | 99 ms | -1 ms (-1%) |
| Release (dont link) | 197 ms | 153 ms | 44 ms (22%) |
When linking all assemblies, the type map has 24 entries, and when not linking
at all it has 2993 entries.
This is part 1 of multiple fixes for #4936.
`ContentOffset` was moved to `UIFocusItemScrollableContainer` in iOS 12.
Since it's a new protocol it's decorated as introduced in iOS 12 - but
the API was actually already available for a long time.
The _trick_ is to keep the original binding inside `UIScrollView`
so it overrides the protocol and keeps the correct availability info.
It requires adding `new` to bindings to avoid compiler warnings.
reference: https://github.com/xamarin/xamarin-macios/issues/4893
---
from @rolfbjarne
In iOS 12 this property was moved to a protocol, but that protocol's
availability attributes limits it to iOS 12, not iOS 2 where this property was
originally introduced.
This is problematic, because it means we'll throw a
PlatformNotSupportedException if someone tries to call it on 32-bit iOS.
So put the property back on UIScrollView, so that the generated code ends up
with the right availability attributes (and a correct 32-bit implementation).
https://github.com/xamarin/xamarin-macios/pull/5004
* [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.
The custom `TryGetValue` could return `true` and an `out null`. That was
fine for many items, e.g. converting `null` to `NSString` or `NSDate` is
fine.
However this cause an `NullReferenceException` when trying to create
arrays (thru `NSArray`) or converting `NSNumber` into value types.
The _normal_ `TryGetValue` behavior fixes this - and avoid extraneous
(and non-required) conversions of `null` items.
ref: https://github.com/xamarin/xamarin-macios/issues/4988
The custom `TryGetValue` could return `true` and an `out null`. That was
fine for many items, e.g. converting `null` to `NSString` or `NSDate` is
fine.
However this cause an `NullReferenceException` when trying to create
arrays (thru `NSArray`) or converting `NSNumber` into value types.
The _normal_ `TryGetValue` behavior fixes this - and avoid extraneous
(and non-required) conversions of `null` items.
ref: https://github.com/xamarin/xamarin-macios/issues/4988
The assert message `TestRuntime.AssertNotWatchOS ("X509Certificate (byte[]) doesn't work on watchOS")`
is clearly wrong as `X509Certificate (byte[])` is supposed to work on all platforms.
Still investigating whether the rest of the test will work on watchOS or not (and why if it doesn't).
Bernhard Urban
Rolf Bjarne Kvinge
Martin Baulig
Sebastien Pouliot
Jeffrey Stedfast
Vincent Dondain
monojenkins
Miguel de Icaza
Martin Baulig
Chris Hamons