Xamarin.forms: 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>

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

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

1. 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>

1. 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.

[Mike-E-angelo]

Right @yowl ... depends on the scenario, really. Simple LOB applications will work very well with Ooui's approach. Note that I say approach (WebSocket bridge) and not Ooui specifically. Ooui is quite the ways off from being a legitimate superpower.

SkiaSharp doesn't work on the web, so you would still need to have another application to run with it there. Unless you use WASM, of course. But that's a bulkier download. Everything is going HTML5/web/lightweight these days. Applications that load faster and are snappier because of it will be the ones that gain users and therefore market traction. We're seeing this with PWAs and web tech as a whole.

Native/stores are becoming passé as the web becomes more and more like them and assumes their power. And it is doing it without all that centralized/authoritative/smothering/censoring/store/registrations/guidelines BS, to boot. 😉 Technology is moving more back towards the decentralized/free way of doing business, the way it was originally designed, intended, and meant to be.

Nonetheless, I am in agreement with you that there will ultimately be two scenarios here: HTML5 for a good majority of the applications (that require accessibility/SEO 😄), and then WASM for the specialized/graphics-intensive/gaming/etc. The ideal presentation technology offering would cater to both camps seamlessly so that developers do not have to know or deal with the differences (i.e. headaches) of either/both.

[yowl]

You say SkiaSharp does not work on the web and as far as I know noone has built it for wasm, but Skia does so I imagine its possible. Or build XF with a Skia backend, comes to the same thing. The mono people have something up their sleeve I'm sure, look out for something at Build in May.

[Mike-E-angelo]

Yeah I have been waiting _years_ now for //build to show something exciting, @yowl. Even Connect(); events have been reduced to bragging about getting .NET to run on refrigerators and other appliances (very low value) rather than in a web page (extremely high value).

I am taking a more "I'll believe it when I see it" approach these days. 😉 For this year's circus, I am not expecting to hear anything significant other than Progressive Web Applications, and how MSFT has managed to "integrate" them into our ecosystem while making it as expensive as possible to work with them as .NET developers. 🎉 A little slice of optimism there for you. 🎉

[timahrentlov]

Skia + Canvas would work with http://webassembly.org. Flutter will be hitting that in a future that is "bring your own UI". This http://webassembly.org/demo/Tanks/ might as well be a Skia business app.

[juepiezhongren]

@timahrentlov skia+canvas? 10M downloaded, it is really big.

[juepiezhongren]

i just wonder, how about xamarin.flutter?

[yunusefendi52]

I agree with @juepiezhongren, the size of skia is big

[opcodewriter]

Interesting discussion. Meanwhile basic controls like ListView still have issues on iOS and Android. XAML preview is not fully working either. There's still basic controls which are not implemented yet. Performance still lags behind. It's nice to talk and dream but the state of XF is not really where it should be despite being almost 3 years old.

[timahrentlov]

Problem with XF is that it is like building a house on a gletcher. It has a gigantic UI platform footprint and cracks and crevices will form underneath.

Fixing them, and adding new features, is a constant uphill battle that will only worsen as more platforms is added. Mac OS x, OOUI/Web, Tizen, whatever. It will grind to a halt. I mean, it almost has. It is a DOA approach. And tools like flutter will run in circles around XF.

XF needs to bring it's own UI and only integrate specific platform UI where it is absolutely necessary. Like map, camera-view, etc. Sooner later Xamarin will have to implement (the open source flutter engine!) anyway, if it wants to support Fuchia or whatever it ends up being called.

[opcodewriter]

I really don't care about Flutter or Tizen or any other things. All it matters in terms of mobile development is iOS and Android. Then maybe UWP. I couldn't care less about Mac OS X and WPF, despite what people say. Trying to unify mobile and desktop when you can't even handle mobile (iOS and Android) right is sad.
Xamarin Forms is really the best example of Jack of all trades, master of none. It's an OSS project which started as a weekend project. The only significant work is on the XAML compilation.
Other than that, Xamarin is pretty much waiting for developers in the wild to continue the work. There's still no serious commitment making the framework how it should really be.
Build conference is coming and they will announce with bells and whistles how great Xamarin Forms 3.0 is. In reality, there will still be same bugs and limitations.

[juepiezhongren]

we need both native and ubi. xf is good enough, because of using all native apis with c#. ubis must be important too.

[opcodewriter]

