This change allows to ignore the use of cookies and cookie containers in
the NSUrlSessionHandler. There are two different cookie containers to
consider:
1. The native NSHttoCookieStorage.
2. The managed CookieContainer.
If the native one is set to null, the native code will not use a cookie
storage, which is used as a flag to ignore the managed one.
There is an interesting situation, we allow different types of sessions.
From the cookie storage point of view, Default and Background sessions
are the same, but Ephemeral is not, since we only want to store in ram
the cookies and do not share them.
This supposes a problem because Apple does not provide any API that will
allow to determine the session type use in the configuration. The
workaround has been to hide the direct native call for the configuration
and add an enum value that can later be accessed in the
NSUrlSessionHandler. Of course things cannot be that easy. When a
session is created with the configuration, it creates a copy, and the
internal session configuration does not longer have the flag, therefore,
we need to store the session type in the handler.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7659
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Use a single point where the different enpoints can be found so that
if they need to be updated (server issues or other) it is a simple
change that will affect all tests in monotouch-tests
microsoft.com is doing user agent sniffing, and broke our our test since their
output is now different. Switch to example.com instead.
Fixes https://github.com/xamarin/maccore/issues/2006.
We do have a test that fails when there are issues accessing the remote
resource. Try different urls to ensure that it is not a network issue with a specific domain.
Fixes: https://github.com/xamarin/maccore/issues/1725
* NSDataDetector
* Add constructor found in header. No idea where the commented-out
constructor came from, it's not in the header, so I removed it.
* Add overloads that take NSTextCheckingType in addition to
NSTextCheckingTypes. Apple's API take NSTextCheckingTypes, but all the
documentation and samples say that you're supposed to pass one or more
or'ed NSTextCheckingType values, so support that as well without casting
between enums.
* NSRegularExpression
* GetMatches had the wrong return type, so add a GetMatches2 that does it
right. Also add a test to make sure it's really right.
* Bind 'regularExpressionWithPattern:options:error:' with a static method.
There's a corresponding constructor, but constructors returning out
NSError parameters isn't the nicest API (when the NSError is important),
so add the static method as well.
* Add a missing [NullAllowed] on FindFirstMatch's return value.
* NSRegularExpressionOptions
* Add missing enum value.
Fixes https://github.com/xamarin/xamarin-macios/issues/5881.
NSNotificationCenter is thread-safe, so that observers can be added and
removed in multiple threads simultaneously.
Unfortunately our own helper code wasn't, so make sure to fix that by locking
around all accesses to the observer list.
And add a test case as well.
- 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 []`.
* 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.
* [tests] Determine at runtime instead of compile time whether LinkAll is enabled. Fixes#3812.
This way we can remove the LINKALL define, which also means nobody can forget
to define it when building using LinkAll.
https://github.com/xamarin/xamarin-macios/issues/3812
Repetitive calls to `NSNull.Null.Handle`, e.g. from `NSArray.UnsafeGetItem<T>`,
means several (one by item), costly, calls into ObjC code - but it always
return the same (native) singleton.
This manually cache the managed `NSNull.Null` static value, once it's
initialized the first time, so future calls won't have the performance
penalty.
https://github.com/xamarin/xamarin-macios/issues/3544
Add a 'register-protocols' optimization that:
Improves static registrar to:
* Generate a new table of protocol -> managed wrapper type. This is required
to find the wrapper type without having the `[Protocol]` attribute around.
* Make the generated code implement protocols from [Adopts] attributes. This
makes it possible to link away the `[Protocol]` attribute, because the
native implementation of `conformsToProtocol:` does the right thing (we
might even be able to link away our complete `ConformsToProtocol` logic when
we remove the dynamic registrar).
Improves linker to:
* Not mark protocol interfaces by the mere virtue of having a type that
implements them. This is implemented by not marking protocol interfaces when
they're implementing a class, but instead when a method implementation is
found to implement a method from a protocol interface.
* Mark the wrapper type for protocols (this allows us to remove the Protocol
attribute, since that's the link between the protocol and its wrapper type).
* Remove the [Protocol], [ProtocolMember] and [Adopts] attributes (but only if
optimizing protocols).
The static registrar still needs some of the information linked away, so a few
changes are required to make it available post linker.
Benchmark
---------
I've compared the size of entire apps built for device:
|test | Before | After | Diff | % |
|:-----------------------------|-------:|-------:|-------:|------:|
|[monotouch-test/Debug][1] | 101mb | 100mb | -888kb | -0.9% |
|[monotouch-test/Release][2] | 99.2mb | 95.4mb | -830kb | -0.9% |
|[minimalistic app/Debug][3] | 10.8mb | 10.4mb | -443kb | -4.1% |
|[minimalistic app/Release][4] | 4.7mb | 4.55mb | -157kb | -3.3% |
[1]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#monotouch-test-debug
[2]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#monotouch-test-release
[3]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#minimal-xi-app-debug
[4]: https://gist.github.com/rolfbjarne/0181ab8abe436c34cf4ee68ecfb8cd18#minimal-xi-app-release
The original, now obsoleted, `LocalizedString` API returned a .net
`string` which does not work in most cases.
Different versions of iOS seems to return different (public or internal)
subclasses of `NSString` that are understood by other API (like NSString
`localizedStringWithFormat:`) for further customization.
Our logic to convert NSString to string is correct but it cannot
recreate the custom, required subclass to continue the localization.
So the new API return an `NSString` publicly (which is actually a
subclass) that can do the required job.
Adding a test in monotouch-test is presently blocked by #3265 [2]
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41292
[2] https://github.com/xamarin/xamarin-macios/issues/3265
* Add tests for new (and old) NSBundle API and adjust old ones since adding a Base.lproj directories changes things
* Add localization to xammac_tests since it shares the same, updated tests
and ensure the temporary `NSString` instance is disposed asap.
Found will debugging something else. Unit tests added to confirm there
is no behavior change when the API are used.
* [MSBuild] Do not set CFBundleDevelopmentRegion if not present.
This is a complicated fix. This is a regression introduced by Apple.
CFLocaleCopyCurrent(), used in the iOS code, will return the value of
the application's CFBundleDevelopmentRegion Info.plist key if all of the
following conditions are true:
* CFBundleDevelopmentRegion is present in the Info.plist
* The CFBundleDevelopmentRegion language is in the list of preferred
languages on the iOS device, but isn't the first one
* There are no localized resources (i.e. no .lproj directory) in the app
for the first preferred locale
This differs from iOS 10 where the presence of the
CFBundleDevelopmentRegion key had no effect.
Note that if the CFBundleDevelopmentRegion key is not present at all,
CFLocaleCopyCurrent() always returns the first preferred locale as it
did in iOS 10.
We are adding the key by default in the plist of the applications which confuses users since they do not see the key in the .plist added by the template. This commit removes it to be more explicit and help users understand the behaviour.
Hopefully third time's the charm...
Don't do date math (adding hours) to a local datetime, since DST *will* muddy
the waters and prove that 1=2.
Instead convert the date we want to calculate on to UTC, which should be DST-agnostic.
I've tested this by running the test for every hour during the next 10 years,
so that should cover mostly everything (although I'm still waiting for the
Delorean I ordered to be able to test both in the future and the past).
Previous attempts:
0442cdf9c05caddb3571
Should fix https://github.com/xamarin/maccore/issues/573.
In 0442cdf9c0 the `now` variable was changed to
be a UTC date, but unfortunately the code that compares it to a local date
(NSDate.Now) wasn't updated.
Only year/month/day values were compared, which meant the test would fail if
run when UTC and local time didn't represent the same date (and conversely
would pass if the UTC and local date was the same date, which is why the
changed did not fail the PR test run: the PR was tested during the 19 hours of
the day when EST and UTC represent the sam date).
Fix this by converting the UTC `now` to NSDate instead of using NSDate.Now.
This has the additional benefit of also fixing a (much smaller) race
condition: if midnight occurred just between calculating `now` and NSDate.Now,
the test would also fail.
At 2:00 AM on November 5h 2017, winter came to our bots in Boston.
This meant that between 2:00 and 3:00 AM, subtracting 1h from the current
time yielded a time difference of 2h.
This was caught by our observant tests:
[FAIL] CalendarTest.DateComponentsTest : b hour
Expected: 1
But was: 2
To avoid such issues next time this test happens to run during this single
hour of the entire year that causes problems, change the test to use time
calculcation using UTC instead.
The explicit operator did all it's math using `long` (the internal
representation for DateTime) so the fractional part of the NSDate was
lost. E.g.
> original: 530499149.239266
> roundtrip: 530499149.0
However even when using `double` computations we're still losing some
precision - parts just can be held in the `long` (Ticks) representation
of DateTime.
> original: 530499149.239266
> roundtrip: 530499149.23927
Reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=32022
* [monotouch-test] Disable EmptyNib tests due to Xcode9 no longer builds nibs if deployment target < 7.0
EmptyNib.xib : ibtool error : Compiling IB documents for earlier than iOS 7 is no longer supported.
* [monotouch-test] Fixt CalendarTest.TestEnumerateDates
It seems that NSCalendar.CurrentCalendar.EnumerateDatesStartingAfterDate
won't stop enumerating unless `stop` is set to `true`.
* [Tests] Add CheckXcodeVersion support for Xcode 9
* [introspection] Avoid introspection to crash with Xcode 9 Beta 1
* [monotouch-test] bring back LogicalName removal from monotouch-test.csproj
Manuel de la Pena
Vũ Đức Tuyến
Rolf Bjarne Kvinge
Waleed Chaudhry
monojenkins
Sebastien Pouliot
Marius Ungureanu
Vincent Dondain
Chris Hamons
kunigaku
Timothy Risi
Sebastien Pouliot
Alex Soto