Turning Events into Commands

Have you ever used some control in Xamarin.Forms that appears to have an event instead of a command? You are working the MVVM love and then you come across that annoying control. Almost all the Xamarin.Forms controls have both events and commands, enabling choice, but you do get those non-conforming ones…

I was lurking on the Xamarin forums and I came across a question regarding the event-only design of the SkiaSharp SKCanvasView. The SKCanvasView has a PaintSurface event that allows you to draw on the view with SkiaSharp commands.

There is nothing wrong with the event as it stands, but things get messy when all the data is in a view model. In simple cases, this is easy to resolve. Take a small example where there is only one view model, which is the binding context for an entire Page:

public partial class MainPage : ContentPage
    public MainPage()

        BindingContext = new MainViewModel();

And the view model looks like this:

public class MainViewModel
    public MainViewModel()
        PaintCommand = new Command<SKPaintSurfaceEventArgs>(OnPainting);

    public ICommand PaintCommand { get; private set; }

    private void OnPainting(SKPaintSurfaceEventArgs e)
        // ... draw ...

Where, or rather how, does one get an event somewhere on the page to the view model? Well, one way would be to attach a handler to the view and then pass the event arguments to the view model:

canvasView.PaintSurface += (sender, e) =>
    // we can do this because of our simple example
    var viewModel = (MainViewModel)BindingContext;

    // fire the command
    if (viewModel.PaintCommand.CanExecute(e))

This will work as everything is pretty much straight-forward. However, what happens if the canvas is in a ListView or if there are several canvases on the page? We would end up with a messy code-behind and probably a few memory leaks.

A much better way to solve this problem would be to use Xamarin.Forms’ behaviors:

Behaviors lets you add functionality to user interface controls without having to subclass them. Behaviors are written in code and added to controls in XAML or code.

Behaviors are easy to create and easy to use. The first thing we need to do is create our specific behavior:

public class PaintSurfaceCommandBehavior : Behavior<SKCanvasView>
    // we need a bindable property for the command
    public static readonly BindableProperty CommandProperty =

    // the command property
    public ICommand Command
        get { return (ICommand)GetValue(CommandProperty); }
        set { SetValue(CommandProperty, value); }

    // invoked immediately after the behavior is attached to a control
    protected override void OnAttachedTo(SKCanvasView bindable)

        // we want to be notified when the view's context changes
        bindable.BindingContextChanged += OnBindingContextChanged;
        // we are interested in the paint event
        bindable.PaintSurface += OnPaintSurface;

    // invoked when the behavior is removed from the control
    protected override void OnDetachingFrom(SKCanvasView bindable)

        // unsubscribe from all events
        bindable.BindingContextChanged -= OnBindingContextChanged;
        bindable.PaintSurface -= OnPaintSurface;

    // the view's context changed
    private void OnBindingContextChanged(object sender, EventArgs e)
        // update the behavior's context to match the view
        BindingContext = ((BindableObject)sender).BindingContext;

    // the canvas needs to be painted
    private void OnPaintSurface(object sender, SKPaintSurfaceEventArgs e)
        // first check if the command can/should be fired
        if (Command?.CanExecute(e) == true)
            // fire the command

Now that we have the behavior, we can simply add it to the canvas view:

        <local:PaintSurfaceCommandBehavior Command="{Binding PaintCommand}" />

That’s it! Our canvas is now command-based and can be drawn on from the view model.

This is just a very limited behavior, for one specific event for one specific view. But, behaviors are very powerful and can be used to do many more things. One such use is to make a more generic behavior that can map any event to any command:

Besides those examples, be sure to read more about behaviors, and what they can do, in the Xamarin documentation.

Evolution of the NuGet PackageReference

NuGet is probably the best thing that happened to .NET dependencies. Before this great time, we all had to copy or worse, commit a bunch of assemblies into source control – just so we could build our projects. And for library developers… well, we had to find someone to host our libraries.

When NuGet was born, we could just throw our libraries up on nuget.org and be done with it. We could tweet about it and then anyone could open the package manager and click install. The repository stayed binary-free and the library started growing in users. Great for everyone.

Both NuGet and MSBuild have evolved much over time, and there have been a few different incarnations of the simple, but complex, feature of including a NuGet package into the project file. It took a few tries, but we are at the best so far with PackageReference. But, before we get there, let us recap some of the past ideas…


There was a downside to the first NuGet: it scratched around in your .csproj and added a few elements that sometimes got mixed up. Let’s take a simple project, and add SkiaSharp:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Reference Include="SkiaSharp">
    <None Include="packages.config" />
  <Import Project="..\packages\SkiaSharp.1.58.1\build\net45\SkiaSharp.targets" Condition="Exists('..\packages\SkiaSharp.1.58.1\build\net45\SkiaSharp.targets')" />
  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    <Error Condition="!Exists('..\packages\SkiaSharp.1.58.1\build\net45\SkiaSharp.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\SkiaSharp.1.58.1\build\net45\SkiaSharp.targets'))" />

