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
Aliens (Block B, Ground Floor, Longkloof Studios, Darters Road, Gardens, Cape Town, 8000, Cape Town, Cape Town, South Africa) July 19, 2017 at 6:30 pm – 9:30 pm Iot Evening (Cross Platform Iot) Cape Town Xamarin Users Group (@CTXUG) Wednesday, July 19 at 6:30 PM Join us for an evening of all things Iot using the magic of Xamarin, Azure and Cognitive Services. Featuring Windows 10 Iot Core, Android Things an... https://www.meetup.com/Cape-Town-Xamarin-Users-Group/events/240083790/
  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) July 11, 2017 at 6:30 pm – 8:00 pm Cross Platform IoT Gauteng Xamarin User Group (@GXUGSA) Tuesday, July 11 at 6:30 PM Join us for an evening of all things IoT using the magic of Xamarin, featuring Windows 10 IoT Core, Android Things and the brand new Xamarin IoT Prev... https://www.meetup.com/Gauteng-Xamarin-User-Group/events/240024901/
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/

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.

Stretching Views with Auto Layout on iOS

I am busy porting my Windows Phone app to Android and iOS, and everything seems to be going quite well. I am using MvvmCross with Xamarin Platform Tools and there is much code reuse.

This is a simple app, literally two screens that could actually be merged into a single screen: A ID number entry form and a status page with a few lines of text. However an app is an app and an Android, iOS and Windows Phone app is still just awesome to have.

This is my first attempt at creating an iOS app from scratch. I have done a couple of Android apps for various companies, but iOS is still ultra new for me. So far as I can see, Apple has created a huge API with many great interfaces. The iOS API is more mature than the Android API, and this shows in many areas.

One of the awesome features that I came across is the Auto Layout features of creating interfaces. My app’s start screen has a view that contains the controls and an image view underneath. The controls view is of a fixed size as it just contains a text box and a button, but the image scaled to fit the remaining space.

On Windows Phone, I was just using a Grid with an expandable row and set the image to fill it. On Android, I placed the image view inside a LinearLayout and set the weight to 1. On iOS, I wasn’t sure… I recalled from my previous dabbling that there was some Autoresizing options, but after reading around, there seems to be something better, Auto Layout.

Eventually, I discovered that this is quite powerful, but a little more complex. What I needed to do was set the image view to be “anchored” at various points. In this case, the image was to expand to fill the space, so I naturally set the top, left bottom and right sides to be pinned at a nice space from the edge of the screen.

I expected the view, if pinned at the top and at the bottom, would grow as the points moved apart, unfortunately for me, there was something that I missed. The height. When I looked around, there was a little icon showing that there was a problem with my constraints. It picked up that there was a problem with the heights of my views, but I wasn’t sure what to do exactly.

My first solution to the problem, but actually wasn’t a solution was to see if there was a way to tell the image view to be expandable. For some reason it did not occur to me that if it was growing horizontally and not vertically, I needed to check to see what was different there. But anyway, I found a little option called “Intrinsic Size” and if I set this to “Placeholder” all the errors went away, but sadly for me, this has little to do with my problem. Intrinsic Size is for when there is shadows or other decoration features that the layout engine should ignore. Even though there were no errors, the actual app on the device just failed and the image was stretched over everything. Sad.

So, it finally occurred to me that if my image was anchored below the controls view, I may actually need to specify a height for the controls. This is not exactly intuitive as it should use the designer’s size automatically, but that’s just me. Anyway, after giving the controls view a height, the running app now correctly stretched my image from the bottom of the view to the bottom of the screen, or, filled the space. Yay!

Because I am cool with images, and Balsamiq Mockups, I have prepared an image for the viewers:

Auto Layout on iOS

Genetics for Xamarin.Android

As with all my development, I try to do as little as possible 🙂 The more code you type, the more you have to maintain and bugfix.

Now, being that I enjoy working on libraries/backends rather than on UI/frontends, I like my code to be neat and clean. Sure, the final app must be good, but I read the code.

