At the Microsoft Build conference this year, Xamarin presented the next iteration of Xamarin.Forms v3. In this article, I will show you a few cool features that they announced and what you can expect of this new version.
What is Xamarin.Forms?
Before we dive right in and show you what to expect from the latest Xamarin.Forms release, let me first tell you a little bit about what Xamarin.Forms is exactly.
Are you keeping up with new developer technologies? Advance your IT career with our Free Developer magazines covering Xamarin, C#, Patterns, .NET Core, MVC, Azure and more. Subscribe to the DotNetCurry (DNC) Magazine for FREE and download all previous, current and upcoming editions.
If you have worked with, or looked up Xamarin before, you’ll probably know by now that it is a great solution to create multi-platform apps based on C# and .NET. You can use it to share all of your business logic throughout all of your apps across Android, iOS, UWP and even across a lot more platforms these days like the Raspberry Pi, Apple TV, etc.
While this is great in itself, Xamarin took it a step further and added the missing link.
With ‘traditional Xamarin’, as they now call it, you can do everything I have mentioned before, but you will still have to put in efforts in the user interface (UI) for each platform.
And that is just fine!
You can leverage the powerful tools that are already available for the respective platform to create a UI that integrates seemingly with the OS that you are targeting. On May 28th of 2014, Xamarin introduced Xamarin.Forms as part of Xamarin version 3.
With Forms, Xamarin then enabled developers to also share the UI code across all platforms.
An abstraction layer was introduced with which an Entry or Label could be defined. Then, with the power of Xamarin.Forms, it would be translated to the native equivalent on the platform that the app is running on at that time.
For instance, this would be a UITextView for iOS, a EditText for Android and a TextBox on Windows in the case of an Entry. To define this shared UI code, you can either use XAML – a XML-based language to define user interfaces – but you can also define the UI in C# code.
In the fall of 2017, Xamarin Forms is coming up with its next milestone version : Xamarin.Forms 3.
Note: The versioning of Xamarin and Xamarin.Forms are not aligned. Ahead of this release, I will walk you through some of the key features that they have already announced, and are even available for you today!
Coming to you in Xamarin.Forms 3
Besides a whole lot of bugfixes and improvements, these are some cool features that you want to look for in the new version of Forms.
Since half-way 2016, there is already a thing called ‘native embedding’ in Xamarin.Forms.
With this feature, you can embed native controls that do not have a Forms abstract counterpart (yet). Some good examples of this are the UISegmentedControl on iOS and the Floating Action Button (FAB) on Android.
These controls are so specific and characteristic to their respective platforms, that they are unlikely to get an abstraction, so you can use it across platforms. With native embedding, the Xamarin team has done a great job in finding a way to add these controls to that specific platform, but in a generic way.
You can read more on this here: https://blog.xamarin.com/embedding-native-controls-into-xamarin-forms/.
Xamarin.Forms Embedding, is just the other way around.
With this method, you can embed Xamarin.Forms controls, pages and all other elements into your traditional Xamarin app, with traditional Xamarin being an app written in C# but using the native UI elements. This enables you to gradually transition from your old Xamarin app, into a new one and with an even more code-sharing Xamarin.Forms app.
Not really a part of the new Forms version, but still nice to mention in this context is the Embeddinator-4000. This application allows you to convert a .NET library into an Objective-C and/or Java one. This way, you can even start converting your existing native apps to Xamarin in phases.
More platforms are supported
Xamarin already enables you to develop C# code for a wide variety of platforms. Most obvious are the phone and tablet platforms: Android, iOS and Windows.
But did you know you could also run your code on a PlayStation 4, Xbox, Google Glass, Amazon Kindle, Linux, etc?
Here yet again, watch out that it does not mean that whenever Xamarin runs somewhere, Xamarin.Forms is supported as well. The platforms that are supported in Forms would be: Android, iOS, Windows Phone and UWP. Most recently Mac OS was added, the desktop OS by Apple.
And now, support for some new platforms are coming up!
The team is working hard to support GTK#, a .NET wrapper for GTK+, the UI toolkit mainly used on Linux system. This means that you can also easily design forms for a wide variety of Linux distributions in the near future. And WPF will be a supported platform as well, I will talk about that a little bit later on in the XAML Standard section.
Enhancements and more speed
The new major release of Forms will mostly be about stability and improvement. This means that they have gone back to the drawing board with the current version and took a long and good look on where improvements could be made.
When we take a closer look at the inner workings of Xamarin.Forms, we will find an important role furnished in the so-called ‘renderers’.
It is the responsibility of the Forms libraries to translate – or better yet, render the elements that you define in an abstract manner, to their native counterpart. Have a look at the figure 1 to see how that works.
Figure 1: Overview of how a renderer does its work. Image courtesy by Xamarin.
Because this is a large part of the Xamarin.Forms solution, you can imagine that optimizing this process can make a tremendous difference. The next generation of renderers that they are implementing now are called fast renderers.
The renderers discussed above, mostly do their work at runtime. Whenever a page is requested, it will take that page and go through the whole visual tree and start rendering all the controls that are on it. This is time consuming and also reflects on the memory usage.
In the version of Forms that is to be released, layout compression will be available. When enabled, the layouts will be optimized at compile time and thus improve performance at run time.
New binding type
One of the Xamarin Forms pillars, is data-binding.
This supports the use of architectural patterns like the MVVM pattern. In short, you do not need to reference actual controls by their name to give them a specific value. Instead, you turn it around; you tell the control from which property it needs to take the value, in your code-behind.
This way, your code is more decoupled because you do not have to refactor your code when a new UI is developed. Just make sure the new UI also references the right properties in your code and you are good to go.
Data-binding can have a great impact on your performance. There are a few different data-binding modes.
You can supply the value to the control, which is one-way. But you could also require the control to update the value in your code, so the value goes both ways and is therefore known as two-way and there some other, less significant ones.
Every time a value needs to be updated, depending on the mode, a few cycles through your code are fired off. This means, when you have a page with a number of data-bound controls, performance could go down.
To make it more performant, Xamarin is now introducing a new data-binding mode: one-time binding.
Note: Do not confuse this with the one-way binding mode. The one-time binding mode, as you could imagine from the name, just ingests the value of the property it is bound to once, the first time the binding is being set up. After that, the binding is not being evaluated anymore.
If you have some affinity with web development, you might know (and love) the FlexLayout (or Flexbox, more information: https://css-tricks.com/snippets/css/a-guide-to-flexbox/) system. This system is being translated into a Xamarin.Forms version and incorporated in this new version they are releasing.
For those who aren’t very familiar with web development; the Flexbox layout system provides for a way to efficiently lay out, distribute and align space amongst items in a container. This also works for elements with an unknown size, hence the word ‘flex’.
There is not much known right now on how Xamarin wants to implement this, but looking at the Flex system in web applications, we might see more out-of-the-box responsiveness and automatic calculations of UI elements.
Improved styling options
Together with the FlexLayout system, they are also expanding the Forms styling options.
And again, if you are a web developer in disguise, you will love this! CSS has proven to be an easy-to-learn, yet powerful way of styling user interfaces. And now, the team at Xamarin is actually implementing more CSS-like styling options into Xamarin.Forms.
Although there is no actual detail available yet, it is a much-heard request from the community. And as a big fan of everything that is simple, but effective, I can’t wait to see what they have in store for us with this.
One of the first critical notes that was heard after the release of Xamarin.Forms, was the incompatibility with the WPF XAML.
Although most of it has the same syntax, the XAML definition used in Forms deviates in some areas from the syntax used in WPF . For example, in WPF there is a layout element which is called a StackPanel. In Xamarin they named it a StackLayout.
Initially, I presume, this was done for two reasons. One, the naming of the WPF components did not always sound logical for the use on mobile. Secondly, the team at Xamarin wanted to prevent developers from just copy and pasting their (desktop) WPF layout to a Xamarin app without rethinking the layout.
If developers would be able to copy layouts from their existing apps, there probably would have been a lot of unusable apps out there right now. Because the design paradigms for desktop applications just aren’t suitable for mobile.
To overcome the confusion of the different XAML dialects, Microsoft has announced XAML Standard.
With XAML Standard, a unified language will be developed and you will be able to exchange layouts between Windows 10 and Xamarin Forms and whichever platforms that will support XAML Standard in the future.
Besides the way you define your controls, nothing will change. XAML will still be the way to define your UI in an abstract matter and the controls will still be rendered to their native counterpart.
Looking at the draft of XAML Standard version 1, which can be found here: https://github.com/Microsoft/xaml-standard/blob/staging/docs/v1draft.md, it looks like the naming will go back to the WPF/Windows 10 dialect. As a Forms developer, that will take some getting used to.
Figure 2: A sample of XAML Standard based on the first draft. Image courtesy by Microsoft.
Work with these hot bits, today!
If you do not want to wait for the official release, you can already take a look at some parts, right now. If you want to join in, or have a look at the discussion on XAML Standard, you can visit this link: https://aka.ms/xamlstandard.
Or if you want to have a look at the Xamarin.Forms Embedding, you can follow these steps:
You should be able to restore the NuGet package needed, Xamarin.Forms 126.96.36.199-embeddingpreview, to the project.
The rest of the features are still being worked on internally and are not yet out. But of course, Forms is open-source these days, so you should be able to see some of the work on the repository: https://github.com/xamarin/Xamarin.Forms/
Xamarin.Forms vNext - Final thoughts
This is just a handful of features and improvements that are coming to Xamarin.Forms.
To read up on everything that is planned, take a look at the roadmap, which is on the Forums, here: https://forums.xamarin.com/discussion/85747/xamarin-forms-feature-roadmap/p1.
Most notable is that ‘only’ two new controls are planned and the rest is targeting performance and stability mainly. But still, things like packaging Forms into one single DLL, implementing a Visual State Manager, supporting .NET Standard 2.0, adding G18n support and much more are on the list as well. There will be enough new awesome stuff to work with.
All these goodies are planned for the third quarter of 2017, which has probably arrived by the time you are reading this. But of course some of the features could have been pushed back and might be available to use later.
I hope that you are as enthusiastic as I am about this next step in the evolution of Xamarin.Forms, and will create even more awesome apps with these goodies. If you have any questions or comments, or you want to show off your Xamarin app, please do not hesitate to contact me.
Thanks to Yacoub Massad for reviewing this article