Nuts & Bolts of Xamarin.Android
In my first publish post I gave a very high level overview of what Xamarin is and what it isn’t. I then followed up with a post describing the nuts & bolts of Xamarin.iOS. In this article, I’ll be describing the nuts & bolts of Xamarin.Android. And as I started in my previous two posts, I think it is essential to understand what Xamarin.Android is, how it is compiled, and how it executes on your Android device. Though it is easy to jump right in and start coding, I believe it is essential to understand Xamarin.Android fundamentals, as well as the Android operating system fundamentals. In the long run, this will be beneficial when you have to start debugging your apps. It will also help you troubleshoot issues an understand what is happening between the Android operating system, Xamarin.Android, and your own code.
Overview of a Xamarin.Android Application
In my initial post, I explained at a high level that Xamarin.Android was a C# wrapper around the Android SDK. In other words, Xamarin.Android allows you to use the same Android SDK that Java developers use to create Android applications. The main difference is that you can access the Android SDK via C#, instead of Java. Though this explanation is adequate for most developers, it is important to understand how this is accomplished. Trust me, once you become a more experienced and accomplished mobile developer, understanding these concepts is essential to troubleshooting real-world problems that may occur in your application. It will also help you in optimizing your application for better performance and to consume less memory. In the mobile world, consuming as little memory as possible is critical for a high performing application.
Figure 1: Overview of a Xamarin.Android Application
What Is The Mono Framework?
Mono is a free and open source project whose goal is to create an ECMA standard-compliant version of Microsoft’s .NET Framework. Mono is based on the ECMA standards for C# and theCommon Language Runtime. The project was originally started by Ximian in July 2001, founded by Nat Friedman and Miguel de Icaza. The goal was create an open source version of the .NET Framework that would not only run on Windows, but on Linux. Version 1.0 of Mono was release in June 2004, almost a year after the company was acquired by Novell. After Novell was acquired by The Attachmate Group in 2011, they laid off all US staff working on the Mono Project. But through a license agreement between Novell, now a subsidiary of Attachmate, a license agreement was reach between Friedman’s and de Icaza’s newly formed company Xamarin. Xamarin would now take stewardship of the Mono Project. Since then, Mono has evolved from creating desktop applications for Linux to creating applications on embedded systems, iOS, Android, Apple’s OS X, and other non-Windows platforms.
The Mono Framework consists of four components. They include the C# Compiler, the Mono Runtime, the Base Class Library, and the Mono Class Library.
Figure 2: Mono Framework Overview
The Mono C# Compiler
The Mono C# compiler is a feature complete compiler for C# 1.0, 2.0, 3.0, 4.0, and 5.0. It meets all EMCA specifications and includes support for generics, partial types, anonymous methods, lambda expressions, and async/await. So another words, all the unique and neat features you use for your C# .NET projects also applies to the Mono C# compiler.
The Mono Runtime
The Mono runtime is the equivalent of the Common Language Runtime in the Microsoft .NET Framework. It implements the EMCA Common Language Infrastructure (CLI). Just like the .NET CLR, the Mono Runtime provides a Just-in-Time (JIT) compiler, an Ahead-of-Time (AOT) compiler, and a Garbage Collector. Because it meets the EMCA specifications, the Mono Runtime is as feature complete as the .NET CLR.
The Mono Base Class Library
The Mono base class library is the equivalent of the Microsoft .NET Base Class Library. It provides a comprehensive set of classes, interfaces, and data types that are necessary to build applications using C#. It includes basic types such as integers, floats, doubles, strings, etc. One very important thing to note here is that not all .NET Base Class Library classes are implement in the Mono base class library. The Mono base class library only implements classes that are platform independent (i.e. that do not rely on the Windows operating system).
For example, many classes in the System.Drawing namespace, such as Bitmap, are .NET wrappers around GDI+. Since GDI+ is a graphics library specific to the Windows operating system, it can’t be implemented in Mono. However, to get around this, you’ll have to use the platform implementation of the class you’re looking for. In the case ofSystem.Drawing.Bitmap, you would use a MonoTouch.UIKIt.UIImage in iOS, anAndroid.Widget.Bitmap in Android, and aSystem.Windows.Media.Imaging.BitmapImage for Windows Phone.
The Mono Class Library
The Mono class library is an extension of the Mono Framework. It provides many classes that are not included in the Microsoft .NET Base Class Library. These classes are very useful for building Linux applications, which includes Gtk+, LDAP, OpenGL, etc. This library is useful for desktop Linux applications, and don’t really apply to mobile development on iOS, and Android. But it is worth noting it does exist as a part of Mono, but does not apply to mobile development.
Xamarin.Android & the Android SDK
The Android SDK is the framework that allows Java developers create applications for Android devices such as phones and tablets running the Android operating system. Just like the .NET Framework, it includes many components that help you create user interfaces, access to media such as sounds and imaging, and core services such as networking, location services, and threading. Usage of the SDK is done by using the Java programming language and by using a number of tools such as Eclipse or Android Studio.
Figure 3: Partial Xamarin.Android Bindings
Xamarin.Android allows you to access the Android SDK by using the C# programming language (via the Mono Runtime) and using either Xamarin Studio or Visual Studio as the IDE. In Figure 3, you can see that the namespaces with a black font color (System.Net, System, etc) are a part of the Mono Base Class Library. The namespaces with a green font color (ActionBar, NFC, etc) are the Xamarin.Android C# bindings to the Android SDK. Now just pretend the top half of the figure is replaced with the Windows Presentation Foundation SDK, the Windows Phone SDK, or the Windows Communication Foundation SDK. When Microsoft develops a new Framework/Library, it just hooks into the .NET Base Class Library. So you can just think of Xamarin.Android as just another library as if Microsoft developed it in the next version of .NET.
How Is A Xamarin.Android App Compiled?
As any experienced .NET developer would know, a .NET application is compiled from C# into Microsoft Intermediate Language (MSIL). The MSIL binary can be an *.exe, *.dll, *.svc, etc. When the application runs, the .NET Common Language Runtime then interprets the MSIL using Just-in-Time (JIT) compilation and executes the MSIL as native (processor specific) code.
Though a Xamarin.Android gets compiled and executed like a .NET application, there are some differences on how it executes. Like a .NET project, a Xamarin.Android project gets compiled into Intermediate Language (IL). However, the difference lies in execution. When a Xamarin.Android application runs, it runs in parallel with the Mono Runtime (JIT) and the Dalvik Runtime (JIT). The Davlik runtime is the Android implementation of the Java Runtime. When you access Android Android SDK through the C# bindings, you are tapping into the Dalvik runtime underneath the hood. Both runtimes JIT IL and Bytecode into native (processor) specific code.
Figure 4: IL Compilation And JIT Execution
Unlike the iOS operating system, the Android operating system does allow dynamic code generation. Which in turn, allows for Just-In-Time execution by the Mono runtime, and obviously the Dalvik runtime.
As of this writing, Android 4.4 (KitKat) includes an experimental version of the upcoming Android Runtime (ART). ART will eventually replace the Dalvik runtime’s JIT model as ART introduces Ahead-of-Time Compilation (AOT), similar to how a Xamarin.iOS project executes. With AOT, Android applications will have better performance, garbage collection, application debugging, etc. Xamarin.Android does also have experimental support for ART, but I have not really experimented with this. But I’m sure Xamarin will be ready when ART is ready for production release.
Limitations of a Xamarin.Android Project
When you’re working with pure C# code (i.e. classes that are not a part of the Android SDK) Generics are fully supported. However, if you are working with classes that are defined in the Android SDK, then generics have partial support. The Xamarin documentation does a really good job of explaining the limitations. However, just like on Xamarin.iOS, I have yet to encounter these limitation and it is unlikely you would too. I recommend you consult the documentation for further reading.
Required Tools
In order to develop an Android application using Xamarin.Android, you need the following tools:
- An Intel-based Macintosh computer running Mac OS 10.8 (“Mountain Lion”) or above 0R a Windows 7 or above PC.
- Your required Android SDKs downloaded from the Android SDK Manager.
- Xamarin Studio or Microsoft Visual Studio 2010 or above
- Visual Studio Express is not supported because the Express editions do not support plug-ins.
Software & Hardware Requirements
The easiest and most common way to develop a Xamarin.Android application is using Xamarin Studio on a Mac or on a PC. Xamarin Studio is an IDE that was forked from the MonoDevelop IDE. Though different project types are supported, Xamarin Studio is best used for developing mobile applications for iOS and Android, and for developing Mac OS X applications. It is quite a powerful IDE that has many features you would expect from a modern IDE. It includes basic features like a debugger, intellisense, source control integration, and even Resharper like features.
Alternatively, you can use Visual Studio 2010 or above on a Windows machine to develop Xamarin.Android applications. This is possible by Xamarin’s Visual Studio extension that gets installed when you install Xamarin Studio on a Windows machine. Like a Xamarin.iOS project, Xamarin (whether you use Xamarin Studio or Visual Studio) will still use the Android SDK Tools. These are the same Andriod SDK Tools that Java developers use. They include the Android SDK Manager, DDMS, ADB, and the AVD Manager which is used to create and run your Android Emulators. Again, I want to stress that these are the same standard Android tools that Java developers use, and are not Xamarin tools. Xamarin uses some these tools underneath the hood when you run and debug your apps, so I recommend reading up on them and understanding what they are.
Optional Requirements
The most common way you will probably develop your app is on an Emulator. Xamarin does provide out of the box support for the same Android Emulators that Java developers use. However, as you’ll soon learn, the ARM based Android Emulators (the ones that come out of the box) are notoriously slow….I mean rrreeeaaalllyyy ssslllooowww. No, I’m serious, they are SLOW! I personally find them unbearable to work with. However, you have two alternatives.
First you can use the AVD Manager and create a x86 base emulator using the Intel Harware Accelerated Execution Manager (HAXM). This creates a hypervisor that speeds up Android emulation. So you are actually running an Android VM. The performance is much more bearable and easy to work with. However, the Android Emulator software is somewhat limited and clunky to work with at times.
The second alternative is to download, and register for Genymotion. Genymotion uses Oracl VirutalBox to create an Android virtual machine. The performance of these Android VMs are exceptional. When you sign up for an account, you can download pre-configured VMs of different phone types, screen sizes, and Android OS versions. The software also includes a lot of neat features that make it easy to work with.
One of my favorite Genymotion features is setting the current GPS location of the Emulator. Using the Android AVD, you have to manually enter in the latitude and longitude, after you search for it on Google Maps. But with Genymotion, Google Maps is integrated and all you have to do is pin a location on a Map and it will automatically send the lat/long values to the Android VM. But my favorite feature of Genymotion is that it’s free. They also provide a paid version, but the free version is more than adequate for most development. I highly recommend Genymotion and it is my preferred Android VM to work on.
For more information on how to setup an Android AVD or Genymotion, consult the Xamarian documentation.
Summary
I hope this has given you a more detailed description on how Xamarin.Android is architected and works. As I stated earlier, I feel it is important to know how Xamarin.Android projects are compiled and how Xamarin.Android relates to the Android SDK before you start coding. But here are some key points to remember:
- Xamarin.Android projects use C# via the Mono Framework and Xamarin.Android to create an Android application.
- The Mono Framework is an open source implementation of the .NET Framework that works on Windows and non-Windows platforms.
- Not every .NET class is available in Mono. Only those that are not specific to the Windows operating system.
- Xamarin.Android is a C# bindings (wrapper) to the Android SDK (Java).
- The bindings also includes wrappers that make the Android SDK more “.NET Friendly”.
- Xamarin.Android applications are compiled into IL, and is JITed by the Mono Runtime. The Dalvik Runtime also runs in parallel to execute Android specific code.
- ARM based Android emulators are slow! Use HAXM or Genymotion!
- Test and debug on real devices early, and often. As you’ll learn, your app can behave differently on Android devices than on emulators. Trust me on this.
As always, feel free to contact me, or leave a comment below. Also, if you think your friends or colleagues will find this interesting, feel free to share it with them by using the share options below.