So, I looked around and found a simple way to reduce the overall boilerplate code, as well as improve the final code. Although good code doesn’t mean a good app, bad code often results in a poor app.

A Practical Example

This library is focused around only one small things, but that one small thing is done over and over again everywhere… boilerplate! This one thing is getting hold of an Android View or Resource based on the ID.

For example, if we have an Activity with X amount of UI widgets that we need to access:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:textSize="50sp" />
    android:layout_margin="10dp" />
    android:layout_margin="10dp" />

Then, usually we would have X number of FindViewById method calls and X fields:

private TextView myLabel;
private Button myButton;
private ListView myListView;

protected override void OnCreate(Bundle savedInstanceState)


  myLabel = this.FindViewById<TextView>(Resource.Id.myLabel);
  myButton = this.FindViewById<Button>(Resource.Id.myButton);
  myListView = this.FindViewById<ListView>(Resource.Id.myListView);

This is not much code as it stands, but it is a bit monotonic if you ask me… especially if you have a good few widgets on the screen.

Now, this is where Genetics comes in. We can replace all those FindViewById methods with a single Splice method call, and annotate the fields, or properties, with the [Splice] attribute:

private TextView myLabel;
private Button myButton;
private ListView myListView;

protected override void OnCreate(Bundle state)



And that’s all there is to it!


Not only can we avoid all the FindViewById method calls, but we can also avoid querying the Resources object for the various values. Given the resource file:

  <string name="titleText">Genetics</string> 

We can automatically populate the field or property in the same way as with the views.

private string loginErrorMessage;

protected override void OnCreate(Bundle state)
  // ...



A special case exists when the target object instance that contains the widgets is not an Activity, Dialog or View. This is most commonly used when inflating views, as when using a Fragment:

public class MyFragment : Fragment
  private TextView textView;

  public override View OnCreateView(LayoutInflater inflater, ViewGroup container, Bundle state)
    var view = inflater.Inflate(Resource.Layout.MyFragmentLayout, container, false);

    Geneticist.Splice(this, view);

    return view;

List Views

Another popular case is when working with a ListView and the view holder pattern for the list items:

public class SimpleAdapter : BaseAdapter
    public override View GetView(int position, View convertView, ViewGroup parent)
        ViewHolder holder;
        if (convertView != null)
            holder = (ViewHolder)convertView.Tag;
            convertView = inflater.Inflate(Resource.Layout.SimpleListItem, parent, false);
            holder = new ViewHolder(convertView);
            convertView.Tag = holder;

        holder.word.Text = ...;
        holder.length.Text = ...;
        holder.position.Text = ...;

        return convertView;

    private class ViewHolder : Java.Lang.Object
        public TextView word;
        public TextView length;
        public TextView position;

        public ViewHolder(View view)
            Geneticist.Splice(this, view);

Downloading & Using

There is lots more that can be done, or rather, not done, using Genetics. The best way to get hold of this library is either through the Xamarin Components Store or from NuGet.

This library is really tiny, and has no dependencies other than Android…

Lots more information can be found on the Getting Started guide as well as in the github.

Self-Signed Certificates and Xamarin.Android

Recently, I had the opportunity to work with Android and self-signed certificates. This is both simple and complex at the same time. In order for Android to be able to handle self-signed certificates, those certificates have to be registered with the SSLSocketFactory.

The HTTP Client

What we will need to do is create a new SSLSocketFactory, and pass that to the HTTP client. In this case, we are using OkHttpClient to communicate over the network. OkHttp is an HTTP+SPDY client for Android applications, and can be found:

Once we have the socket factory, we pass it to the OkHttpClient using the SetSslSocketFactory method:

