[Enhancement] RenderPlatform, Islands, platform-agnostic renderers

[JeroMiya]

Summary

Suggestion: Implement a set of platform agnostic renderers. That is, these renderers would not use platform native controls, but would rather render the entire UI to a surface that is then displayed on each platform. Provide a mechanism to opt-into this set of renderers at some feasible level of granularity (e.g. per-app, per-page, or perhaps even per-view?).

API Changes

Initially it appears that using the new Visual system would be a good fit for the opt-in mechanism - perhaps using Visual="MaterialCanvas" instead of Visual="Material" to select Material styling on the platform-agnostic renderers. However, the new renderers more closely resemble a platform than a visual. It's likely that these renderers would break compatibility with existing controls unless they use only built-in Xamarin.Forms controls, with no native renderers.

Therefor, I propose a (name tentative) RenderPlatform property, at the appropriate level of granularity (App, Page, View), as feasible. The acceptable values of RenderPlatform are Default (the default renderer selection for the current platform), and one representing these new renderers, e.g. Canvas.

Let's say the level of granularity that is feasible is on a Page by Page basis. Here is how you would opt-into the platform agnostic renderers on a particular ContentPage:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MyApp.ExamplePage"
             Title="{Binding Title}"
             RenderPlatform="Canvas">
</ContentPage

Next, there needs to be a way to provide a renderer for a specific RenderPlatform. An optional parameter/overload of the Xamarin.Forms.ExportRenderer method would be added:

[assembly: Xamarin.Forms.ExportRenderer(typeof(MyControlType), typeof(MyControlTypeRenderer), RenderPlatform.Canvas)]
[assembly: Xamarin.Forms.ExportRenderer(typeof(MyControlType2), typeof(MyControlTypeRenderer2), UIUserInterfaceIdiom.Pad, RenderPlatform.Canvas)]

If not specified, Default is implied.

The following is a "stretch goal", but would make this feature much more useful, especially for existing applications:

There is potentially a need to integrate controls designed for the "Default" RenderPlatform within an app using the platform agnostic renderers. Or, the opposite: an app that uses the default RenderPlatform but wants to use a control or portion of the UI that uses the new platform-agnostic renderers. This would be accomplished with "islands":

<ContentPage RenderPlatform="Canvas">
    <StackLayout>
        <Button Text="This button uses the platform-agnostic canvas renderers" />
        <Island RenderPlatform="Default">
            <Button Text="This button uses the platform-native renderer" />
        </Island>
    </StackLayout>
</ContentPage>

If creating a third party control, it might be convenient to dynamically configure specific settings for each RenderPlatform. We can't use OnPlatform, because the platform is still iOS/Android/etc..., so add an equivalent for RenderPlatform:

<OnRenderPlatform x:TypeArguments="x:Double">
    <On RenderPlatform="Default" Value="20" />
    <On RenderPlatform="Canvas" Value="30" />
</OnRenderPlatform>

Intended Use Case

One of the intended use cases of the new Visual system in Xamarin.forms 4.0 is consistent UI rendering between platforms. This is good, because platform-specific tweaks and styling is one of the biggest sources of development pain in Xamarin.Forms. However, the Visual system doesn't go far enough. While Visual styles native controls to look like a particular application style - they are still native controls, and thus are not "pixel perfect" across platforms. This means that teams will still have need of platform-specific tweaks to margins and layout to accommodate the differences.

RenderPlatform could work hand-in-hand with the new Visual system to provide not just styling consistency, but full pixel-perfect layout and rendering consistency between platforms. And, being free from the requirement to keep a native UI tree synced to the virtual one in XAML/Code, Xamarin.Forms could provide significantly improved performance and smoothness, particularly with respect to UI animations and scrolling.

This suggestion is not a duplicate of #1789 as I am not proposing a new subset of controls but rather a system for rendering the existing controls using a platform-agnostic renderer.

[jfversluis]

Awesome write-up and so sorry we never got to properly respond to this! I think you should be pretty happy with what is now .NET MAUI :)

If you have any more ideas around this please make sure to pitch in over at the .NET MAUI repo.

[JeroMiya]

Awesome write-up and so sorry we never got to properly respond to this! I think you should be pretty happy with what is now .NET MAUI :)

If you have any more ideas around this please make sure to pitch in over at the .NET MAUI repo.

Thanks for the response! Unfortunately, it has been quite a while since the nature of my work involved native or mobile application development - everything I'm working on now and in the foreseeable future will be pure web development. And, well, MAUI doesn't natively support the web as a first class supported platform. Also, I understand that MAUI, like Xamarin.Forms, still mainly supports mapping MAUI controls to native controls - not platform agnostic controls rendered to a canvas, yes?

In terms of UI frameworks for the web, we really only have three choices: a web-native framework, Blazor, or Flutter. We chose a web-native framework (Angular, specifically), as it fit our needs best. If we were to use a framework other than a web-native one, we'd probably choose Flutter over Blazor. While Flutter uses vector drawn controls and has advantages in terms of presentation and animation, Blazor is just an HTML/CSS framework. It's a good HTML/CSS framework (I'd say better than most JS based ones), but there just isn't much benefit outside of "you can use C# instead of JavaScript" to justify the friction of the tooling in its current form, vs just using Angular or React/etc.... TypeScript is pretty good too!

[jfversluis]

Also, I understand that MAUI, like Xamarin.Forms, still mainly supports mapping MAUI controls to native controls - not platform agnostic controls rendered to a canvas, yes?

That is correct. .NET MAUI will follow the same paradigm as Xamarin.Forms here. However!

Since the net .NET MAUI architecture is now much more pluggable and loosely coupled, that makes it easier to insert a fully rendered canvas. Efforts on that are here: https://github.com/dotnet/Microsoft.Maui.Graphics.Controls feel free to explore and provide feedback :)

Also thanks for your response and insights!