Today we are happy to release Mono for Android 1.0 as well
as MonoTouch
4.0.

Both products allow you to use the C# language to write
applications that run on Android and iOS devices.

Both products are based on the
latest Mono
2.10 core. The Parallel Frameworks can be used to write
more elegant multi-threaded code across all devices, and
automatically takes advantage of multiple cores available on the
iPad2 and Xoom devices. The C# 4.0 is now the default as
well as the .NET 4.0 APIs.

Mono for Android

Our Mono
for Android debuts today after almost a year worth of
development.

Mono for Android can be used from either Visual Studio
Professional 2010 for Windows users, or using MonoDevelop on
the Mac.

Mono code runs side-by-side the Dalvik virtual machine in
the same process:

This is necessary since code running in Dalvik provides the
user interface elements for Android as well as the hosting and
activation features for applications on Android.

APIs

The Mono for Android API is made up of the following
components: Core .NET APIs, Android.* APIs, OpenGL APIs and
Java bridge APIs.

Let us start with the most interesting one: Android.* APIs.
These are basically a 1:1 mapping to the native Java Android
APIs but they have been C#-ified, for example, you will find
C# properties instead of set/get method calls, and you will
use C# events with complete lambda support (with variables
being automatically captured) instead of Java inner classes. This
means that while in Java you would write something like:

In addition to the UI APIs, there are some 57 Android.*
namespaces bound that provide access to various Android
features like telephony, database, device, speech, testing and
many other services.

In what is becoming the standard in the Mono world, OpenGL
is exposed through the
brilliant OpenTK API.
OpenTK is a strongly
typed, Framework
Design Guidelines-abiding binding of OpenGL. The benefit
is that both Visual Studio and MonoDevelop can provide
intellisense hints as you develop for the possible parameters,
values and their meaning without having to look up the
documentation every time.

Finally, for the sake of interoperability with the native
platform, we exposed many types from the Java.* namespaces (31
so far) that you might need if you are interoperating with
third party libraries that might require an instance of one of
those Java.* types (for example, a crypto stack might want you
to provide a Javax.Crypto.Cipher instance. We got you
covered.

Core Differences

Mono for Android has a few differences from MonoTouch and
Windows Phone 7 when it comes to the runtime. Android
supports JIT compilation while iOS blocks it at the kernel
level and Windows Phone 7 has limitations.

This means that developers using Mono on Android have
complete access to System.Reflection.Emit. This in turn
means that generics-heavy code like F# work on Android as do
dynamic
languages powered by the Dynamic Language Runtime like
IronPython, IronRuby
and IronJS.

Now, although those languages can run on Mono for Android,
we do not currently have templates for them. The Ruby and
Python support suffer due to Android limitations. The
Dalvik virtual needs to know in advance which classes you
customize, and since it is not really possible to know this
with a dynamic language, the use of Iron* languages is limited
in that they cant subclass Android classes. But they can
still call into Android APIs and subclass as much .NET class
libraries as they want.

Native User Interfaces

MonoTouch and MonoDroid share a common runtime, a common
set of class libraries, but each provides different user
interface and device specific APIs.

For example, this code takes advantage of iOS's
UINavigationController and animates the transition to a new
state in response to a user action:

We chose to not follow the Java write-once-run-anywhere
approach for user interfaces and instead expose every single
bit of native functionality to C# developers.

We felt that this was necessary since the iOS and Android
programming models are so different. We also wanted to make
sure that everything that is possible to do with the native
APIs on each OS continues to be possible while using Mono.

For instance, if you want to
use CoreAnimation
to drive your user interactions, you should be able to
leverage every single bit of it, without being forced into a
common denominator with Android where nothing similar to this
is available.

To give your code the most broad reach, you should consider
splitting your backend code from your presentation code.
This can be done by putting reusable code in shared libraries
(for example, REST clients) and shared business logic on its
own libraries.

By splitting your presentation code from your business
logic code for your application, not only you gain the ability
to create native experiences in each platform, you also get a
chance to test your business logic/shared libraries more
easily.

Linking

In Mono for Android when you build an application for
distribution, we embed the Mono runtime with your application.
This is necessary so your application is entirely
self-contained and does not take any external dependencies.

Mono for Android uses
the Mono
Linker to ensure that only the bits of Mono that you
actually use end up in your package and that you do not pay a
high tax for just using a handful of functions.

For example, if you want to just use a method from
XElement, you would only pay the price for using this class
and any of its dependencies. But you would not end up
bringing the entire System.XML stack: you only pay for what
you use.

During development a different approach is used: the Mono
runtime is installed on your emulator or test device as a
shared runtime. This minimizes both the build and deploy
times.

Thank You!

Mono for Android would not have been possible without the
hard work of the MonoDroid team at Novell. The team worked
around the clock for almost a year creating this amazing
product.

The team was backed up by the Mono core team that helped us
get C# 4.0 out, WCF, the linker, the LLVM support, improve the VM,
extend the MonoDevelop IDE, scale Mono, improve our
threadpool, support OpenTK, implement the Parallel
Frameworks, ship dozens of betas for MonoDevelop, Mono and
Mono for Android.