What about ubiquitous things for Xamarin.Forms?

[juepiezhongren]

Thanks to Flutter, a lot of xamarin-fans are seriously considering ubiquitous looking things,@Mike-EEE, but indeed there is avalonia for years, @kekekeks.

Thanks to Skixam, @adamped, a sample project aimed to create another platform like flutter.

• Xamarin.Forms is loved and enjoyed, but it is a "limited" abstraction in the form of native wrapper, which lacks the strong customizablity in wpf and avalonia. So, Miguel de Icaza's idea of offering render-options(wrapper vs skia vs...) for current xf controls is not to provide the beauty of Flutter or Avalonia.

• Skixam is great, but it is a "Hard Fork" of Xamarin.Forms. Ubiquitous UX is great, but native UX is also needed, e.g. alert and listView refresh animation. Existing wrapper controls are still good.

So, I suggest that there should be a different set of ubiquitous looking controls(Ubis) , which is to boost the ecosystem for forms and not to compete or to replace it. My suggestions are below:

1. UbiGrid, UbiStackPanel, UbiLabel...... Ubis are better than a new platform, because it could be used together with existing forms' api without any change.

2. For nesting, "only-ubi", there should only be one renderer just like skixam' idea.

<UbiGrid>
    <UbiStackPanel>
        <UbiLabel/>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

3. For nesting, "non->ubi", renderers should be as many as root-ubis, below there should be 3

<Grid>
    <StackPanel>
        <UbiLabel/>
        <UbiButton/>
        <UbiLabel/>
    </StackPanel>
</Grid>

4. For nesting, "ubi-root", there should be 2 renderers, one skiaView renderer and one other render for nonUbis layout.

<UbiGrid>
    <UbiStackPanel>
        <Grid>
           <UbiButton/>
        </Grid>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

5. Skia is good, but to decouple it from ubi is better. Skia is only for 2D, other engines should also be given the hook. So, there will be things like this. BTW, skia into wasm is possible, but there seems to be no prototype, SO to use another engine based on web canvas API is a MUST!

<UbiGrid Engine="Skia">
    <UbiStackPanel Engine="Urho">
        <Grid>
           <UbiButton/>
        </Grid>
        <UbiButton/>
        <UbiLabel/>
    </UbiStackPanel>
</UbiGrid>

[Mike-E-angelo]

FWIW @juepiezhongren I am investigating Ooui here:
https://github.com/praeclarum/Ooui

If there is a way to package it up with Trigger.io you would be able to run .NET in all the major four food groups of iOS, Droid, Windows, and web.

It's still in a bit of a demo state, but it's caught my interest. 👍

[charlesroddie]

The OP is hard to understand but I gather that "ubi" means "a Xamarin.Forms view rendered in a platform-independent way using SkiaSharp or something similar". In that case "ubi" containers cannot contain non-ubi things. I assume the OP is a request for more people to create "ubi" views? If "ubi" views do get created I'm sure most of us would have no objection to using them.

[Mike-E-angelo]

Part of the issue here is that it would take a change in how we view "native" applications, Or rather how they are rendered. HTML5 is really the greatest example here. You can view an HTML5 page on any device and it will essentially look the same regardless of the device . IMO this is how all applications should be rendered. If you want a "platform-specific" rendering or interactions, this should be a matter of styling and/or templating (something that was easily possible with WPF 😉). That is, developers should be able to present an iOS-based UX on a Droid device and vice versa simply by applying a theme.

For all intents and purposes, HTML5 is that ubiquitous rendering mechanism, but it has been so ingrained with JavaScript it introduces prohibitive TCO when paired with .NET. What Ooui introduces is the prospect of utilizing HTML5/CSS as the rendering mechanism, while still exclusively using .NET for all the rest of development, thereby retaining knowledge, leveraging existing investments, and therefore reducing overall development costs. Developers are then left with ONE codebase for both their presentation and its supporting infrastructure, working across iOS, Droid, Windows, and Web. Something that many .NET developers have been asking for several years now.

The downside is that .NET developers will have to deal with CSS, but at this point after waiting so long for a truly ubiquitous solution, it's a concession we'll be willing to make. At least, I will. 😛

[charlesroddie]

The uservoice thread was a call for something like Xamarin.Forms. It was posted in 2015 before Microsoft bought Xamarin. Out of its requirements, Xamarin.Forms has released on 1) Windows 10 4) Droid 5) iOS , is in preview on 3) *nix (Unix/Linux) 6) Macintosh, has started with 2) Legacy Windows, and just doesn't do 7) HTML5 which is too different. And actually Windows 10, Droid, iOS, Legacy windows, and Mac cover 99.5% of client devices. Since Xamarin.Forms exists and does all this now, there is no need for another grand solution.

The only things needed are to:

• Combine Xamarin.Forms with WPF by speeding up Xamarin.WPF
• Advertise Xamarin.Forms: apparently there are still some .Net devs that don't know about it.

