The following is reprinted with permission. For more on this topic, check out Professional Android Programming with Mono for Android and .NET/C# by Wallace McClure, et al.
Introduction to Mono for Android
What’s in This Chapter?
- Introduction to Mono and Mono for Android
- Configuring the development environment
- Mono for Android tools for Visual Studio
- Debugging and deploying
What is Mono for Android? This chapter provides the basis for Mono for Android development. It starts with an overview of Mono and then moves to a discussion of Mono for Android, configuring the development stack, and developing and deploying a “Hello Mono for Android” application — first to an emulator and then to your Android-based phone.
Before getting started with development, you need to learn about a number of items that will help you understand the development environment and the tools that are involved. This section covers what Mono is and how it is implemented. Then it discusses what Mono for Android is, along with its benefits and implementation. Finally, this section discusses the development stack before moving on to development.
What Is Mono?
Mono is an open source project sponsored by Xamarin to create an Ecma standard implementation of the .NET common language infrastructure (CLI), a C# compiler, and an open development stack. The Mono project was started by Ximian in 2001, and version 1.0 was released in 2004.
Mono Implementation Goals
The Mono implementation is currently targeting three goals:
- An open source CLI
- A C# compiler
- An open development stack
The CLI provides the runtime environment for languages that have been compiled to the Common Intermediate Language (CIL). The C# compiler is responsible for compiling C# code to CIL for execution on the runtime. The open development stack facilitates development and includes an IDE in MonoDevelop and several libraries beyond the core libraries to provide open cross-platform development. These libraries include GTK# for graphical user interface development, POSIX libraries for UNIX/Linux compatibility, Gecko libraries, database connectivity libraries, and XML schema language support via RELAX NG.
Mono adheres to the Ecma Standard. Ecma International was formed in 1961 to support the standardization of information and communication technology. In 2005, Ecma approved version 3 of C# and CLI as updates to Ecma 334 and 335. Currently, a working draft of the Ecma 335 CLI is in progress.
The Mono C# compiler is currently feature-complete per the Ecma standards for C# versions 1, 2, and 3 in version 2.6. Version 2.6 also includes a preview of C# 4, with a feature-complete version of C# 4 available in the trunk of version 2.8.
What Is Mono for Android?
Mono for Android is a runtime and development stack that allows .NET developers to leverage their knowledge of Visual Studio and C# to develop applications for Android-based devices.
- Runtime: The Mono for Android runtime is an application that runs on the Linux kernel in the Android stack. It interprets the Mono byte code and handles communication with the Dalvik runtime for calls to native Android APIs.
- Development stack: Mono for Android is also a development stack, providing the tools necessary to create and package applications for Android devices.
Why Do I Need Mono for Android?
Given that the Android platform has an open development stack based on Java with Eclipse as a visual development environment, it would be reasonable to ask why you need Mono for Android. A .NET developer who uses Visual Studio has three main reasons: a familiar development environment, familiar APIs, and, as a result, rapid start-up.
Familiar Development Environment
As every developer knows, learning a new development stack is time-consuming and can be painful. Mono for Android allows the .NET developer to stick with the two core tools of .NET development: Visual Studio and C#.
- Visual Studio: Visual Studio is an excellent and robust IDE geared toward .NET. By using the Mono for Android tools for Visual Studio, you won’t have to change your IDE or the settings you like.
- C#: Some .NET developers work only with Visual Basic .NET, but most .NET developers are familiar with C#. Although C# and Java are similar in structure, many differences in the idioms of each language make for fluent writing. And although proficient C# developers would not have to spend extensive amounts of time learning the Java idioms, they would not have to spend any time if they could stick with a language they already knew.
Familiar API and Library Structure
Staying within the .NET world allows you to work with a familiar API and library structure. Table 2.1 shows the assemblies that are a part of Mono for Android 4.0.1.
So, with your favorite development environment to leverage as well as familiar APIs, you will have a rapid start-up for Android development.
What Are the Trade-Offs of Working with Mono for Android?
When you decide not to work with a native API and development stack, trade-offs will be necessary. They need to be weighed against the advantages of working with a more comfortable, but abstract, layer.
Waiting for Improvements
Although moving away from the native Java and Eclipse in favor of Visual Studio has the benefits just mentioned, it also has some downsides. The first is that you generally have to wait for the latest improvements. That is, usually as soon as a new feature or performance enhancement is available in the Android SDK, you have to wait for the next release of Mono for Android for it to be available.
Taking a Potential Performance Hit
The second trade-off is performance. The Mono for Android runtime has to communicate with the Dalvik runtime to get a number of things done. This overhead, however, generally is minor and is more than offset by the benefits mentioned previously.
After you install the Mono for Android tools for Visual Studio, starting a new Mono for Android project is as easy as selecting File ⇒ New ⇒ Project ⇒ C# ⇒ Mono for Android. We will cover this in more detail next.
Many of the objects that are allocated by Mono for Android are wrappers for the Java objects they represent. So what happens is this: Every time you allocate a type which is wrapping a corresponding Java type, two objects are created:
Mono for Android does some work to ensure that both objects stay alive as long as one is referencing the other. That is, as long as the Mono garbage collector (GC) refers to an object, the Java-side object will be kept alive and vice versa. This is accomplished by the proxy objects that are created by the mandroid.exe tool at build time.
However, the GCs are by nature lazy, only performing a collection on demand and not simply when objects go out of scope. So that means that cross-VM garbage will stick around longer than average, and this is unavoidable.
So, when allocating a large number of objects for temporary use, it is worthwhile to explicitly dispose of those objects. A convenient approach to this is to use a using block with a new object, as this will implicitly dispose of the new object that is the target of the using clause, and thereby dispose of the Mono-side wrapper, which will allow the Java-VM to collect the object, preventing too many temporary objects from sticking around for too long.