Can someone give an example of any other project/framework/tool which has so many directions like Xamarin Forms? What I mean by "directions" is Android, iOS, UWP, Mac OS X, CSS, Flexbox, Tizen, WPF. Did I miss anything? web/HTML? Crazy...
It's almost like someone constantly says "is there anything else we can play with today"? It's like someone is constantly experimenting. There's nothing wrong with experimenting, but it's strange to talk about stuff you're working on as if it's solid, when in fact they are all experiments.

[timahrentlov]

If only XF was focused on only iOS and android..
If only MS had begun using XF for it's own apps..
If only MS had applied more resources and human testers..
If only Xamarin wasn't so hellbent on making tech-events the focus of their major releases..
if only..

It seems that for last couple of years no grown ups has been at home. Who's been behind the wheel, plotting the course? What course?

Releases has had a tech-demo quality, stable has certainly not been Stable, and stuff has been released not because it fitted into a general strategy and thus should - but because a techie got an idea and they could. And apart from generating content to keynotes, XF has not been the success we've all hoped it would be. That it should have been by now.

I'm still hoping that XF can be snatched out of the jaws of death. I'm still hoping that an adult will take the wheel. This late in the game it will need to be a herculean effort. At least if MS wish to succeed using XF's current UI paradigm.

MS could make it easier on themselves and be more like, well, flutter. _XF needs to bring it's own UI!_

Right now, the dart side sure looks seductive to me!

[opcodewriter]

Microsoft couldn't care less about Xamarin Forms... Microsoft is just using Xamarin's mobile thing to try evangelize and keep the level of .NET hype alive... Microsoft is still living in the past, in the "developers, developers, developers" hype era. Which is not bad, what's bad is that it's more hype than quality now.
Reality is most of developers are on MacBooks and do not care about Windows and .NET for a long time now. Microsoft failed on pretty much everywhere in mobile and hardware space. They struggle to keep the hype alive but it's been pretty very hard. At management level, Microsoft failed hard. Don't get me wrong, there many many really great technical people at Microsoft, I'm talking about the low-level/technical guys.

If only MS had begun using XF for it's own apps..

How could they? Performance is not where it should be.

[yowl]

Reality is most of developers are on MacBooks do you have anything to back that up?

[opcodewriter]

do you have anything to baack that up?

No, but if you look to the most popular technologies, I can assure you large majority of those devs are on MacBooks

[mhmd-azeez]

@opcodewriter what does "popular technologies" have to do with "MacBooks"? Most of the things that work on macOS also work on other Unix-based operating systems.

[opcodewriter]

@encrypt0r Yeah, ignore me. Everything's great. 👍

[juepiezhongren]

considering vs popularity，how is posible that most coders r using mac？

[Mike-E-angelo]

Kinda late to the party here, but even Xamarin is in on the web tech now:
http://www.davidortinau.com/blog/styling_xamarin_forms_with_css

Seems sort of Frankenstein to bolt CSS into Xaml-based tech, but hey. 😉 Also, the CSS used here is more of a DSL for Xamarin control styling that reads like CSS. In any case, the point being is that WHEN USED CORRECTLY 😆 it's a mature standard that can be utilized by devices everywhere.

Some additional discussion around this here:
https://twitter.com/migueldeicaza/status/972525236301238272

[juepiezhongren]

@Mike-EEE ,have u seen draw and materialShell issues?

[Mike-E-angelo]

I have not @juepiezhongren ... is this in reference to HTML or Forms?

[juepiezhongren]

@Mike-EEE
https://github.com/xamarin/Xamarin.Forms/issues/2452
https://github.com/xamarin/Xamarin.Forms/issues/2415

[juepiezhongren]

That is fabulous

[Mike-E-angelo]

Yeah not bad @juepiezhongren but not worth the time/money/effort/resources if it's not ubiquitous in the first place. :)

[MisterJimson]

Material Shell does relate to this issue, but its still styled native controls and not true ubiquitous controls.

[weitzhandler]

@juepiezhongren
I like the concept, though not the way you laid it out.

In my dreams Avalonia-like framework is the perfect option. Native look and feel is really not much of a concern to me; I would prefer the controls to be rendered the same everywhere, with an option to add native look and feel themes to each platform for those who require it.
As soon as that gets wasm support, Silverlight is back, and there will only be left to miss RIA Services 😁

[jassmith]

@MisterJimson actually the idea is that material shell inherently brings ubiquitous controls

[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
https://github.com/xamarin/Xamarin.Forms/issues/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 https://github.com/xamarin/Xamarin.Forms/issues/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

https://github.com/xamarin/Xamarin.Forms/issues/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!