Xamarin - Documentation

Android

change platform
  1. Xamarin
  2. Android
  3. Getting Started
  4. Introduction to Mono for Android

Introduction to Mono for Android

Getting Started - 1

BRIEF

This article is the first in a series of getting started with Mono for Android articles, and introduces the Mono for Android platform. It is the first step in learning how to build Mono for Android applications and covers the fundamental concepts of what the platform is, what it can do, as well as general information on building for Android.

This article is intended for those who are brand new to Android and/or the Mono for Android platform, but who have at least a basic familiarity with C# and .NET programming.

Time to Complete:

30 Minutes

Related Articles:

Installing Mono for Android
Create An Android Project
Hello, Android; A First Application

Overview

When considering how to build Android applications, many people think that Java is the only choice. However, over the past few years, an entire new ecosystem of platforms for building Android applications has emerged. These new solutions include Mono for Android, AppCelerator, PhoneGap, etc., just to name a few.

Each of these platforms has a different feature set and each varies in its ability to write native applications – that is, applications that compile down to native code and that interop fluently with the underlying Java subsystem. For example, some platforms only allow you to build apps in HTML and JavaScript (such as AppCelerator), whereas some are very low-level and only allow C/C++ code. Some platforms (such as Flash) don’t even utilize the native control toolkit.

Mono for Android is unique in that it combines all of the power of Java and adds a number of powerful features of its own, including:

  • Complete Binding for Android Java API – Mono for Android contains bindings for nearly the entire ADK. Additionally, these bindings are strongly-typed, which means that they’re easy to navigate and use, and provide robust compile-time type checking and autocomplete during development. This leads to fewer runtime errors and higher quality applications.
  • Java and C/C++ Interop – Mono for Android provides facilities for directly invoking Java, C, and C++ libraries, giving you the power to use a wide array of 3rd party code that has already been created. This lets you take advantage of existing Android libraries written in Java or C/C++.
  • Modern Language Constructs – Mono for Android applications are written in C#, a modern language that includes significant improvements over Java such as Dynamic Language Features, Functional Constructs such as Lambdas, LINQ, Parallel Programming features, sophisticated Generics, and more.
  • .NET Base Class Library (BCL) – Mono for Android applications uses the .NET BCL, a massive collection of classes that have comprehensive and streamlined features such as powerful XML, Database, Serialization, IO, String, and Networking support, just to name a few. Additionally, existing C# code can be compiled against Mono for Android for use in your applications, which provides access to thousands upon thousands of libraries that will let you do things that aren’t already covered in the BCL.
  • Modern Integrated Development Environment (IDE) – Mono for Android uses MonoDevelop on Mac OSX, and also MonoDevelop or Visual Studio 2010 on Windows. These are both modern IDE’s that include features such as code auto completion, a sophisticated Project and Solution management system, a comprehensive project template library, integrated source control, and many others.
  • Mobile Cross Platform Support – Mono for Android is a sibling to MonoTouch, which allows C# applications to be written for the Android platform. MonoTouch and Mono for Android allow iOS and Android applications to be written that share common backend application code. Additionally, because both Mono for Android and MonoTouch utilize C# and the .NET BCL, the same application code can be shared with Windows Mobile 7 applications as well! This can significantly reduce both development costs and time to market for mobile developers that target the three most popular mobile platforms.

Because of Mono for Android’s powerful and comprehensive feature set, it fills a void for application developers that want to use a modern language and platform to develop cross-platform mobile applications.

Let’s dig into Mono for Android a bit to examine how it works.

How Does Mono for Android Work?

Mono for Android is a commercial product built on top of Mono, which is an open-source version of the .NET Framework based on the published .NET ECMA standards. Mono has been around nearly as long as the .NET framework itself, and runs on nearly every imaginable platform including Linux, UNIX, FreeBSD, Mac OSX, and others.

Mono for Android was originally created by Novell and released in 2011; however, just after its release, most of the Mono (and Mono for Android) team formed a new company (Xamarin) as part of Novell’s restructuring. Novell then granted Xamarin a perpetual license to all things Mono and handed the Mono for Android reins over to Xamarin, who supports and continues to develop new Mono for Android releases.

Mono for Android allows you to use C# and the .NET Base Class Library (BCL) to write native Android applications. This is accomplished by executing applications in an instance of the Mono runtime VM, which co-exists on devices along with Google’s Dalvik VM. When a Mono for Android application is built, three main steps occur:

  • Resource Generation – As a pre-build step, aresgen.exe is run against a Resources directory in order to generate a Resources.designer.cs file containing Android resource identifiers. These resource identifiers are a key piece of Android applications and are used to locate images, UI files, strings, etc.
  • Compilation – C# code is compiled into a Managed .NET/Mono assembly.
  • Android Wrapper Creation – The mandroid.exe tool is run against the .NET assembly to generate Android-callable wrappers and generate an Android package.

Mono.Android.dll

Mono for Android application’s are built against a subset of the .NET BCL known as the Mono for Android Profile. This profile has been created specifically for Android and packaged in Mono.Android.dll. This is much like the way Silverlight (and Moonlight) applications are built against the Silverlight/Moonlight .NET Profile. In fact, the Mono for Android profile is equivalent to the Silverlight 4.0 profile with a bunch of BCL classes added back in.

For a full list of available assemblies and classes, see the Mono for Android Assembly List.

In addition to the BCL, Mono.Android.dll includes wrappers for nearly the entire Android Development Kit. This allows you to invoke ADK APIs directly from C#.

Note: Mono for Android applications are compiled against the Mono for Android profile, just like Silverlight/Moonlight apps are compiled against theirs. This means that you will have to recompile off-the-shelf .NET assemblies and your C# source against the Mono for Android profile.

Requirements

All the tutorials presented here are based on the latest Mono for Android and Visual Studio 2010 or MonoDevelop. Installation is covered in the next tutorial.

Additionally, if you want to deploy to a device, rather than just the Android Emulator, you’ll need a non-evaluation version of Mono for Android, which can be purchased at the Xamarin Store.

App Stores

Unlike other popular mobile platforms, Android takes a very open approach to app distribution. Devices are not locked to a single, approved app store. Instead, anyone is free to create an app store, and most Android phones allow apps to be installed from these third party stores.

This allows developers a potentially larger yet more complex distribution channel for their applications. The Android Marketplace is Google’s official app store, but there are many others. A few popular ones are listed below:

Developing for Android

Like other mobile platforms, developing applications for Android differs significantly from developing traditional desktop applications. Mono for Android goes a long way toward bridging some of the gaps, but the reality is that Android applications have a unique architecture as a result of the fundamental design of the Android OS, and therefore have some very specific requirements and limitations. Let’s examine some of these now.

Multitasking

There are two significant challenges to multitasking (having multiple applications running at once) on a mobile device. First, given the limited screen real estate, it is difficult to display multiple applications simultaneously. Therefore, in Android, only one application is in the foreground at any one time. Second, having multiple applications open and performing tasks can quickly eat battery power.

Because of this, Android has a very specific screen (activity) lifecycle framework that applications must adhere to in order to create responsive, well-behaved applications. For more information, see the Activity Lifecycle guide.

Many Devices + Many Form Factors

Unlike iOS, which has a small set of devices, or even Windows Mobile 7, which only runs on approved devices that meet a minimum set of platform requirements, Google doesn’t impose any limits on which devices can run the Android OS. This open paradigm results in a product environment populated by a myriad of different devices with very different hardware, screen resolutions and ratios, device features, and capabilities.

Because of this, it’s important to take into account different devices throughout the entire software development lifecycle:

  • Conceptualization and Planning – Because different devices can have different hardware and device features, you must keep in mind that an application that relies on certain features may not work properly on certain devices. For example, not all Android devices have cameras, so if you’re building a video messaging application, some devices may be able to play videos, but not take them.
  • Design – When designing an application’s User Experience (UX), different screen ratios and sizes should be kept in mind. Additionally, when designing an application’s User Interface (UI), different screen resolutions should be considered, and assets should be created for low, medium, high, and extra-high density devices. For more information, see Supporting Multiple Screens in the Android Documentation.
  • Development – When using a feature from code, the presence of that feature should always be tested first. For example, before using a device feature, such as a camera, always query the OS for the presence of that feature first. Then, when initializing the feature/device, make sure to request currently supported configurations from the OS about that device and then use those configuration settings.
  • Testing – It’s incredibly important to test your application early and often on actual devices. Even devices with the same hardware specs can vary widely in their behavior.

Limited Resources

Mobile devices running the Android OS get more and more powerful all the time, but they are still mobile devices that have limited capabilities in comparison to desktop or notebook computers. For instance, desktop developers generally don’t worry about memory capacities; they’re used to having both physical and virtual memory in copious quantities, whereas in Android you can quickly consume all available memory just by loading a handful of high-quality pictures.

Additionally, processor-intensive applications such as games or text recognition can really tax the mobile CPU and adversely affect device performance.

Because of considerations like these, it’s important to code smartly and to deploy early and often to actual devices in order to validate responsiveness.

Security Considerations

Applications in the Android OS all run under a distinct, isolated identity with limited permissions. By default, applications can do very little. For example, without special permissions, an application cannot send a text message, determine the phone state, or even access the Internet! In order to access these features, applications must specify in their application manifest file which permissions they would like, and when they’re being installed; the OS reads those permissions, notifies the user that the application is requesting those permissions, and then allows the user to continue or cancel the installation. This is an essential step in the Android distribution model, because of the open application store model, since applications are not curated the way they are for the iOS, for instance. For a list of application permissions, see the Manifest Permissions reference article in the Android Documentation.

x86 Emulator

Desktop and laptop computers commonly use x86 architecture, whereas mobile devices typically use ARM. Likewise the Android emulator has traditionally only been available for ARM. With the release of the r17 (and above) Android platform tools, an x86 emulator is available for Android API level 10 emulators, offering faster performance. For information on setting up an x86 emulator with Mono for Android see Configuring the x86 Emulator.

Distribution

All Android applications must be signed before being distributed. Developers sign their applications by using their own certificate protected by a private key. This certificate can provide a chain of authenticity that ties an application developer to the applications that developer has built and released. It must be noted that while a development certificate for Android can be signed by a recognized certificate authority, most developers do not opt to utilize these services, and self-sign their certificates. The main purpose for certificates is to differentiate between different developers and applications. Android uses this information to assist with enforcement of delegation of permissions between applications and components running within the Android OS.

Summary

In this tutorial, we got a good background on Mono for Android, including what it is, how it works, and what it can and can’t do. We also examined general considerations for building Android applications, including app design factors and distribution.

In the next tutorial, we’ll run through how to install Mono for Android on your platform of choice.