It's now time to take a deeper dive into Xamarin.Android to see how it pulls off the same magic as Xamarin.iOS. In this chapter, we will see that Xamarin.iOS and Xamarin.Android share many of the same design goals. However, Xamarin.Android does not rely on static compilation. Many of the goals are achieved through completely different methods. This chapter covers the following topics:
- Mono CLR and Dalvik VM—working side by side
- Application packaging
- Mono assemblies
- Xamarin.Android bindings
- Attributes for the
ApplicationManifest.xmlfile - Garbage collection
Android apps run within the Dalvik Virtual Machine (Dalvik VM), which is somewhat similar to a Java VM, but optimized for devices with limited resources. As we discussed in Chapter 1, Xamarin and Mono – a Pathway to the Unnatural, Xamarin products are based on the Mono platform that has its own VM called the Common Language Runtime (CLR). The key question to ask here is, "In which environment does a Xamarin.Android app run?" The answer is both. If you take a look at the next diagram, you will see for yourself how these two runtimes coexist:
Both environments seem quite different from each other, so how does an app run in both? Xamarin.Android's power is achieved through a concept called peer objects and a Java framework called Java Native Interface (JNI).
Let's start with JNI. This is a framework that allows non-Java code with languages such as C++ or C#, as an example, to call or be called by Java code running inside a JVM. As you can see from the previous diagram, JNI is a critical component in the overall Xamarin.Android architecture.
Tip
You can find some supporting information on JNI, particularly on peer objects, in Chapter 2, Xamarin.Android Architecture in Packt Publishing's Xamarin Mobile Application Development for Android, Mark Reynolds.
Peer objects are a pair of objects that work together to carry out the functionality of an Android app. One of these is a managed object residing in the Mono CLR, while the other is a Java object residing in the Dalvik VM.
Xamarin.Android is delivered with a set of assemblies called the Android binding libraries. Classes in the Android binding libraries correspond to the Java classes in the Android application framework, and the methods on the binding classes act as wrappers, to call corresponding methods on Java classes. These binding classes are commonly known as Managed Callable Wrappers (MCW). Because whenever you create a C# class that inherits from one of these binding classes, a corresponding Java proxy class is generated at build time. The Java proxy contains a generated override for each overridden method in your C# class and acts as a wrapper to call the corresponding method on the C# class.
Peer objects can be created from within the Dalvik VM by the Android application framework or from within the Mono CLR by the code you write in the overridden methods. A reference between the two peer objects is kept by each instance of a MCW and can be accessed through the Android.Runtime.IJavaObject.Handle property.
You can see for yourself how peer objects collaborate together here:
