Sharing Code with Xamarin

Traditionally with Xamarin applications (before Xamarin.Forms) we would build out our native user interfaces with Storyboards, XML, and XAML for each platform “head” that we wanted to develop for. The key though is that with Xamarin you have access to 100% of APIs all from C# and all of your code behind for those native views are all in C# with awesome C# features. Everything compiles down into lovely native apps that look and feel native… you guessed it because they are native. This is unlike other cross-platform frameworks that are just abstractions or some sort of webview… Xamarin apps are 100% native.

What comes next is the magic that with Xamarin you have a full .NET runtime that runs native on each platform enabling anyone to share a vast majority of the apps business logic between all of their apps and even their existing desktop and websites. This logic usually is all of the models, view models, and service logic that is just pure .NET code that is now cross-platform to nearly any platform. On average I share about 70% of code across all of my applications that I build with Xamarin and I am using super productive tools like Visual Studio and of course using the best programming language, C#.<

What about the User Interface?

The one thing that isn’t shared though is the user interface. This was a hard problem because you don’t want to lose the native part of Xamarin which makes it so unique. Other cross-platform UI frameworks just fake it and lack great performance and don’t really display the native UIs and are very messy. This is why Xamarin.Forms was designed differently. Abstract what is common into a XAML schema with a full MVVM & data binding framework built in. If you don’t know about MVVM & Databinding and why it matters listen to our latest Merge Conflict:

The difference with Xamarin.Forms is that everything that actually gets displayed are native controls for each platform. It is just this thin layer on top with a bunch of great features including Messaging Services, Dependency Services, and full navigation.

So I Should Just Use Xamarin.Forms?

Xamarin.Forms is spectacular and I have been quoted many times that 80% of all applications could be built with Xamarin.Forms especially seeing a bulk of all applications are built for the enterprise scenarios. This is where Xamarin.Forms shines and was NEVER sold as the silver bullet that everyone thought it was. If you have heard me present I have always said that my first love will always be Xamarin Native and when I am building an app that needs sub-2 second startup, access to tons of native libraries and controls such as material design, and want full control then I would always recommend Xamarin Native as you are still sharing 60-70%+ of code!

Until now developers could only pick one or the other. You had to pick Xamarin Native or Xamarin.Forms and trying to blend the worlds wasn’t the easiest to do and transitioning from a POC (proof of concept) and throw away the Xamarin.Forms user interface seemed like a waste. Or maybe you already had a Xamarin Native app and just want to share more code without having to re-write your whole app. This is where Xamarin.Forms Embedding comes in.

Xamarin.Forms Embedding Is AWESOME

Xamarin.Forms Embedding enables Xamarin Native developers to leverage Xamarin.Forms including a bunch of its great features (including data binding) to create shared user interface pages for their applications in Xamarin.Forms and embed them in their Xamarin Native apps. That is correct, you can now start replacing all of those simple screens (about, settings, details) that you had to write three times with a SINGLE XAML/Xamarin.Forms based page that is shared across all of your applications.

This is truly game changing when it comes to choosing Xamarin and Xamarin.Forms as your mobile app development platform. You can benefit from all of your performance and design of a Xamarin Native application without any overhead at all and embed those shared pages directly into your apps. You can dabble in Xamarin.Forms without the commitment. Need to develop a feature quickly? No problem because embedding will save you TONS of time. The code is so simplistic that it can now take that 60-70% up to 80-90%+ when developing a Xamarin Native app, which is simply awesome.

Embedding Everything Everywhere

To me this is really only the first step to where Embedding will go. At Build 2017 I got to help announce the Embeddinator-4000 project which enables developers to compile and embed a .NET or Xamarin.IOS/Android/Mac library into a native language library (Objective-C/Swift/Java/C++). This means that non-Xamarin developers can now create that shared code layer for their applications without having to take the leap and re-writing their full application as this usually is not an option. Now, let’s look into the future when Embeddinator is complete and Xamarin.Forms Embedding has hit stable where a mobile app developer writing an Objective-C iOS and Java Android app could adopt Xamarin into their native application and share not only business logic, but also create shareable NATIVE user interface with Xamarin.Forms Embedding. This is the story I want to tell, this is unbelievably amazing, and I can’t wait for this embedding future!

These reasons are why Xamarin.Forms embedding matters, why you should care, and why you should give it a try today. If you still don’t believe me after reading this then watch it in action:

So, what is OnPlatform? It allows you to set properties on elements or run specific code based on specific platforms. This is really nifty for tiny tweaks to UI and can be done completely in the XAML, which is awesome. To make way for furture enhancements there have been small tweaks to the XAML and code behind implementations.

First, XAML. Instead of having to support all the crazy inline options for hard coded platforms we can simply use string versions of each platform. Here is a before and after:

Easy peasy to update actually and allows for custom platforms in the future.

How about the favorite Device.OnPlatform method? Well I never really liked this method to be honest with you and apparently it wasn’t very flexible long term. So instead of passing in a bunch of Actions into a crazy method the new recommendation is to simply do a switch case over Device.RuntimePlatform! Check it out:

