With Android applications, mono runtime is placed right on top of the Linux kernel. This creates a parallel execution context to the Android runtime. Xamarin code is then compiled into IL and accessed by mono runtime. On the other hand, Android runtime is accessed by the so-called Managed Callable Wrappers (MCW) which is a marshalling wrapper between the two runtimes. The MCW layer is responsible for converting managed types to Android runtime types and invoking Android code at execution time. Every time that .NET code needs to invoke Java code, this JNI (Java Interop) bridge is used. MCW provides a wide range of applications including inheriting Java types, overriding methods and implementing Java interfaces.

The following image shows the Xamarin.Android architecture:

Figure 1: Xamarin.Android Architecture

Android.* and Java.* namespaces are used throughout the MCWs to access device- and platform-specific features in Android runtime and Java APIs such as facilities like audio, graphics, OpenGL, and telephony .

Using the interop libraries, it is also possible to load native libraries and execute native code in the execution context with Xamarin.Android. The reverse callback execution in this case is handled through Android Callable Wrappers (ACW). ACW is a JNI bridge which allows the Android runtime to access the .NET domain. An ACW is generated at compile-time for each managed class that is directly or indirectly related to Java types (those that inherit Java.Lang.Object).

In iOS applications, the use of an integrated parallel runtime is (unfortunately) not permissible under the iOS SDK agreement. According to the iOS SDK agreement, interpreted code can only be used if all of the the scripts and code are downloaded and run by Apple's WebKit framework.

With this restriction in place, developers can still develop applications in .NET and share code over the other three platforms. At compile time, projects are first compiled into IL code and then (with the Mono Touch Ahead-Of-Time compiler—mtouch) into static native iOS bits. This means that iOS applications developed with Xamarin are completely native applications.

Figure 2: Xamarin.iOS Compilation

Xamarin.iOS, like Xamarin.Android, contains an interop engine that bridges the .NET world with the Objective-C world. Through this bridge, under the ObjCRuntime namespace, users are able to access iOS C-based APIs, as well as using the Foundation namespace, and can use and derive from native types and access Objective-C properties. For instance, Objective-C types like NSObject, NSString, and NSArray are exposed in C# and provide binding to underlying types. These types can be used either as memory references or as strongly-typed objects. This improves the development experience and also increases type-safety.

This static compilation is the main reason for using a build machine to develop iOS applications with Xamarin on the Windows platform. Therefore, there is no reverse-callback functionality in Xamarin.iOS where calls to native runtime from .NET code are supported but calls from native code back to .NET domain are not. There are other features that are disabled because of the way that Xamarin.iOS applications are compiled. For example, no generic types are allowed to inherit from NSObject. Another important limitation is the fact that no dynamic type creation is allowed at runtime which, in return, disables the use of dynamic keywords in Xamarin.iOS applications.

In a similar way to Xamarin.Android development, with Xamarin.iOS, it is also possible to re-use native code and libraries from managed code. To do this, Xamarin provides a project template called a binding library. A binding library helps developers create managed wrappers for native Objective-C code.

Even though Xamarin does not include Windows Runtime as a target platform nor provide specialized tools for it (other than Xamarin.Forms), cross-platform projects that involve Xamarin can and generally do include Windows Runtime projects. Since .NET and C# are indigenous to Windows Runtime, most of the shared projects (such as portable libraries, shared projects, and Xamarin.Forms projects) can be reused in Windows Runtime with no further modification.

With Windows Runtime, developers can create both Windows Phone 8.1 and Windows Store applications. Windows Phone 8 and Windows Phone 8.1 Silverlight can also be targeted and included in the PCL description.

Android applications can be developed and compiled on Windows using both Xamarin Studio and Visual Studio with Xamarin extensions installed, as well as on an Apple OS X operating system with Xamarin Studio for Mac installed.

For iOS application development, whether using Visual Studio on Windows or Xamarin Studio on Apple OS X, an Apple Macintosh computer, running at least OS X Mountain Lion, is required. The build machine should have the Xcode development tools with iOS SDK together with the Xamarin.iOS suite installed.

On the other hand, Windows Store applications can only be developed on the Windows platform.

On the virtualization front, developers are also limited. OS X cannot be installed and run on a non-Apple branded machine nor can it be virtualized, according to the end user agreement. On the other hand, you can set up a virtual machine on an OS X development machine for Microsoft Windows and Visual Studio. However, in this case, the system should be running nested virtualization for Hyper-V to run Visual Studio for Windows Phone and Android emulators. Even though Parallels and VMWare Fusion support nested virtualization, Microsoft doesn't support nesting Hyper-V and, therefore, such machines may be unstable.