What you want is something different: identical cross-platform rendering. I can understand this need. That project, for Xamarin.Forms, could be split up into:

• Document the platform differences between different Xamarin.Forms controls. I think a lot of devs would find this interesting, even if they don't need precise identical rendering.
• Anyone who thinks a particular control looks too different across platforms can create one that renders identically.

[Mike-E-angelo]

Thank you for taking the time to present your views, @charlesroddie. I very much appreciate them.

and just doesn't do 7) HTML5 which is too different

That's exactly the mindset/attitude we're combating here, unfortunately. The web is simply a hosting environment, exactly like how native platforms are hosting environments for applications. By looking at the web as "different" you fall into the very costly trap of having to develop and maintain two separate code bases.

there is no need for another grand solution.

The idea here isn't another grand solution, but a simpler one. If you take time to read the comments of that UserVoice (very much alive btw 😄), there are not a lot of fans of Xamarin.Forms there. I myself support the project (and all things Xamarin!), but at the end of the day you are supporting n-number of presentation stacks, each with their own idiosyncrasies and considerations (which as we all know has lead to very poor quality which is just now getting a handle on itself). Plus, there's the whole custom renderers which has been a hassle in case you need specific rendering per platform. Contrast that with the paradigm where you are simply maintaining one presentation technology (HTML5) and platforms simply render the HTML5 they have been supporting and capable of doing so for many years now. Platform-specific rendering is applied simply by applying a particular style.

I am not saying it's perfect, but it feels a lot lighter and more maintainable in the long run -- not to mention CHEAPER, LOL!

That said, consider that the HTML5 design space is loaded with seasoned talent, especially where CSS is concerned. From a business perspective, this reduces TCO as not only are you concerned with one presentation technology offering (rather than n+), but there are plenty of resources that are able to work in this space to provide quality work around it. e.g. if you have turnover it will be easier to find a resource that knows one presentation technology (specialized -- higher quality), vs. finding one that knows n+ (generalized -- lower quality).

I know it's well-rooted in our community to think of the web as "different" but it looks more and more that that "different" is capable of upending everything we know about presentation in the .NET space.
That is my impression of what is happening, at least. I have been known to be wrong, from time to time, however. 😉

[charlesroddie]

I have no expertise in web tech and when I said too different I meant that current technology appears a long way from bridging the gap between native and web app structures. Xamarin.Web would be a nice idea but hard to implement, although there may be a proof of concept already based on Ooui. In a Xamarin.Forms context this would of course mean less html, not more.

[Mike-E-angelo]

That's the aha here, indeed. I don't think it's that difficult at all, considering. Ooui doesn't (yet) support data binding, or any sort of Xaml-constructs, but those should be easy enough to implement. Also, please don't get me wrong here as I am not a fan of HTML at all, in fact Xaml is a requirement listed in the UserVoice noted above. But now nearly 3 years later I am willing to concede this if it means one codebase for 100% market reach. Additionally, I am not sure if you saw, but Ooui is basically a wrapper/adapter model around HTML5 elements. So, you would be working with .NET objects and not having to deal with div and yuck tags. 😉 That is what has drawn my interest here, among other things.

[juepiezhongren]

@Mike-EEE Avalonia is really a nice experiment

[charlesroddie]

I think the most productive thing for Xamarin Forms developers would be to revive https://github.com/chrfalch/NControl by porting it to SkiaSharp. That will allow easy creation controls that only require certain types of interaction, and these controls will behave identically cross-platform, and immediately support all the platforms that SkiaSharp supports.

[timahrentlov]

Flutter is coming like an avalanche. A lot of work has gone into making that framework and corresponding documentation. But luckily, it is open source!

The flutter engine is c++ and Dart - almost being a subset of c# - should be "transpilable" to C# and Xamarin.

I think the most productive way of getting onboard the skia train is to have Xamarin embrace Flutter and help Google in moving it forward. Xamarin can offer better platform integration.

Yes, It is not going to be a Forms effort (ex. Redux being a more obvious choice than MVVM), but it would be sooo cool :)

Come on MS. Embrace and extend like it was yesterday. You need to do it anyway if Fuchia becomes a thing.

[opcodewriter]

Oh boy. So after flex, CSS and other crazy things which they don't even actually work completely, now Flutter? Xamarin Forms, Jack of all trades, master of none.
How about first making Xamarin Forms a truly mature stable first class framework? But wait, I think that's long overdue...

[juepiezhongren]

@timahrentlov could u show me the comparison of redux vs mvvm, where i'm eager to know

[timahrentlov]

@juepiezhongren I've haven't come across such a comparison for flutter.

[juepiezhongren]

@timahrentlov i mean to compare xamarin.forms vs react native considering mvvm vs redux

[juepiezhongren]

@Mike-EEE have u noticed the storm out of blazor and frank's ooui-wasm?

