DotNetDom: El futuro de Xamarin

Notas del editor

• #6: Now let’s talk about the future…..
• #8: We’re making progress on .NET Multi-platform App UI that we announced almost a year ago at Build 2020. It will help you deliver performant, beautiful and consistent app experiences across various platforms and devices, and allow you to share code across your mobile and desktop apps. .NET MAUI under the hood uses technologies out there today for building native apps on Windows with WinUI, Mac Catalyst for macOS, and of course, iOS and Android. .NET MAUI abstracts all those frameworks into a single framework built on .NET 6. <CLICK> That means it will allow you to build these apps for any device from a single codebase and project system. <CLICK> And that includes desktop and mobile across operating systems, Windows, macOS, iOS and Android. <CLICK> It will be part of the unified .NET in the .NET 6 timeframe <CLICK> and preview 1 dropped last week so you can go check it out!
• #11: Blazor has become a very popular way to write .NET web apps. We first supported Blazor on the server, then in the browser with WebAssembly, and now we’re extending it again, to enable you to write Blazor desktop apps in .NET 6. This enables you to create hybrid client apps, which combine web and native UI together in a native client application. It is primarily targeted at web developers that want provide rich client and offline experiences for their users. Blazor hybrid desktop apps is built on top of .NET Multi-platform App UI. It relies on that UI stack for a native application container and native controls (should you want to use them). 
• #17: maddy
• #18: maddy
• #19: maddy
• #20: maddy
• #25: In Xamarin.Forms, the Renderers are tightly couple to Xamarin.Forms components. In the ButtonRenderer, have several references to a Xamarin.Forms Button which is a bindable object implementing INotifyPropertyChanged, etc. The other topic is, the Xamarin.Forms Registrar where register the available renderers, etc. In this case, use assembly scanning and it is really slow. What happens is basically, Xamarin.Forms goes through and scans all your assemblies for assembly attributes and then automatically registers to the framework, and Allow to use that components. This is great because is easy to use, and try to remove some requirements from the user, but impact in the performance. The third topic is, in some cases is really complex to reach the native platform from cross platform code. Mainly, because the way that dependency tree works. The button renderer depends on button component so, the button has no concept of a renderer. When you are in the Button context, have no context or reference to the renderer. If you want to Access the native layer, you have different options. You can register your own custom renderer and interact with it or, use an API, that is great but very difficult to discover. I am talking about Platform Specifics. At the end, is not doing anything really special, just setting a cross platform pproperty to a native UI control property.
• #26: Relying on event handlers to orchestrate behavior and property changes Lots of boilerplate code Tons of knowledge required about order of events, both on the platform side and on the Xamarin.Forms side (i.e,, Does this need to happen on ElementChanged? What about ElementPropertyChanged? Etc.)
• #27: There are several ideas driving this, but one of the most important ones is performance minded and simplified. Achieve a much better performance and allow to understand how everything Works in a easy way. Mostly, if you are a new developer. In Xamarin.Forms is a Little bit hard to understanding how to get the renderer, the lifecycle, etc. Also, is complex as we mentioned to Access to any native element from the cross platform layer. So, what we are doing is sort of moving everything into the cross-platform side to allow you Access things within the context of your shared application. So you can see in the slides some samples, and as you can see, the idea is to allow register any handler you want. For sure, there are handlers registered by defaut, but, you can swap those in and out. The idea behind this is, we are not going to use assembly scanning by default. In next slides we will see that we will allow the use of scanning assembly for a very specific case. This is for teo reason; first one, to gain performance and second one; to simplify the registration process. Of course, the code sample from the slides, also Works with multitargeting so you can include it in cross platform code.
• #28: Now, I am going to compare the ways renderers strategy Works in Xamarin.Forms and .NET MAUI. In Xamarin.Forms, there are some huge if statements, some consistency problems, all of the methods to update any property are privates.
• #29: The .NET MAUI strategy is more function based. The idea here is that, all the update methods we have seen before, will be moved to extensión methods. Why?. Will be public methods that you will be able to apply in your own handlers. Also, is very powerful for cross-platform, because since the way everything Works is créate a standard API across all platforms, for example, the LabelExtensions, you can use it from a cross platform class, and you can say, handler, UpdateText and in every platform will use the same method with the correct implementation for the platform. So, image this, and we will see this in samples more later, but can have just one class to implement the Handler while in Xamarin.Forms we used several projects, several clases, etc. Finally, the mapper is just a dictionary of functions, so before when you saw the Xamarin.Forms property changed stuff, what was doing is just mapping string with methods. And is what the mapper is doing but standarizing that to use a structure and something much more pluggable.
• #38: All this is poising the framework to be easily to extend, and allow more customization options. Shell vNext: More customization options, more explicit API, more integrated with MVVM frameworks, etc.