Xamarin Studio setup and configuration

Xamarin Studio can be set up on both the Windows and OS X operating systems. Developers can download it from www.xamarin.com and follow the installation instructions. Xamarin components for target platforms (for example, Xamarin.iOS, Xamarin.Android, and so on) together with the dependencies for these platforms (for example, Android SDK) should be downloaded and installed on the development machine. One required component for OS X, which has to be installed separately and configured, is the iOS SDK with the Xcode development environment.

Figure 4: Xamarin Setup on Mavericks (OS X 10.9)

On Microsoft Windows, it is important to mention that Xamarin Studio only supports the development of Android applications. Neither Windows Phone nor iOS application (even with the remote build machine) projects can be viewed, modified, or compiled with Xamarin Studio on Windows.

Figure 5: Xamarin Dev. Environment Setup on OS X

While developing on OS X, the only option for developing Windows Phone applications together with iOS and Android, is to use a Windows virtual machine and run Visual Studio in parallel with Xamarin Studio. This setup is also helpful for developers who use Team Foundation Server as the source control, since they can use the enhanced integration offered by Visual Studio Client rather than the standalone TFS Everywhere. It can also be set up so that the OS host machine can be paired with Visual Studio to become the build host for iOS applications.

Visual Studio setup and configuration

A typical Windows development platform configuration for Xamarin projects includes Visual Studio 2013 or 2015, an Apple OS X build host and Hyper-V and/or VirtualBox to be able to use Android and Windows Phone emulators. Xamarin.iOS applications are then compiled and emulated on the Apple OS X build host.

Figure 6: Windows Platform Xamarin Development Environment

Note

In spite of the fact that it is technically possible to run OS X with a virtual machine in the Microsoft Windows environment, Apple's license agreement does not allow this:

"2.H. Other Use Restrictions: The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so."

On Microsoft Windows, the Xamarin installation is similar to the Xamarin Studio setup on Apple OS X. All of the prerequisites for Xamarin development are installed with the Xamarin for Windows package, together with the Visual Studio extension.

Figure 7: Visual Studio 2015 Setup

One of the key differences between OS X and Microsoft Windows is that Visual Studio 2015 now includes cross-platform development tools such as Android SDK, development kits, and Xamarin project templates. Therefore, the Xamarin installation is only responsible for installing the extensions for the requested platforms (that is, Xamarin.iOS and/or Xamarin.Android).

In order to develop and test iOS applications and visualize and edit storyboards with Visual Studio, an Apple OS X machine must be connected to Visual Studio as a build host. Xamarin 4.0 introduced the concept of Xamarin Mac Agent, which is a background process on the OS X machine providing the required SSH connection to Visual Studio (a secure connection over port 22). Prior to Xamarin 4.0, the build host machine needed to run the so-called Mac build host which was used to pair the Mac host with Visual Studio. The only prerequisites for Xamarin Mac Agent are to have Xamarin.iOS installed on both the Windows workstation and the OS X build host and the build host to have a remote login enabled for the current user. In Visual Studio, the Find Xamarin Mac Agent dialog helps establish the remote connection.

Figure 8: Xamarin.iOS Build Host

It is important to keep in mind that the Mac machine paired with Visual Studio has to have Xcode with iOS SDK installed. A developer account (either enrolled into the app developer program or not) must also be added to the accounts configuration section of Xcode.

Note

If the account associated with Xcode does not have a paid subscription to the developer program, the platform for the iOS projects can only be set for simulator and debug selection to one of the simulator options, not an actual device. Otherwise, the user will be presented with an error message such as, No valid iOS code signing keys found in keychain.

Android applications can be run and tested on a number of emulators on both Microsoft Windows and Apple OS X operating systems.

Android SDK comes with the default emulator that is installed on the development machine. This emulation option is available both on OS X and Windows operating systems.

Figure 9: AVD and Genymotion Emulators

This Android emulator uses the Android Virtual Devices (AVD) to emulate the Linux kernel and the Android runtime. It does not require any additional virtualization software to run, however, the lack of virtualization support makes AVD much less responsive and makes the startup time relatively longer. It also provides a wide range of emulation options for developers, from SMS and telephony to hardware, peripherals, and power events.

