Cross Platform C#

Looking Ahead to Xamarin.Forms 3.0

From performance improvements to new platforms, here’s a look at what’s coming down the road for Xamarin.Forms developers.

It's been a few years now since Xamarin.Forms was released into the world, and it continues to be a popular and evolving framework choice for Xamarin developers. Later this year Microsoft is planning to release Xamarin.Forms 3.0, its third major release of the framework, which is slated to ship with a lot of exciting features and improvements. While it certainly won't be comprehensive, as the feature set is large and still in motion, in this article I'll walk through some of the highlights of what's coming later this year for Xamarin.Forms developers.

Performance
If you ask developers what types of improvements they want to see from their framework of choice -- whatever that might be -- performance is undoubtedly going to rank high on their lists. Xamarin.Forms is no exception to this, and Microsoft has been spending a lot of time working on a variety of performance enhancements.

One of the main initiatives is a feature called "fast renderers." In Xamarin.Forms, controls go through components called renderers when they need to be translated into the native view system of the target platform. As you can likely deduce from the feature's name, fast renderers are an effort to improve the performance of that rendering pipeline on different platforms. Microsoft is going through these renderers one by one, starting with Android, and making improvements to simplify the rendered views, because by flattening out view hierarchies on any platform you’ll see notable performance and memory improvements for an application. As more renderers get addressed during this initiative, Xamarin.Forms developers should see real performance improvements in applications without having to change a thing.

Fast renderers are certainly a headliner of the performance category, but there are other improvements coming, as well. Microsoft is introducing a new one-time binding mode for cases where you don't need to take on the overhead of keeping live bindings around after the initial binding. Improvements are coming to the compiler pipeline for views, as well, to help compress layouts during compilation to reduce memory usage and improve rendering times.

There are a lot of welcome performance enhancements coming to Xamarin.Forms 3.0, and most of them will come for free without having to make any changes to your applications. What more could you ask for?

New Platforms
One thing you might have asked for is the ability to extend your apps into more platforms. Xamarin.Forms already lets you ship your apps to iOS, Android and Universal Windows Platform (UWP), but now Microsoft is extending your reach much, much further. Four new platforms are coming to Xamarin.Forms:

  • macOS
  • Linux
  • Windows Presentation Foundation (WPF)
  • Tizen

Linux support is being built on top of the GTK# framework, and macOS builds on Xamarin.Mac. You can already target Windows using the Xamarin.Forms UWP support, but soon you’ll be able to build classic WPF apps if you'd prefer. By bringing Tizen into the mix, you can extend your Forms apps to millions of Samsung devices, as well, such as TVs, wearables and more.

Embedding
The last thing I want to talk about is the one I'm personally most excited about. Historically you could always call out to native platform features from a Xamarin.Forms app, but the other direction wasn't quite as feasible. What if you had a classic Xamarin.iOS or Xamarin.Android app and wanted to just use Forms for one or two screens where it made sense? There wasn't a good story for this ... until now.

Starting in Xamarin.Forms 3.0, Microsoft is introducing a new embedding feature so you can reference and use Xamarin.Forms controls and features outside of an actual Xamarin.Forms application. In addition to just getting basic layout support, you also get to bring over features like data binding, MessagingCenter and DependencyService. Use of NavigationService isn’t supported, because you’d be using the native platforms to handle things such as navigation, but the rest are available to leverage in native applications.

Let's look at how simple it is to embed Forms content in native applications on a few platforms. First, I'll create a simple ContentPage in a shared Xamarin.Forms Portable Class Library (PCL) (see Listing 1).

Listing 1: Creating a Simple 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="VSMEmbedding.Forms.ArticlesPage">

    <ContentPage.Content>
      <StackLayout>

        <Image
          Source="https://i-msdn.sec.s-msft.com/dynimg/IC854146.png"
          HorizontalOptions="FillAndExpand"
          BackgroundColor="White" />

      </StackLayout>
    </ContentPage.Content>
  </ContentPage>

This is quite simple, and no codebehind is needed (though it would still work if it were!). This is a page named ArticlesPage that for now simply displays a Visual Studio logo.

Android: Before expanding this, let's add it to a native Xamarin.Android app. The app needs to reference the Xamarin.Forms NuGet package, as well as the shared class library containing ArticlesPage. In the app's main activity, first initialize Xamarin.Forms by calling:

Forms.Init(this, null);

That's all you need to do to start using Forms features in your app! Let's go ahead and create an ArticlesPage:

Fragment articlesFragment = new ArticlesPage().CreateFragment(this);