// get the socket factory
var socketFactory = GetSocketFactory();
// create a new OkHttpClinet 
var client = new OkHttpClient();
// add the socket factory to the client
// now we can use the client as usual
Request request = new Request.Builder().Url(&quot;https://&lt;yourserver&gt;&quot;).Build();
Response response = await client.NewCall(request).ExecuteAsync();
var body = await response.Body().StringAsync();

SSL The Socket Factory

In order to create the socket factory, we will need the self-signed certificate. This can be downloaded from the website, or obtained from the source. Then, we must include it in the app. In this instance, I have added it as a raw resource. Loading the certificate into the socket factory consists of a few steps:

  1. Load the certificate out of the resources/assets and into a Certificate instance
  2. Create a new KeyStore instance, and add the Certificate
  3. Create a new TrustManagerFactory instance from the KeyStore
  4. Get the IX509TrustManager from the TrustManagerFactory
  5. Create the new SSLContext, and initialize with the IX509TrustManager
  6. Get the SocketFactory from the SSLContext

Here is the code that does this:

/// &lt;summary&gt;
/// This method returns the configured SSLSocketFactory that contains
/// the self-signed certificate.
/// &lt;/summary&gt;
public static SSLSocketFactory GetSocketFactory()
    // Load our certificate from resources (we created this one using OpenSSL and 
    // saved as a .cer using Windows' certlm console)
    var certificateFactory = CertificateFactory.GetInstance(&quot;X.509&quot;);
    Certificate certificate;
    using (var stream = Application.Context.Resources.OpenRawResource(Resource.Raw.selfsigned)) {
      certificate = certificateFactory.GenerateCertificate(stream);

    // Create a KeyStore containing our trusted CAs
    var keyStore = KeyStore.GetInstance(KeyStore.DefaultType);
    keyStore.Load(null, null);
    keyStore.SetCertificateEntry(&quot;ca&quot;, certificate);

    // Create a TrustManager that trusts the CAs in our keystore
    var algorithm = TrustManagerFactory.DefaultAlgorithm;
    var trustManagerFactory = TrustManagerFactory.GetInstance(algorithm);
    var trustManagers = trustManagerFactory.GetTrustManagers();
    var trustManager = trustManagers[0].JavaCast&lt;IX509TrustManager&gt;(); 

    // Create an SSLContext that uses our TrustManager
    var context = SSLContext.GetInstance(&quot;TLSv1.2&quot;);
    context.Init(null, new ITrustManager[]{ new CompleteX509TrustManager(trustManager) }, null);    

    // return the final socket factory
    return context.SocketFactory;

The Trust Manager

Because we are usinmg a custom trust manager with a custom keystore that only contsins the one self-signed certificate, all other certificates will be rejected. To avoid this, we wrap the trust manager in a new trust manager that first tries the default trust manager. Only when the default trust manager fails to verify the certificate, we try the custom trust manager:

/// &lt;summary&gt;
/// This trust manager wraps a custom socket factory and provides a
/// fallback to the default trust manager with the system certificates.
/// This allows the app to communicate not only with a self-signed 
/// server, but also servers with certificates from a CA.
/// &lt;/summary&gt;
public class CompleteX509TrustManager : Java.Lang.Object, IX509TrustManager
    private readonly IX509TrustManager defaultTrustManager;
    private readonly IX509TrustManager localTrustManager;

    public CompleteX509TrustManager(IX509TrustManager localTrustManager)
        this.localTrustManager = localTrustManager;

        var algorithm = TrustManagerFactory.DefaultAlgorithm;
        var defaultTrustManagerFactory = TrustManagerFactory.GetInstance(algorithm);
        var trustManagers = trustManagerFactory.GetTrustManagers();
        defaultTrustManager = trustManagers[0].JavaCast&lt;IX509TrustManager&gt;();

    public void CheckClientTrusted(X509Certificate[] chain, string authType)
        // we are the client

    public void CheckServerTrusted(X509Certificate[] chain, string authType)
        try {
            defaultTrustManager.CheckServerTrusted(chain, authType);
        } catch (CertificateException) {
            localTrustManager.CheckServerTrusted(chain, authType);

    public X509Certificate[] GetAcceptedIssuers()
        // we are not the server
        return null;

Some of the namespaces used are in the Java and Javax namespaces:

using Java.Interop;
using Java.Net;
using Java.Security;
using Java.Security.Cert;
using Javax.Net.Ssl;