The Genymotion emulator (https://www.genymotion.com/) is one of the most popular emulation options for Xamarin and Android developers. Although it is available with a free license, the free version only allows for GPS and camera emulation. The Genymotion emulator runs on (and is installed with) VirtualBox virtualization software.

bcdedit /copy {current} /d "No Hyper-V"
bcdedit /set {<identifier from previous command>} hypervisorlaunchtype off

The last and the most recent Android emulation option is the Visual Studio Android emulator. This Android emulator runs on Hyper-V and provides various device API versions and emulation options for developers.

Figure 10: Visual Studio Android Emulator

The Visual Studio Android emulator is installed as part of the Visual Studio 2015 installation and can also be installed as an extension later. The emulator provides a similar experience to the Windows Phone emulator and allows developers and testers to use almost the same set of emulation options with different device profiles as well as different API levels.

iOS emulation is only possible with the Xcode tools and iOS SDK. The iOS simulator can be started either directly on Apple OS X while developing with Xamarin Studio, or by pairing the build machine with the Visual Studio Xamarin extension running on Microsoft Windows. It also can be used to test both iPhone and iPad applications.

Portable class libraries are the most common way of sharing code between cross-platform projects. PCLs provide a set of common reference assemblies that enable .NET libraries and binaries to be used on any .NET-based runtime or with Xamarin compilers—from phones to clients, to servers and clouds. PCL modules are designed to use only a specific subset of the .NET framework and can be set to target different platforms.

Figure 12: Portable Class Library Targets

Microsoft has a designation for each target combination and each profile also gets a NuGet target. A subset of .NET libraries for portable class libraries were released through NuGet with the release of Visual Studio 2013. This makes it possible for developers to release their work through NuGet packages, targeting a wide range of mobile platforms (see the NuGet packages section for more information).

While creating a PCL, the biggest drawback is the fact that no platform-specific code can be included in or referenced by the project. This caveat is generally addressed by the abstraction of platform-specific requirements or by using dependency injection or similar methods to introduce the implementation in platform-specific projects.

For instance, in the device-specific peripheral example below, the common portable class library has a constructor that accepts two separate interfaces which can be injected with a dependency injection container or can be initialized with a device-specific implementation. The common library, in return, creates a business logic implementation, as shown:

namespace Master.Xamarin.Portable
{
    public class MyPhotoViewer
    {
        private readonly IStorageManager m_StorageManager;

        private readonly ICameraManager m_CameraManager;
        public MyPhotoViewer(IStorageManager storageManager, ICameraManager cameraManager)
        {
            m_StorageManager = storageManager;
            m_CameraManager = cameraManager;
        }

        public async Task TakePhotoAsync()
        {
            var photoFileIdentifier = await m_CameraManager.TakePhotoAndStoreAsync();

            var photoData = await m_StorageManager.RetrieveFileAsync(photoFileIdentifier);

            // TODO: Do something with the photo buffer
        }
    }

    /// <summary>
    /// Should be implemented in Platform Specific Library
    /// </summary>
    public interface IStorageManager
    {
        Task<string> StoreFileAsync(byte[] buffer);

        Task<byte[]> RetrieveFileAsync(string fileIdentifier);
    }

    /// <summary>
    /// Should be implemented in Platform Specific Library
    /// </summary>
    public interface ICameraManager
    {
        Task<string> TakePhotoAndStoreAsync();
    }
}

The term, shared project, was initially coined by the Microsoft team with the release of Universal Apps for Windows Phone and Windows Runtime (that is, Visual Studio 2013). With the arrival of Xamarin, shared projects can also be referenced by Android and iOS projects. These types of projects are essentially wrappers or containers for shared code and resource files that are linked to multiple projects and platforms. Shared file assets are included in the referencing projects later and compiled as part of these modules.

Figure 13: Shared Projects

While using shared projects, developers should be careful when including platform-specific code since the shared elements will be included in all the referencing projects and compiled. Compiler directives (for example, #if __ANDROID__) can be introduced in shared projects to denote that certain parts of the code are only for a specific platform.

Tip

Visualizing platform-specific code in shared projects

With Visual Studio (2013 or higher), it is possible to visualize different execution paths according to the combinations of conditional compilation constants.

Figure 14: Visual Studio shared project editor

Visual Studio provides a dropdown in the top corner of the editor window which determines the platform-specific projects that are referencing the shared project. By selecting the project, you can see the disabled sections of the code, according the target platform.

If we used the same example to take a photo, we would need to create two completely different implementations for the same action, as shown here:

private async Task<string> TakePhotoAsync()
{
    string resultingFilePath = "";

    var fileName = String.Format("testPhoto_{0}.jpg", Guid.NewGuid());

#if __ANDROID__

    Intent intent = new Intent(MediaStore.ActionImageCapture);
    var file = new File(m_Directory, fileName);
    intent.PutExtra(MediaStore.ExtraOutput, Net.Uri.FromFile(_file));

    // TODO: Need an event handler with TaskCompletionSource for
    // Intent's result
    m_CurrentActivity.StartActivityForResult(intent, 0);

    resultingFile = file.AbsolutePath;

#elif WINDOWS_PHONE_APP

    ImageEncodingProperties imgFormat = ImageEncodingProperties.CreateJpeg();


    // create storage file in local app storage   
    var file = await LocalStore.CreateFileAsync(fileName);

    resultingFilePath = file.Path;

    // take photo   
    await capture.CapturePhotoToStorageFileAsync(imgFormat, file);

#endif

    return resultingFile;
}

Xamarin.Forms is the unified library for creating UI implementations for target platforms to be rendered with native controls. Xamarin.Forms projects are generally created as PCL projects and can be referenced by Xamarin.iOS, Xamarin.Android, and Windows Phone development projects. Xamarin.Forms components can also be included in shared projects and can utilize platform-specific features.

Developers can effectively create common UI implementations with these forms, either declaratively (with XAML), or by using the API provided. These views, which are constructed with Xamarin.Forms components, are then rendered at runtime with platform-specific controls.

Development projects can be realized with Xamarin.Forms by creating the data access model up until the UI components with a shared implementation, thus raising the amount of shared code between the platforms to as much as, or at times more than, 90%.

NuGet, which was initially an open source Microsoft initiative to share code among developers, has now become a much larger ecosystem. While NuGet servers can be used as an open source library-sharing platform, many development teams use NuGet as a private company repository for compiled libraries.

NuGet packaging is a viable code-sharing and reuse strategy for Xamarin projects since it is supported by both Xamarin Studio and Visual Studio (with no further installation following Visual Studio 2012).

The NuGet target framework moniker for Xamarin projects is mono and there are further groupings such as MonoAndroid10, which refers to projects with a target framework of MonoAndroid version 1.0 or higher. Other platform targets are:

Developers are free to either re-use publicly available NuGet packages or create their own repository to store compiled packages to include in Xamarin projects.

Tip

Creating NuGet packages in Visual Studio 2015

With the release of Visual Studio 2015, there is a new project template that should help developers to create and reuse NuGet packages.

Figure 15: The Visual Studio NuGet package project template

More information on creating NuGet packages and publishing them can be found on the NuGet documentation hub: (http://docs.nuget.org/create/creating-and-publishing-a-package)

Components are another approach to re-using compiled libraries and modules in Xamarin projects. The Component Store is built into both Xamarin Studio and Visual Studio and it has gathered a number of re-usable submissions from developers since its release in 2013. Components can be downloaded and installed into projects in the same way as for NuGet packages by using the Xamarin Component Store. The Xamarin Component Store can be found at https://components.xamarin.com.

"How much of the code can be reused throughout the project?"

Reusability is one of the key quality identifiers in cross-platform development projects. Xamarin, especially with the release of Xamarin.Forms, has provided developers with extensive resources to create platform-agnostic components that can decrease redundancy and reduce developer hours in complex projects. Code quality matrices generated by Visual Studio and unit test coverage results can convert this descriptor into a quantifiable measure.

"How much do the shared components know about the platform?"

It is almost unavoidable not to include platform-specific bits in cross-platform solutions. The level that these modules are abstracted to increases the robustness of the shared components and is closely related to how loosely the implemented logic is coupled with the underlying platform. In this way, the shared components can be tested easily with mock or fake libraries without having to create platform-specific test harnesses. Unit test code coverage results help determine the testability of the application.

"How easy is it to transpose the project into another platform?"

On top of the platform-specific abstracted implementation, an autonomous shared implementation layer creates flexible solutions which can easily be adapted to other platforms. Reducing the dependencies of the shared logic to the underlying platform not only inherently increases the reusability but also the agility of the development projects. The number of conditional compilation blocks or if or else loops for the underlying platform on shared projects identifies the amount of code executed according to the platform.

"How much does your application blend into the platform?"

Even though the ultimate goal while developing with Xamarin is to create an application that can be easily compiled onto multiple targets, the applications created with Xamarin should look, feel and behave as if they were designed for that specific platform. The UI paradigms and user interaction mechanisms of each platform should be respected while creating a common foundation. Nativity is more of a nominal and subjective measure when compared to the aforementioned code descriptors.