You can see here that an instance of ArticlesPage is created the same way you normally would in a Xamarin.Forms app, and then the CreateFragment extension method is simply called to get a standard Android Fragment object for it. Once you have the fragment you can use it just like you would any other fragment:

FragmentManager
  .BeginTransaction()
  .Replace(Resource.Id.FragmentFrame, articlesFragment, "articles")
  .Commit();

It's that simple! You can see this in action in Figure 1.

[Click on image for larger view.] Figure 1. A Basic Xamarin.Forms Page Rendering in a Native Android App

iOS: Doing the same thing in iOS is just as easy. For example, in AppDelegate you can create a view controller from the page and assign that as the window's root view controller:

Forms.Init();

UIViewController articlesController = new ArticlesPage().CreateViewController();

_window.RootViewController = articlesController;

UWP: As you might expect, it's effectively the same thing for UWP, as well:

FrameworkElement articlesElement = new ArticlesPage().CreateFrameworkElement();

Easy!
Binding: Displaying an image across three platforms is great and all, but let's add in some data binding. Also, just to prove that the binding system does actually work, the data that will be bound will be passed in from the Android app, instead of just being kept entirely in the shared code layer.

First, I'll add a new class named article to hold information about articles in this column:

public class Article
{
  public string Title { get; set; }
  public string Author { get; set; }
}

Next, I'll update the XAML for ArticlesPage to display a list of articles below the logo, as shown in Listing 2.

Listing 2: XAML for Displaying a List of Articles
<?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="VSMEmbedding.Forms.ArticlesPage">

    <ContentPage.Content>
      <StackLayout>

        <Image
          Source="https://i-msdn.sec.s-msft.com/dynimg/IC854146.png"
          HorizontalOptions="FillAndExpand"
          BackgroundColor="White" />

        <ListView ItemsSource="{Binding .}" >
          <ListView.ItemTemplate>
            <DataTemplate>
              <TextCell
                Text="{Binding Title}"
                Detail="{Binding Author}" />
            </DataTemplate>
          </ListView.ItemTemplate>
        </ListView>

      </StackLayout>
    </ContentPage.Content>
  </ContentPage>

There’s still no need for codebehind here, as the binding will take care of everything. Next, I'll need some sample data, so I'll add the code shown in Listing 3 to the Android app.

Listing 3: Sample Article Data
var articles = new List<Article>
{
  new Article 
  {
    Title = "Track Your Fitness with a Fitbit and Xamarin",
    Author = "Wallace McClure"
  },
  new Article
  {
    Title = "Visual Studio Mobile Center: A Better Way To Build Mobile Apps",
    Author = "Greg Shackles"
  },
  new Article
  {
    Title = "Xamarin.Forms -- Caching for the ListView",
    Author = "Wallace McClure"
  },
  new Article
  {
    Title = "Getting Device-Specific When Customizing a Xamarin Forms App",
    Author = "Wallace McClure"
  },
  new Article
  {
    Title = "You, Too, Can Build Xamarin Apps with F#",
    Author = "Greg Shackles"
  }
};

Finally, all that's needed is to assign this list to the page's BindingContext property to trigger the binding:

Fragment articlesFragment =
  new ArticlesPage
  {
    BindingContext = articles
  }.CreateFragment(this);

With that in place, running the app should look like Figure 2. I could take advantage of Xamarin.Forms for layout and binding, with the data source being constructed from the Android app itself and simply passed in. This embedding support is going to open a lot of exciting possibilities for mixing and matching Xamarin.Forms and native apps, allowing developers to be able to choose the right tool for the job at a per-screen level in an app, instead of having to make that decision at the app level.

[Click on image for larger view.] Figure 2. A Xamarin.Forms Page Rendering with Data Binding in an Android App

Wrapping Up
These are just a few of the highlights from what's coming in Xamarin.Forms 3.0, but it's safe to say the framework is still evolving quickly and becoming an increasingly powerful choice for developers. Between the performance improvements, extending the target reach to a host of new major platforms, and an increased ability to mix and match Xamarin.Forms with native applications wherever it makes sense, it's a good time to be a Xamarin developer.

About the Author

Greg Shackles, Microsoft MVP, Xamarin MVP, is a Principal Engineer at Olo. He hosts the Gone Mobile podcast, organizes the NYC Mobile .NET Developers Group, and wrote Mobile Development with C# (O'Reilly). Greg is obsessed with heavy metal, baseball, and craft beer (he’s an aspiring home brewer). Contact him at Twitter @gshackles.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube