Given the following API definition:
```cs
[Protocol]
public interface Protocol {
[Abstract]
[Export ("requiredMethod")]
void RequiredMethod ();
[Export ("optionalMethod")]
void OptionalMethod ();
}
```
we're now binding it like this:
```cs
[Protocol ("Protocol")]
public interface IProtocol : INativeObject {
[RequiredMember]
[Export ("requiredMethod")]
public void RequiredMethod () { /* default implementation */ }
[OptionalMember]
[Export ("optionalMethod")]
public void OptionalMethod () { /* default implementation */ }
}
```
The main difference from before is that the only difference between required
and optional members is the [RequiredMember]/[OptionalMember] attributes.
This has one major advantage: it's now possible to switch a member from being
required to being optional, or vice versa, without breaking neither source nor
binary compatibility.
It also improves intellisense for optional members. In the past optional
members were implemented using extension methods, which were not very
discoverable when you were supposed to implement a protocol in your own class.
The main downside is that the C# compiler won't enforce developers to
implement required protocol members (which is a necessary side effect of the
fact that we want to be able to switch members between being required and
optional without breaking compatibility). If this turns out to be a problem,
we can implement a custom source analyzer and/or linker step that detects
missing implementations and issue warnings/errors.
This PR also:
* Adds numerous tests.
* Updates the requiredness of a few members in Metal to test that it works as
expected.
* Adds documentation.
* Handles numerous corner cases, which are documented in code and docs.
This PR is probably best reviewed commit-by-commit.
Fixes https://github.com/xamarin/xamarin-macios/issues/13294.
Import all the xml documentation for types from https://github.com/xamarin/apple-api-docs.
Some of this documentation should probably be rewritten, and potentially moved
to conceptual documentation, in particular those that contain images (because
images can't be imported into xml documentation).
Note that the documentation hasn't been modified in any way; that's not the purpose of this PR. If documentation should be modified for whatever reason, it can be done in a later PR.
The xml documentation for members will come in a later PR.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/17399.
Add support for binding constructors in protocols.
Given the api definition:
```cs
[Protocol]
public interface Protocol {
[Abstract]
[Export ("init")]
IntPtr Constructor ();
[Export ("initWithValue:")]
IntPtr Constructor (IntPtr value);
[BindAs ("Create")]
[Export ("initWithPlanet:")]
IntPtr Constructor ();
}
```
we're binding it like this:
```cs
[Protocol ("Protocol")]
public interface IProtocol : INativeObject {
[Export ("init")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithValue:")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithPlanet:")]
public static T Create<T> () where T: NSObject, IProtocol { /* default implementation */ }
}
```
Also add documentation and tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14039.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
Note that this document is currently not published on our documentation web site.
* Consolidate on a single way to specify message arguments (* instead of {...}).
* Mark messages that will only be show in legacy as such (but keep them)
* Escape star characters in headers.
* Remove mentions of Xamarin.
* Misc other updates.
It's been a few years since we've synchronized the documentation here with the
documentation in the documentation repository
(https://github.com/MicrosoftDocs/xamarin-docs-pr/), so bring all updates done
there over here.
This PR is probably best reviewed commit-by-commit.
From https://developer.apple.com/news/?id=3d8a9yyh
> Starting March 13: If you upload a new or updated app to App Store
Connect that uses an API requiring approved reasons, we'll will send you
an email letting you know if you’re missing reasons in your app’s
privacy manifest. This is in addition to the existing notification in
App Store Connect.
>
> Starting May 1: You’ll need to include approved reasons for the listed
APIs used by your app’s code to upload a new or updated app to App Store
Connect. If you’re not using an API for an allowed reason, please find
an alternative. And if you add a new third-party SDK that’s on the list
of commonly used third-party SDKs, these API, privacy manifest, and
signature requirements will apply to that SDK. Make sure to use a
version of the SDK that includes its privacy manifest and note that
signatures are also required when the SDK is added as a binary
dependency.
[Document
preview](928100b38f/docs/apple-privacy-manifest.md)
fixes: https://github.com/xamarin/xamarin-macios/issues/20059
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Add multi-targeting support for our initial .NET 8 packs (for Xcode
15.0).
This means a library/binding project can do:
```xml
<TargetFrameworks>net8.0-ios17.0;net8.0-ios17.2</TargetFrameworks>
```
and the library will be built in two varieties: once using our iOS 17.0
bindings, and once using our iOS 17.2 bindings.
An app project can also do:
```xml
<TargetFramework>net8.0-ios17.0</TargetFramework>
```
to build with the iOS 17.0 bindings (which is typically not very useful,
since building with the latest iOS SDK is usually best).
Remove support for the Protocolize attribute from the generator, and remove
all usages of it in our api definitions - just use the protocol interface.
The Protocolize attribute was used to support binding stuff using the Model
class with Classic Xamarin code + and binding stuff using the protocol
interface with Unified Xamarin code, using the same source code.
Classic Xamarin has been dead for quite a few years ago now though, so there's
no need to keep his code around anymore, we can just upgrade the api
definitions to use the protocol interface directly.
Fixes https://github.com/xamarin/xamarin-macios/issues/14585.
---------
Co-authored-by: Alex Soto <alex@soto.dev>
This PR adds lookup tables and factory methods for INativeObjects and
NSObjects. These generated methods allow us to create instances of these
objects without needing reflection.
Closes#18358.
I created a short doc to help anyone uploading their app to Test Flight.
I targeted MacCatalyst apps for the Mac App Store but would work the
same for iOS apps.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
Fixes#17738
Addresses the initial issue of just documenting which properties are
tied to which configuration. But to make the documentation more helpful,
we should provide further context about what exactly these properties
mean. However, this isn't trivial as some properties are a bit
cryptic..once further info is acquired, it will be integrated in a later
revision.
Handle the 'need-repro' label like the 'need-info' label:
* Add a comment that we need a repro, and how to get one.
* Close the issue if no comments within 7 days.
* Add a 'need-attention' label if reporter comments.
Also add a document explaining how to create a repro, modeled after (copied)
MAUI's document (https://github.com/dotnet/maui/blob/main/.github/repro.md).
It's not used by anyone anymore, and there are better alternatives for .NET.
This removes a dependency on a private component, which makes a potential move
into the dotnet org easier.
AutoGeneratedName was a toggle to implement a certain (correct) behavior,
while at the same time not cause breaking changes.
Now that we can do breaking changes in .NET, we can remove the toggle (i.e.
the property), and just always do the right thing (that is: automatically
generate a _unique_ Objective-C name for Model classes, unless a name is
specified manually).
Ref: https://github.com/xamarin/xamarin-macios/issues/5107
* Add a configure option to use a locally built dotnet/runtime.
* Add documentation how to build dotnet/runtime the way we need it built.
* Modify our build to consume the custom dotnet/runtime if so configured.
This is useful when trying to debug the runtime locally, or trying out new
features there are no packages for yet.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233)
Diff: 424fa26148..ed6d146822
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
* [mmp] Don't ignore failures to execute pkg-config and simplify/improve logic.
* Show proper errors if pkg-config fails to execute.
* Extract logic to verify system mono version into its own function.
* Extract logic to execute pkg-config into its own function.
* Simplify code slightly.
* [mmp] Remove the MM5301 error message.
It's never used in mmp, and the same error code is already used in mtouch.
Using this option it's possible to test for the presence of a type
reference in both pre-linked and post-linked assemblies.
This makes it possible to detect if
* a 3rd party assemblies are using some specific type you would like to avoid;
* a type reference has been removed during the build (e.g. linker)
Notes:
* Custom attributes are encoded differently and not included in the assembly type references metadata.
* Assembly that define a type `X` do not have a reference (but the definition) of the type (and won't be reported).
If either the pre or post-linked warnings are not useful then it's possible
to add `-nowarn:150x` to exclude the results.
E.g.
* `-nowarn:1502` would not report references in pre-linked assemblies;
* `-nowarn:1503` would not report references in post-linked assemblies;
Finally `-warnaserror:150x` can be used to stop a build that would not
satisfy either the pre or post-linked condition.
* `-warnaserror:1502` would not report references in pre-linked assemblies;
* `-warnaserror:1503` would not report references in post-linked assemblies;
_side note_ same as https://github.com/xamarin/xamarin-macios/pull/7925
except that this one uses the localized mtouch/mmp errors only in master (so far)
Rolf Bjarne Kvinge
Michael Cummings (MSFT)
Gerald Versluis
Haritha Mohan
Šimon Rozsíval
dustin-wojciechowski
Chris Hamons
Sebastien Pouliot