[Mike-E-angelo]

@juepiezhongren indeed... things are starting to heat up! 🎉

[juepiezhongren]

@Mike-EEE considering ubis for wasm, skiasharp is not a good option.

[juepiezhongren]

@samhouts what does t-enhencement mean?

[Mike-E-angelo]

Honestly @juepiezhongren, I think the only real option long-term is HTML5/CSS. That is why I am all about the WebSocket Bridge (Ooui) approach. It's more lightweight and less overhead than WASM. CSS sucks but with a little elbow grease I think we as developers can make it work. 😉 In any case, I get the feeling we're about 12-18 months away from something really viable, which is awesome. Ooui and Blazor are just the beginning/trailblazers (trail Blazors? hah hah).

Also, while I am at it, I do have to commend MSFT and @SteveSanderson for being experimental and innovative with their Blazor initiative. We really haven't seen something like that in a while. Very encouraging and I hope these sorts of approaches and projects continue out of MSFT. 👍

[juepiezhongren]

@Mike-EEE yes, it is the CANVAS in html5, just like baidu sponsored echarts.js, which renders pretty good. So, render-engine should be decoupled.

[Mike-E-angelo]

Pure HTML5 is faster, @juepiezhongren. The most ideal scenario is to utilize HTML5 DOM controls, as the rendering is already happening on the NATIVE canvas. 😉 Otherwise, you are then rendering on the HTML5 Canvas and updating it via JavaScript which is slooooooow by comparison and resource intensive. Of course, HTML5 Canvas can still be used for complex non-native controls (such as charting, etc), but it shouldn't be used as a rendering surface, IMO.

[juepiezhongren]

what is pure HTML5?@Mike-EEE something not js?

[Mike-E-angelo]

Right, @juepiezhongren ... utilizing all the baked-in "native" (have to be careful with that word, LOL) controls of HTML5 rather than creating new ones to render via an HTML5 canvas control (something you would see in Unity or JSIL).

Of course, this depends on your context and application you are building. In all my conversation I am assuming/considering business/LOB by default, so utilizing "pure" HTML5 would be preferred. If you are doing a game/graphics intensive scenarios then WASM is your first choice, followed by a canvas control.

[yowl]

I think HTML5 would best be left behind in favour of XF over SkiaSharp. ooui is nice, but its always going to suffer from having to convert the XF controls to HTML. Just go straight to the canvas is what I say. Accessibility/SEO would be a problem now but dont see why that couldn't be overcome same way as winforms using GDI can be accessible.

[MisterJimson]

@jassmith how exactly? Rendering raw or styling native controls? Styling native controls will always have some inconsistencies, even if minimal.

[juepiezhongren]

@MisterJimson shell is based on skia or ios CoreDraw api, i think
@jassmith so, there will be fluentShell or cupertinoShell?

[jassmith]

@MisterJimson as @juepiezhongren yes the idea is it draws fully from scratch. It wont have to draw on the target platform but you could certainly ask it to. The goal is on to bring Material (with MaterialShell at least) everywhere.

@juepiezhongren Ideally yes. The problem right now is both FluentShell and CupertinoShell would rely heavily on live blur. Android is lovely and all but somehow they've managed to avoid getting an efficient live blur view. This made Material the natural first target while we figure out exactly what to do about that problem.

[jassmith]

To be clear, Shell does not do drawing, MaterialShell does.

[gulshan]

Have you guys seen this- https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample ?
Only for desktop though, not mobile platforms.

[juepiezhongren]

@gulshan server-side is good

[PureWeen]

@juepiezhongren thoughts on
#4435

It seems similar to what you propose here except instead of being a tag it's an attribute that brings about the ubiquity and if someone were inclined they could create Visual="Skia"

[juepiezhongren]

@PureWeen i dont treat visual="skia" a good suggestion, simply because current xf's controls lack two much properties for personal customization, eg. brush, controlTemplate, etc.

[juepiezhongren]

or, just make current controls full api implemented, lots of properties invalid while wrapper-mode and valid while skia-mode

[samhouts]

We've made a lot of progress on Visual in the last few months. We've love to get your feedback on it. We invite you to try the Visual Challenge and let us know if this solves any pain points for you that led you to make this proposal. Thanks! https://github.com/davidortinau/VisualChallenge

[juepiezhongren]

@samhouts visual is good, but we do need draw, we do need pixel-perfect solution

[PureWeen]

So where does this enhancement request fall when held up against visual and the drawing spec #2452

simply because current xf's controls lack two much properties for personal customization, eg. brush, controlTemplate, etc.

This is pretty easily overcome via attached properties that we are figuring out the best way to achieve over here

#5005

[weitzhandler]

@samhouts

We've made a lot of progress on Visual in the last few months.

By us, Windows and desktop are first. Visual doesn't even support UWP, won't even try it.

[samhouts]

I think we can close this now that we're making progress on #2452. Thanks!