Platform specific API

[pictos]

This PR implements the Platform Specific APIs using Xamarin.Forms API. We need to agree with:

1. Folder structure;
2. Namespace structure;

With this implementation, we are able to implement platform-specific features in the same way that Forms does.

We can do it on C#

using Xamarin.Forms.PlatformConfiguration;
using Xamarin.CommunityToolkit.PlatformConfiguration.iOSSpecific;
using Xamarin.CommunityToolkit.PlatformConfiguration.WindowsSpecific;

// API usage example
On<iOS>().UseArrowDirection(PopoverArrowDirection.Right);
On<Windows>().SetBorderColor(Xamarin.Forms.Color.Red);

And in XAML

xmlns:uwpXct="clr-namespace:Xamarin.CommunityToolkit.PlatformConfiguration.WindowsSpecific;assembly=Xamarin.CommunityToolkit"
xmlns:iosXct="clr-namespace:Xamarin.CommunityToolkit.PlatformConfiguration.iOSSpecific;assembly=Xamarin.CommunityToolkit"
iosXct:PopUp.ArrowDirection="Right"
uwpXct:PopUp.BorderColor="Blue"

Following the Forms implementation, the Xamarin.CommunityToolkit.PlatformConfiguration shouldn't be in our custom schema (http://xamarin.com/schemas/2020/toolkit).

Fixes #948

[pictos]

need to use the XFPC.iOS because the compiler complains that iOS is a namespace, during the build.

[AndreiMisiukevich]

Do we really want to handle it by "PlatformConfiguration" as Forms does?

Maybe, we might add properties to shared classes with some comment telling that a certain property is supported only by iOS, for example, or iOS and Android etc.
Or even add iOS or Android prefix/postfix.

IOSArrowDirection
ArrowDirectionPlatformSpecific

/// This propertu is iOS-specific
ArrowDirection

CC @jfversluis @pictos @sthewissen @jsuarezruiz

[pictos]

Maybe, we might add properties to shared classes with some comment telling that a certain property is supported only by iOS, for example, or iOS and Android etc.

@AndreiMisiukevich the problem that I see with this approach, is that isn't very clear/explicit. In that way at first glance looks like that feature is supported by all platforms. I'm ok to not use the Forms API and create our own but we need to make it in a way that will be explicitly and reusable.

Or even add iOS or Android prefix/postfix.

This may help, but I need to think a bit more about it, right now I can which can lead to some confusion for contributors.

Also, I can see a problem in how we will handle that in other platforms, like if that prop. is on shared code, all platforms will see it and we (us on XCT and users on their apps) need to treat it on all platforms, doing null checks or PlatformChecks

[Cfun1]

As discussed with @pictos it could be problematic when for the same feature/functionality (at shared code level) some flags are only supported by specific platform, while in others it doesn't exist or with a different name, we could rename or map the flags internally but it won't be a nice approach I think. Not sure yet but I think this could be a solution to that problem.

@AndreiMisiukevich my concern is xaml platform specific flags like in this spec #718.

[jfversluis]

Totally unrelated, I think we can create an extension for this, right? I remember us doing it for something else, that will make this syntax better

[SkyeHoefling]

What kind of markup extension are you thinking? The PopupSize is a helper for the sample project to make it easier to specify size.

Are you thinking about making this something that consumers of XCT could use for their Popups? That may be a really useful API.

[jfversluis]

What's the use of Unknown? @ahoefling?

[SkyeHoefling]

This was added in #854 by @geskill and I approved the changes.

I am not 100% sure what Unknown or Any is used for. Looking at the code this maps 1:1 with the iOS implementation. Since this is iOS specific I think it is okay to leave both of them in. If we get to a point where we want to make this a shared API instead of attached property we would need to determine if it is still applicable.

[Cfun1]

Reference: https://developer.apple.com/documentation/uikit/uipopoverarrowdirection/

[jfversluis]

Do we really want to handle it by "PlatformConfiguration" as Forms does?

Maybe, we might add properties to shared classes with some comment telling that a certain property is supported only by iOS, for example, or iOS and Android etc.
Or even add iOS or Android prefix/postfix.

IOSArrowDirection
ArrowDirectionPlatformSpecific

/// This propertu is iOS-specific
ArrowDirection

As already mentioned by the other people above there is some concerns with that too. Both ways have their up- and downsides for sure. Picking between these I think the best choice is to be consistent with Forms and use the platform-specific stuff. People know that approach and there is no confusion over what is implemented in what platform or clutter our property names with prefixes etc.

But I appreciate you trying to find an alternative Andrei! It would be easy to just copy what Forms does without thinking, we should stay sharp :)

[SkyeHoefling]

@AndreiMisiukevich I requested the iOS specific arrows class be added in since it is not implemented in Android or UWP. If we get to a point where arrows are implemented in the 3 major platform iOS, Android and UWP I think we can remove that class and make it a shared class.

[pictos]

@AndreiMisiukevich @jsuarezruiz @jfversluis can you re-review it?

[pictos]

@brminnick , @AndreiMisiukevich @jfversluis @jsuarezruiz can you re-review this API? That way we can merge it and unblock a couple of PRs