Our beautiful project file just got a bit mutilated… Still, it is not that bad, right? Well, what happens if you use a few packages? You get a project file that has quite a few elements that basically pull in a bunch of assemblies and add a few targets – there is just clutter.

Although this is all correct MSBuild file, the packages are really managed by that packages.config file. The IDE and NuGet use that file to track the installed packages and also to update the project file with the assembly references and target imports.

You can read more about the packages.config file here.


Along came a spider (named .NET Core) and sat down besIDE her…

The guys working on .NET Core also had had enough of this, (they may have gone a bit too far and removed all XML) so they came up with project.json. Although they threw the .csproj right out of the window, they had a cool idea when it came to NuGet packages: don’t touch the project file.

Initially, project.json was just for ASP.NET Core apps, but they also used it for (and still do) UWP apps. Then, they decided to let other project types use it. If we were to install the SkiaSharp package into a project.json file, we would end up with something like this:

  "dependencies": {
    "SkiaSharp": "1.58.1"
  "frameworks": {
    "net46": { }
  "runtimes": {
    "win": { }

This WAS way neater than the big, clunky .csproj, and – best of all – NuGet managed itself. No need for assembly references and importing .targets. Also, because NuGet never touched the .csproj, it could never get it wrong.

The downside to project.json was simply the fact that it was no longer MSBuild. There were other project types, such as .xproj that would pull in the project.json and then make it work with MSBuild, but now we have even more files and overhead. The problem of less was undone by the new file type.

You can read more about the project.json file here.


So, the experts got together and decided to come up with a plan – a format to rule them all. They took the idea that NuGet needs to be MSBuild and that it must not touch what it shouldn’t. It needs to be minimal, but still powerful.

This is what they came up with:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PackageReference Include="SkiaSharp" Version="1.58.1" />

No, your browser is not still loading. That simple, single line does it all. There is no additional packages.config or project.json file. That goes directly in the .csproj like any .NET framework reference (such as when including System.IO.Compression).

I could write a big puff piece about how awesome this is, but the whole point is to not have that puff. I really love this new format, and I hope that you will too. I have tested this with many projects, including Xamarin projects. It all works, and it should – it is part of MSBuild, and Xamarin uses MSBuild. This is one of the cool features about having a MSBuild-based project: if MSBuild supports it, then so does your project.

You can read more about the PackageReference format here. And, there is some more information about using PackageReference in any project type here.


Using this new PackageReference format makes life so much easier, but there are some things that you will need before you switch over all those projects:

  • MSBuild v15
  • NuGet v4.x

If you want to use an IDE, the best still are:

  • Visual Studio 2017
  • Visual Studio for Mac v7.1

The current set of requirements is just that you need to be using MSBuild v15 (comes with Visual Studio) and NuGet v4.x (also comes with Visual Studio). If you need the NuGet command line tool, you can get it here.

By default, Visual Studio will use the packages.json format, but you can change this in the options. Navigate to “Tools” > “Options…”, then “NuGet Package Manager” > “General”:

NuGet Package Manager

See more information about using PackageReference in any project type here.


Right now this magic works on Windows and macOS without anything special. Linux is a bit different… As it has a case-sensitive file system, and NuGet is a little inconsiderate: it downloads the packages as lowercase, but then tries to include the real case.

If you look at the ~/.nuget/packages directory, you will see a skiasharp directory, but when you try and compile, you will get this error:

error : The package SkiaSharp with version 1.58.1 could not be found in /home/matthew/.nuget/packages/. Run a NuGet package restore to download the package.

Exciting stuff! But no worries, until NuGet/MSBuild fixes this, we can just tell Mono to ignore case sensitivity using the MONO_IOMAP environment variable:

> export MONO_IOMAP=all
> msbuild


> MONO_IOMAP=all msbuild

That was mostly painless. Still, we can set that environment variable per build and not affect any other apps. And, this is just a tiny bit of “work” so that we can get really awesome, clean .csproj files.

So, is there anything stopping you from using the PackageReference in your projects? No! Transition Now!

Multi-Select ListView

I was just hanging around in the IDE this week and I had a chat with ListView. He was a very nice guy, but he was complaining about the fact that for some reason he could only ever select one item at a time…

I think of myself as a somewhat decent coder, and I decided to solve this problem – at least some part of it.

The easiest, and quickest, way to add multi-select capabilities to a ListView requires two steps: the “selectable” item and the “select” action.

The Selectable Item

I started with the model:

public class SelectableItem
    public object Data { get; set; }
    public bool IsSelected { get; set; }

But, since we are doing data binding, I created a bindable object that has several bindable properties:

public class SelectableItem : BindableObject
    public static readonly BindableProperty DataProperty =

    public static readonly BindableProperty IsSelectedProperty =

    public SelectableItem(object data)
        Data = data;
        IsSelected = false;

    public SelectableItem(object data, bool isSelected)
        Data = data;
        IsSelected = isSelected;

    public object Data
        get { return (object)GetValue(DataProperty); }
        set { SetValue(DataProperty, value); }

    public bool IsSelected
        get { return (bool)GetValue(IsSelectedProperty); }
        set { SetValue(IsSelectedProperty, value); }

You may have noticed that I didn’t create a generic type. This is because later on we are going to want to get the value of the IsSelected property from the ItemSelected event handler, and we won’t know what the type is. However, we can create a generic type that inherits from this base type:

public class SelectableItem<T> : SelectableItem
    public SelectableItem(T data)
        : base(data)

    public SelectableItem(T data, bool isSelected)
        : base(data, isSelected)

    // this is safe as we are just returning the base value
    public new T Data
        get { return (T)base.Data; }
        set { base.Data = value; }

We now have a nice generic type for the developer (us) and a non-generic type for the event (the machine).

The Selectable ListView

The next step is to hook up the ListView with the selectable items. So, we will need a data field on the view model or the Page – depending on how you work (note the generic SelectableItem):

public partial class MainPage : ContentPage
    public MainPage()

        Items = new ObservableCollection<SelectableItem<string>>();

        BindingContext = this;

    public ObservableCollection<SelectableItem<string>> Items { get; }

And, we need a list item that has a “checked” state (here it is just a red block):

<ListView ItemsSource="{Binding Items}">
                <StackLayout Orientation="Horizontal">
                    <!-- the "check" mark -->
                    <BoxView IsVisible="{Binding IsSelected}" 
                             WidthRequest="12" HeightRequest="12"
                             Color="Red" />
                    <!-- the text/data -->
                    <Label Text="{Binding Data}" />

We should now have a list of items that can show either a selected or unselected state. To handle when an item is selected by the user, we just need an event on the list:

<ListView ... ItemSelected="OnItemSelected">

And then we write the code to toggle the selection (note the non-generic SelectableItem):

private void OnItemSelected(object sender, SelectedItemChangedEventArgs e)
    var item = e.SelectedItem as SelectableItem;
    if (item != null)
        // toggle the selection property
        item.IsSelected = !item.IsSelected;

    // deselect the item
    ((ListView)sender).SelectedItem = null;

This is all we need, and we will have a ListView that that can support multiple items being selected.


We could call it a day, but we are not going to. The day has just started, and we are thinking that we might want to use this in multiple places. We can just copy the logic – mainly the event and cell view, but there are better ways (and we don’t like duplicate code).

Attached Property

The first thing that we will look at is if we can magically do the event hookup with a single property instead of the event:

<ListView ... local:MultiSelectListView.IsMultiSelect="True">

That looks nicer than the event, and we have a couple of benefits: no code in the page, the event code is written once and the property is bindable.

What we are doing here is using an attached property to “inject” a bindable property into an existing view type:

public static class MultiSelectListView
    public static readonly BindableProperty IsMultiSelectProperty =
            propertyChanged: OnIsMultiSelectChanged);

    public static bool GetIsMultiSelect(BindableObject view)
        => (bool)view.GetValue(IsMultiSelectProperty);

    public static void SetIsMultiSelect(BindableObject view, bool value)
        => view.SetValue(IsMultiSelectProperty, value);

    private static void OnIsMultiSelectChanged(
        BindableObject bindable, object oldValue, object newValue)
        var listView = bindable as ListView;
        if (listView != null)
            // always remove event
            listView.ItemSelected -= OnItemSelected;

            // add the event if true
            if (true.Equals(newValue))
                listView.ItemSelected += OnItemSelected;

    private static void OnItemSelected(
        object sender, SelectedItemChangedEventArgs e)
        var item = e.SelectedItem as SelectableItem;
        if (item != null)
            // toggle the selection property
            item.IsSelected = !item.IsSelected;

        // deselect the item
        ((ListView)sender).SelectedItem = null;

We now have a super easy way to turn any list into a multi-select list with a single property.

The ItemsSource

Another area we can improve is the ItemsSource collection. Right now we have quite a long type with two generic types:

public ObservableCollection<SelectableItem<string>> Items { get; }

We can not only make this shorter, but more convenient by creating a new type that derives from ObservableCollection. And, now that we have a new type, we can add additional methods so that we don’t even have to deal with the SelectableItem type at all:

public class SelectableObservableCollection<T> : ObservableCollection<SelectableItem<T>>

    // a constructor overload
    public SelectableObservableCollection(IEnumerable<T> collection)
        : base(collection.Select(c => new SelectableItem<T>(c)))


    // a convenience property
    public IEnumerable<T> SelectedItems
        => this.Where(i => i.IsSelected).Select(i => i.Data);


    // a method overload
    public void Add(T item)
        Add(new SelectableItem<T>(item));

When we use this new type, we can do some cool things:

// a nice type
public SelectableObservableCollection<string> Items { get; }

// cool methods and properties
private void OnDoSomething()
    Debug.WriteLine("You have selected:");

    // use a property
    foreach (var selected in Items.SelectedItems)
        Debug.WriteLine($" - {selected.Data}");

    // use a method
    Items.Add("A New String");

The Cell

Finally, as you may have a really cool check mark for selected items (unlike our red block now), we will want to be able to create a custom cell type that will allow us to just specify the item contents, and automatically handle the check mark:

<ListView ItemsSource="{Binding Items}"
                <Label Text="{Binding}" />

This requires a new Cell type:

public class SelectableViewCell : ViewCell
    public SelectableViewCell();

    public View CheckView { get; set; }

    public View DataView { get; set; }

I have left the implementation of this cell to your imagination… just kidding, I have it all in my my repository. You can find all this code, a sample app and more there too:

I hope you enjoyed this short(ish) post and are able to make your list views handle the selection of multiple items.

Embedding Xamarin.Forms in Native Apps

Xamarin.Forms is really cool! It allows you to almost write your app once and then compile for many platforms. With Xamarin.Forms, you can quickly produce multiple apps, but, you can also take advantage of some awesome features – such as cross-platform UIs in XAML, data binding, sharing code and much more.

Xamarin.iOS, Xamarin.Android and UWP are also fantastic! You can get 100% of the platform APIs and you can produce apps that are super fast and polished.

Most of the time you have to choose between one or the other. Sure, you can do custom renderers or effects in Xamarin.Forms to get more platform API access. And sure, you can use frameworks that help you share code with native Xamarin and Windows apps. Before today, you had one of two choices:

  • Xamarin.Forms for 100% shared code and UI
  • Xamarin/Windows Native for polished, platform-specific APIs and UIs

But… why not have both? Recently Xamarin/Microsoft shared on the blog that Xamarin.Forms can be embedded into native apps. This means that you can take your existing (or new) native app and just drop in a Xamarin.Forms page without doing anything special. You lose nothing, and gain a whole lot more. You can still use XAML, data binding, converters, effects and everything else that comes with Xamarin.Forms – but now from within you native app code and UI.

I have a nice sample app that you can pull from GitHub. Be sure to check it out and let me know what you think of this new functionality. I will try and keep that repository up to date with any new developments.

Xamarin.Forms embedded in native apps

Getting the Bits

To embed Xamarin.Forms into your native app, you just need to install a preview NuGet from the Xamarin.Forms pre-release feed:


Then, you want to install the NuGet into any Xamarin.Forms projects as well as into the native app projects.

That is it! Now you should be able to create your shared page.

If you have any questions or comments you can do this using the Xamarin discussion (Preview: Xamarin.Forms Embedding) on the forums.

It is important to note that this is a pre-release and functionality may change with subsequent releases.

Creating Shared Pages

Let’s take an example of an existing app that you want to add the ability to register and/or login to save user preferences on some cloud service – such as Azure. Your app is out and in the wild, users are loving it, and, you have just received feedback that they want to login across devices and keep their preferences.

What do you do? Well you could create a few screens for each platform and then share some code. But, as all the login screens are going to look the same and work the same, why not do everything in shared XAML?

So, the first thing we can do is to either create a shared project, a .NET Standard library or even a PCL. We then just need to install the pre-release Xamarin.Forms NuGet. Finally, we can go ahead an add a new XAML page. Just right-click and do “Add” > “New Item…” > “Content Page (XAML)” and then you have a new page.

In this page below, I am using data binding, converters, resource dictionaries and good old XAML markup:

<?xml version="1.0" encoding="utf-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
            <app:NegateConverter x:Key="Negate" />
            <app:NullInvisibilityConverter x:Key="NullInvisibility" />
                <RowDefinition Height="*" />
                <RowDefinition Height="Auto" />
                <RowDefinition Height="*" />
            <StackLayout Spacing="12" Grid.Row="1">
                    <OnPlatform x:TypeArguments="Thickness" 
                                Android="24" iOS="24" WinPhone="0" />
                <Label Text="Enter any username/password:"
                       FontSize="12" />
                <Entry Keyboard="Email" 
                       Placeholder="username or email"
                       Text="{Binding UserName}" 
                       IsEnabled="{Binding IsBusy, Converter={StaticResource Negate}}" />
                <Entry IsPassword="True" 
                       Text="{Binding Password}" 
                       IsEnabled="{Binding IsBusy, Converter={StaticResource Negate}}" />
                <Button Text="Log In" 
                        Command="{Binding LoginCommand}"
                        IsEnabled="{Binding IsBusy, Converter={StaticResource Negate}}" />
                <Label Text="{Binding ErrorMessage}" 
                       IsVisible="{Binding ErrorMessage, Converter={StaticResource NullInvisibility}}" />
                <ActivityIndicator IsRunning="{Binding IsBusy}" 
                                   IsVisible="{Binding IsBusy}" />

Then, in our code-behind, we can write out code to work with the UI. Here we have made use of several features such as binding, commands, messaging and async/await:

public partial class LoginPage : ContentPage
    public const string LoginMessage = "login";

    private readonly JsonPlaceholderApi api;
    private string errorMessage;

    public LoginPage()

        // initialize our fake services
        api = new JsonPlaceholderApi();

        // set up the data binding
        LoginCommand = new Command(OnLogin);
        BindingContext = this;

    private async void OnLogin()
        IsBusy = true;

        // reset errors
        ErrorMessage = "";
        // try logging in with our fake services
        var user = await api.LoginAsync(UserName, Password);
        if (user == null) {
            // there was an error
            ErrorMessage = "There was a problem logging in.";
        } else {
            // let the app know we are finished
            MessagingCenter.Send(user, LoginMessage);

        IsBusy = false;

    public string ErrorMessage
        get { return errorMessage; }
        set { errorMessage = value; OnPropertyChanged(); }

    // we don't want to save this as the user types
    public string UserName { get; set; }

    // we don't want to save this at all
    public string Password { get; set; }

    // the login button uses this
    public ICommand LoginCommand { get; }

That is basically all we need to do in order to create our UI. The JsonPlaceholderApi type just makes use of http://jsonplaceholder.typicode.com to get some random data, the User type is just a simple POCO object and the converters are basic IValueConverter implementations.

Displaying Shared Pages in Native Apps

Once we have created our shared Xamarin.Forms page, we can just instantiate out Xamarin.Forms page and then ask for the native version.

On Android, the CreateFragment extension method will return a native Android Fragment, which we can then use as we would any other fragment. On iOS, we use the CreateViewController extension method and we will get out a native UIViewController that, again, we can use as we would any other view controller. And finally, on Windows, we use the CreateFrameworkElement extension method to get out a native FrameworkElement that we can also uses as any other element.

There are two steps to obtaining this native container, first we make sure Xamarin.forms is initialized:

// Android
Xamarin.Forms.Forms.Init(this, null);

// iOS

// Windows
// the `e` from `Application.OnLaunched(LaunchActivatedEventArgs e)`

Once that is done, we can then get the native page:

// create the Xamarin.Forms page for all platforms
var formsPage = new MyFormsPage();

// Android - get the native Fragment
var nativeFragment = formsPage.CreateFragment(this);

// iOS - get the native UIViewController
var nativeController = formsPage.CreateViewController();

// Windows - get the native FrameworkElement
var nativeElement = formsPage.CreateFrameworkElement();

Now that we have the native view, we can just go ahead and use it as if it was created using the traditional mechanisms.

Xamarin.Android and Xamarin.Forms

When using Xamarin.Forms with an Android app, we are going to need to handle the native Fragment that represents the page. To this end, our Android app is using a native .axml layout with a FrameLayout that will hold all our fragments:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    <!-- the other bits of UI -->
        android:id="@+id/frameLayout" />
    <!-- some more UI -->

Then, in our main activity code, we load this UI as normal and everything works as it usually does. When we want to show our new XAML page at some point, all we need to do is to just make sure Xamarin.Forms is initialized and then instantiate the page before navigating to it:

using Xamarin.Forms.Platform.Android;

public void DisplayLogin()
    if (!Xamarin.Forms.Forms.IsInitialized)
        // initialize Xamarin.Forms before we use it
        Xamarin.Forms.Forms.Init(this, null);

        // we want to listen to the messaging center
        Xamarin.Forms.MessagingCenter.Subscribe(this, LoginPage.LoginMessage, (User user) =>
            // update the app
            CurrentUser = user;

            // go back to the main page

    // create the login page (Xamarin.Forms ContentPage)
    var loginPage = new LoginPage();

    // get hold of the native Android fragment that represents the Xamarin.Forms page
    var loginFragment = loginPage.CreateFragment(this);

    // show the login screen (native Xamarin.Android)
        .Replace(Resource.Id.frameLayout, loginFragment)

Xamarin.iOS and Xamarin.Forms

If we want to use Xamarin.Forms in our iOS app, we will be showing a new UIViewController. We first need to make sure that Xamarin.Forms is initialized and then we can just go ahead and create the desired page. We then get the native view controller that can be presented using all the existing means:

using Xamarin.Forms;

partial void OnLoginClicked(UIButton sender)
    if (!Xamarin.Forms.Forms.IsInitialized)
        // initialize Xamarin.Forms before we use it

        // we want to listen to the messaging center
        Xamarin.Forms.MessagingCenter.Subscribe(this, LoginPage.LoginMessage, (User user) =>
            // update the app
            User = user;

            // go back to the main page

    // create the login page (Xamarin.Forms ContentPage)
    var loginPage = new LoginPage();

    // show the login screen
    var viewController = loginPage.CreateViewController();
    NavigationController.PushViewController(viewController, true);

Windows UWP and Xamarin.Forms

When we want to show a Xamarin.Forms page within our native UWP app, we will work with a FrameworkElement. Like with all the other platforms, we have to make sure that Xamarin.Forms is initialized and then just create the page. Once we have obtained the native element, we can just place it anywhere we need it to be. In this example, I am placing my view in a Flyout as the it is being opened:

using Xamarin.Forms;

private void OnLoginFlyoutOpening(object sender, object e)
    var flyout = sender as Flyout;

    if (!Xamarin.Forms.Forms.IsInitialized)
        // initialize Xamarin.Forms before we use it

        // we want to listen to the messaging center
        Xamarin.Forms.MessagingCenter.Subscribe(this, LoginPage.LoginMessage, (User user) =>
            // update the app
            User = user;
            // show some message for some random reason
            WelcomeText = $"Welcome back {user.Name}!";

            // hide the login screen

    // create the login page (Xamarin.Forms ContentPage)
    var loginPage = new LoginPage();

    // set the native dialog to contain the shared login
    var loginElement = loginPage.CreateFrameworkElement();
    flyout.Content = new Frame
        Content = loginElement,
        Width = 300,
        Height = 200


In this fairly long post, we looked at how to quickly embed a Xamarin.Forms page into an existing native app. The process is easy and painless, and will only get better.

You can download the full code from my GitHub repository and try it out for yourself. And maybe have a look at your app and see if some of those screens that are exactly the same could use Xamarin.Forms.

You can also check out some links:

Some other people also have blogs:

And, then there is code:

Powershell & VCVars Batch

Recently, I have been doing more and more work with PowerShell, which is a very good thing. PowerShell is far more powerful than the “classic” batch files, and one of the feature I love is the ability to use the .NET framework right in there.

The downside for development is the fact that Visual Studio environments are not set properly. Typically, I would start the Visual Studio command prompt and then launch PowerShell. This works most of the time as I typically only build one platform.

But, doing a bit of research, I found that I can run the vcvars batch file, and then get a list of all the environment variables. Thanks to Niclas Lindgren and Chris Tavares, I merged and modified their scripts into this small function that allows PowerShell to set up its environment as if vcvars was run. Another big thing is that you can change the environment halfway through, such as if you are building for both x86 and x64.

function VsVarsAll($version = "14.0", $platform = "x86") {
    # handle 64-bit OS differences
    $64bit = !(gv PSHOME).Value.ToLower().Contains("syswow64")
    if ($64bit) {
        $HKLM = "HKLM:SOFTWARE\Wow6432Node"

    # get the path to vcvarsall.bat
    $VsRoot = (gp "$HKLM\Microsoft\VisualStudio\$version").ShellFolder
    $file = [System.IO.Path]::Combine($VsRoot, "VC", "vcvarsall.bat")

    # run the .bat, and return a list of all the envvars
    $cmd = "`"$file`" $platform & set"
    cmd /c $cmd | Foreach-Object {
        # parse the variables, and set them in powershell
        $p, $v = $_.split('=')
        Set-Item -path env:$p -value $v

    # cool factor: update the title
    [System.Console]::Title = "VS $version - $platform Windows PowerShell"

To set up for x86 development, just run:

VsVarsAll -platform "x86"

Similarly, for x64:

VsVarsAll -platform "x64"

If you are running an older/newer Visual Studio, you can set the version:

VsVarsAll -version = "14.0" -platform "x86"

Xamarin.Android Binding Generators


This NuGet is no longer required to get nice parameter names in the binding. With the release of Cycle 8, Xamarin has provided a way to use the class-parse tool that comes with the Xamarin release.

More information can be found on the binding docs, but the gist of it is that you just need to add a new element to your project file:


Build status

A MSBuild Task to make Xamarin.Android binding projects easier.

Currently, there is no nice way to set the parameter names for methods when binding Xamarin.Android libraries. This tiny little NuGet adds a .targets file to the Xamarin.Android Binding project.

The .targets file adds a MSBuild task which will then read the jar elements and automatically generate the transform files needed to set the parameter names for all the bound methods.

You can view the project source for this on GitHub.


Using this is very simple, just install the NuGet:

PM> Install-Package Xamarin.Android.Bindings.Generators

Then, rebuild! That is all!

As this is just used for binding projects, it shouldn’t be installed
into Xamarin.Android app projects.


This is currently what is available in the first release:

  • Automatic parsing of InputJar and EmbeddedJar
  • Handles multiple input files
  • Finds available parameter names
  • Missing parameter names are still meaningful (uses type names)
  • Shouldn’t give matched-no-nodes warnings
  • No manual intervention necessary

Xamarin Events in South Africa


I have created a better page for these events. Although the content of this new page is almost identical to this page, It looks way better. Be sure to check it out here and share to with your South African family/friends/colleagues/developers.


Every month, three cities across South Africa have User Groups for anyone interested in Xamarin. These events range from hands-on development to interesting talks related to Xamarin development.

There are user group meetups in 3 major cities:

Cape Town Xamarin User Group

As I stay in Cape Town, I always attend this User Group. We often discuss a wide variety of Xamarin-related topics.

We meet the second-last Thursday every month:

Location When Summary Description
  August 23, 2017 at 6:30 pm – 9:30 pm Monthly Meetup - MvvmCross 5 & MFractor Cape Town Xamarin Users Group (@CTXUG) Wednesday, August 23 at 6:30 PM https://www.meetup.com/Cape-Town-Xamarin-Users-Group/events/240286772/

Gauteng Xamarin User Group

Fairly often, I will come and visit this user group to say hi, and maybe present. Although I am not always there, the presenters / organizers are very good.

These guys meet almost every second Tuesday of the month:

Location When Summary Description
Microsoft Bryanston Office (3012 William Nicol Drive, Bryanston, Johannesburg, Johannesburg, South Africa) August 8, 2017 at 6:30 pm – 8:00 pm Monthly Meeting Gauteng Xamarin User Group (@GXUGSA) Tuesday, August 8 at 6:30 PM Agenda · Welcome (start 18h30) · Session: Details TBC (start 18h35) – 60 min · Questions and Networking (start 19h35) - 20 min https://www.meetup.com/Gauteng-Xamarin-User-Group/events/240024915/
Microsoft Bryanston Office (3012 William Nicol Drive, Bryanston, Johannesburg, Johannesburg, South Africa) September 12, 2017 at 6:30 pm – 9:30 pm Monthly Meeting Gauteng Xamarin User Group (@GXUGSA) Tuesday, September 12 at 6:30 PM Agenda · Welcome (start 18h30) · Session: Details TBC (start 18h35) – 60 min · Questions and Networking (start 19h35) - 20 min https://www.meetup.com/Gauteng-Xamarin-User-Group/events/241783748/
Microsoft Bryanston Office (3012 William Nicol Drive, Bryanston, Johannesburg, Johannesburg, South Africa) October 10, 2017 at 6:30 pm – 9:30 pm Monthly Meeting Gauteng Xamarin User Group (@GXUGSA) Tuesday, October 10 at 6:30 PM Agenda · Welcome (start 18h30) · Session: Details TBC (start 18h35) – 60 min · Questions and Networking (start 19h35) - 20 min nhttps://www.meetup.com/Gauteng-Xamarin-User-Group/events/241783761/

Durban Xamarin User Group

This user group has just started up, but I know Xamarin developers. We are a great bunch, so come along and see what is happening.

Still to be confirmed, they meet the last Thursday of the month:

No upcoming events

UI Testing for Indie Xamarin Devs

In the Xamarin 4 announcement, there were hundreds of improvements, but some of the most exciting points for indie devs included free access to UITest and Xamarin Insights.

I noticed especially well-received comments during my presentation at the Gauteng Xamarin User Group. Typically South African indie devs complained about high prices, especially due to the exchange rate being very unfavourable.

And this is not just for South Africans; Indie devs don’t usually have large amounts of money to throw at Unit Testing frameworks. They might just grab the best free tool out there. And now, Xamarin has become that “best” and “free” tool.


I think Xamarin.UITest is the best automated UI testing framework currently available. It takes two tried-and-tested frameworks: NUnit and Calabash and merges them to create a excellent C# API for controlling mobile apps.

Not only does UITest make testing easier, we can also test on both devices and simulators at no additional cost. No extra configuration is needed either. When the project is compiled, the test appear in the IDE’s Unit Test panel. From there, the tests can be run as any other unit test.

I installed the NUnit Test Adapter for Visual Studio as this IDE can’t run NUnit tests natively.

Simple Example

Using UITest is very easy, and just requires that the interaction is described using C# code. The actual flow of the code is the same as if you had actually performed the actions on the device.

Lets take an example test case – making sure a credit card number is valid. We would first want to make sure that the text field is clear before entering the number. Then, after the keyboard is hidden, we want to start the validation. Finally, we need to ensure that the error message appears.

In this test, failure comes if the error message does not appear at all, or if the screen changes.

// clear credit card number

// enter a card number
app.EnterText("CreditCardNumber", "123456789123456");

// make sure the keyboard is gone

// tap the validate button
app.Tap (c => c.Button ("ValidateCreditCard"));

// make sure that the error message appears
app.WaitForElement(c => c.Marked("Credit card number is invalid."));

Xamarin Test Recorder

Xamarin recently announced the Xamarin Test Recorder, a preview tool that makes writing mobile UI tests even easier.

Instead of writing this test by hand from scratch, we can make use of the recorder to interact with the app. While we do this, the recorder writes out the steps in C# code. We can then take this code and add it to our test project.

Although the recorder is not perfect yet, we can still use the code and just tweak it a bit. I found that sometimes the recorder wasn’t able to pick up when I had tapped on switches or sliders, but this can be changed. If the element has an ID, then we can swap out the code that tries to find the element by UI index with code that finds the element by ID.

Xamarin 4 – in Bullet Form

With the announcement of Xamarin 4, there were hundreds of changes, new features and improvement. Xamarin included major and minor changes to all phases of the lifecycle of a mobile app.

Mobile Life Cycle

I thought I would re-share some of the features, just in case you missed some 🙂 But, during my presentation at the Gauteng Xamarin User Group, I saw some areas that were especially interesting to South Africa developers.

New in the Xamarin Platform

The most well known area of Xamarin is the BUILD platform. This received some love:

  • Xamarin.Forms 2.0
    Faster, more reliable, and more functional. Pre-compiled XAML. Support for UWP, iOS 9 and Android Material Design. New gestures.
  • Visual Studio and iOS
    Rebuilt the Visual Studio extension from the ground up. Multiple concurrent Visual Studio instances.
  • Mono/.NET Upgrade
    Incorporated large portions from Microsoft’s open sourced .NET codebase.
  • Android and iOS Designers
    iOS designer can load XIB files. Android designer supports Android Material Design. Improved UI and UX for both designers.
  • Objective Sharpie & CocoaPods
    Improved parsing of header files. New attributes for Objective-C equivalents. Support for generating bindings from a CocoaPod.

New in Xamarin Test Cloud

More recently added to Xamarin is the advanced testing capabilities using new testing tools:

  • Xamarin Test Recorder
    New preview tool that makes mobile UI testing dead simple. Initially available for Mac
  • Xamarin.UITest 1.0
    New capabilities for advanced test scenarios. Free for everyone to use. No limits on test duration. No limits on the use of local devices and simulators.

Xamarin Insights

Now generally available, you can track your apps in the wild:

  • General Availability
    Free crash reporting for all Xamarin Platform customers. 30 days data retention.

Something for Everyone

Along with new features and improvements, Xamarin has given developers even more free stuff with each subscription:

  • Xamarin Insights with 30 day data retention.
  • 60 Xamarin Test Cloud device minutes per month.
  • Complete access to Xamarin.UITest.
  • A 30-day trial pass to Xamarin University.

Read the official announcement by Xamarin.

My New (First) Book and This Year

eBook: $40 | Print + eBook: $50

This has been a great year so far, I have released multiple new components on the Xamarin Component Store, committed thousands of lines of code into various repositories, and, finally had my book published!

It has been a long time coming, originally scheduled for about 6 months, but working full time had forced me to go a bit slower. So after 12 months of work, Packt Publishing, made my book, “Xamarin Mobile Development for Android Cookbook”, available to the world.

Beginning Writing

In September last year, they contacted me about authoring a book focused on more advanced concepts when developing Android apps using the Xamarin platform. I cover concepts ranging from using basic UI elements, to managing view states. I also show how one can make use of Bluetooth and NFC communication. Included in the topics are some that cover modern app development, such as making use of the Android support libraries to create modern apps that run on almost all versions of Android.

I won’t lie and say that the book was easy; writing is pretty hard. Once the topic is decided and the code ready, the actual readable text takes a bit of work. I feel that I was able to bring each recipe across in an easy-to-consume manner without compromising on the actual content. This is a lot of work in that it is sometimes hard to write a technical document without knowing the knowledge level of the reader.
In addition to that, sometimes I had to research why I did something. I have done something so many times that it has become automatic, and then I have to go and learn why. And then I sometimes realize that what I had been doing all this time was only one way…

All in all, I quite enjoyed writing, even if it meant very late nights. If I was to write another book, well, it might be some time in the future. I hope that my book sells well, not because of money, but it is an accomplishment. How many people can say they have written a book, and how many of those can say they wrote a good book. If this book sells well, then I would have achieved one of my life goals.

After I first found out about software development when I was 9 years old, I wanted to become a programmer. After the release of Windows, I wanted to be the new Bill Gates. I don’t think I’ll ever get to that level of awesomeness, but I can go for the other things. One of those things is to provide developers with tools that they can use to create the best that can be created.

Why I Started

When I started developing professionally, my projects were ASP.NET websites and Desktop applications. This is great, but typically those apps were company apps and only used during work hours. Mobile apps have always been a passion of mine in that they travel with the user. I have always liked being a back end developer as this is often the area where the “cool” work is done. The UI is great, don’t get me wrong, but almost all of them talk to some library or service.

During my years of development, I really grew to love my work more and more. This love grew into something that I want to share with the world. It started off by helping by brother do a bit of development. He now has built several games using many of the game creation tools. One of the coolest, and most cross-platform, is Scirra’s Construct 2. Recently, he has started using Unity 3D.

Another way I shared my love for development is though my code. I have several repositories on GitHub, which I try and update. I also use this account to update repositories in the community. Sometimes there is that awesome library, but just doesn’t have that feature… For example, there is this tiny library, NLipsum, that allows you to generate a chunk of lorerm ipsum. Although technically not very useful, it is often the simplest way to populate text fields. This library required no changes, but could only be used with desktop .NET platforms. In the age of mobile development, I was able to add a new project that created a Portable Class Library, which can be used everywhere. This is not a headlines-worthy change, but NLipsum is now more cross-platform than ever before.

Writing a book was just another way to share my knowledge and love of development with the world. I hope my book helps both the new guy on the block as well as the other guy that never got around to using In-App billing in his popular Android app. As a result, I am not going to tell you to buy my book… If you want to check it out, or use it to get started with Xamarin.Android apps, you can order it in both an ebook and/or print from Packt Publishing for $32.