There you have it, quick and simple changes available now in 2.3.4 of Xamarin.Forms.

Checkout my newly updated blog on Design Time Data best practices that are updated for the most recent changes in Xamarin.Forms.

Original Post

The most annticipated announcement of Xamarin Evolve 2016 had to be the Xamarin.Forms xAML Previewer. Enabling you to see a live preview of your Xamarin.Forms XAML without having to run it on a simulator or device. Simply write some XAML and there it is running on an iOS or Android phone or simulator design surface.

Writing XAML and seeing it is fine, but what if you want to see sample data right inside of your preview? I mean doesn’t each View have a ViewModel associated with it? If so, then would’t we like to use it during design time?

Return of the ViewModelLocator!

During the keynote Nina showed off a list of Coffees where the ItemSource was bound to some design time data. I first thought about taking this approach and create a static List for my Monkeys app, but then I thought there has to be a better way. Essentially, Laurent taught us years ago how to create a static ViewModelLocator class that can be used at design time. So here is the setup, simply create a new class called ViewModellLocator.cs and create a static version of each ViewModel you wish to use (I personally put it in my App.cs):

public static class ViewModelLocator
{
    static MonkeysViewModel monkeysVM;

    public static MonkeysViewModel MonkeysViewModel =>
       monkeysVM ?? (monkeysVM = new MonkeysViewModel());
}

Note: you could pass in some additional arguments to tell your view model you are in design mode.

Design Time

Next up is to head over to your XAML file and create a new xmlns:design on your Page that refers to the assembly that you are using.

xmlns:design="clr-namespace:Monkeys;assembly=Monkeys"

Then you can set BindingContext of the page to your design time static view model:

BindingContext="{x:Static design:ViewModelLocator.MonkeysViewModel}"

See it live!

Now the rest of your Bindings will all just work, which is pretty much fantastic.

Here is a short video walking through the process:

Don’t forget that it even renders your custom renders. Awesome! Be sure to read the Evolve blog post announcing all these awesome features.

I am working out of my Xamarin.Forms-Monkeys project that I have blogged about before, which consists of a nice list of Monkeys with Images. You can browse this code on my GitHub.

Bindable Group Structure

There are a few examples of using headers with Xamarin.Forms, but I wanted to create an ultimate “Group” that would allow me to sort, organize any data, and that is when I came up with Grouping:

Grouping seems simple, but is very extensible, especially if using data binding. Notice that a Grouping is really just an ObservableCollection of type T. However, each Grouping also has a Key. Now this key is of type K, which means it could be anything including a complex data structure. This means you could in theory bind your header to a data structure of K and then bind multiple controls to multiple properties, which is very cool. For this example though we will just make K a string for sorting.

Sorting Our Monkeys

Before we get to our Monkeys we will create a new new public ObservableCollection<Grouping<string,Monkey> > MonkeysGrouped{get;set;} in our ViewModel. The reason for this is that we actually have multiple lists, which is a list of a list of grouped monkeys. Then we will add a new property to our monkey that we can use for sorting, which will be a name sort property:

And now we can sort our list of Monkeys in our view model, which we will set as the ItemsSource on our list view:

Enabling Headers

Enabling headers is very simple. There are a few properties to set on the ListView itself to get things going. First is to enable grouping, and then to set the property that the headers will bind to:

list.ItemsSource = viewModel.MonkeysGrouped;
list.IsGroupingEnabled = true;
list.GroupDisplayBinding = new Binding("Key"); //this is our key property on grouping.

Jump List

Of course, we could stop there, but what fun would that be, as we can add a jump list with just a single line of code:

list.GroupShortNameBinding = new Binding("Key");

This results in a nice jump list:

Custom Headers

Let’s take it one step further and implement our own custom header cell with a nice background color. Right now our Key, K, is only a string, but we could pass in a full data structure if we wanted to make the custom view more complex and bind to multiple pieces of information.

My HeaderCell is very simple and just contains a Label, which binds to Key and I am placing it inside of a StackLayout with a bit of custom padding and a background color. It should be noted that I am setting a fixed Height of 25 here as the Xamarin.Forms ListView needs to know what to render.

The last thing to do is to update the the ListView with this new template:

if(Device.OS != TargetPlatform.WinPhone)
  list.GroupHeaderTemplate = new DataTemplate(typeof(HeaderCell));

list.HasUnevenRows = true; //you might want to enable if using custom cells.

We don’t set it on Windows Phone because the default styling is standard on Windows Phone with accent colors. However, you can customize it here as well. Here is our outcome on all three platforms:

XAML?

As Charles Petzold would say… Show me the XAML! Of course it is just as easy, as all we need to do is bring over our updated ViewModel and Grouping and create the rest all in XAML:

Conclusion

It is extremely easy to not only customize your cells in your ListView, but also add rich functionality like list sorting with group headers with just a few lines of shared C# code with Xamarin.Forms!