Monodroid: new perspectives for cross-platform mobile development

Recently, our company needed to port a .NET project on Android and iOS in the future. To save customer’s money, I tried to look for a solution that will reuse already existing code.

Xamarin provides MonoDroid and MonoTouch technologies, which allows you to write applications for Android and iPhone on C#. MonoTouch is already proven technology existing since 2009. MonoDroid is its logical continuation. I closely followed the technology and in the end it came out in April 2011.

Sounds good and exactly what my customer wants, isn’t? Because of the novelty of MonoDroid technology, it is used in only a few applications. For this reason, it is necessary to examine very carefully the pros and cons of this technology. Let's get started.

“+”

  • It is possible to reuse existing .NET code. So, we can also use common class library to cover almost the entire major mobile world: Android (MonoTouch), IPhone (MonoDroid), Windows Phone (Silverlight for Windows Phone), Windows Mobile (.NET Compact Framework), writing own UI-layer for each platform.
  • Almost full Android port, including OpenGL support.
  • No need to install a special runtime on user device. From the user’s point of view, there is no difference (excluding much bigger APK size and short start delay) between an application created in Java and an application created using Mono for Android.
  • Presence of various ported samples from Android SDK
  • It is possible to write code on Visual Studio with the tools that developers are already using.
  • Possible Moonlight support in the future.
  • Another technology, MonoTouch, that allows .NET developers to create applications for iOS, is very popular on mobile development since 2009. MonoDroid is a good addition to MonoTouch which guarantees long life and popularity of MonoDroid in the future.

“-“

  • Very slow debugging. Very often I get the following timed out error message on a breakpoint - “Unable to evaluate the expression. The expression evaluation took too long”. But maybe debugging on real device will be much faster.
  • Big limitations such as impossibility of including external JARs.

    Third party .jar files cannot currently be easily used and extended from managed code. Some JNI support is provided, but subclassing and implementing third party classes and interfaces isn't possible via Android.Runtime.JNIEnv. Support for third party .jar files will be added in a future release.

  • Instability of the product
    1. Sometimes you cannot create the package due to MonoTouch bugs (like this) so you can waste a lot of time to figure such problems out.
    2. Sometimes (2-4 times per day!) wrong detection of available devices causes Visual Studio crash.
    3. Other weird Visual Studio crashes.
  • Big APK file size, but fortunately, the application can be installed on SD-card (example application)
  • Small app start delay
  • There's a currently ~3s startup penalty overhead when first loading the app on a G1 (your mileage will vary depending on hardware). This is due to initializing the Mono runtime and loading up the referenced assemblies. We do want to improve this in the future.

  • Not all .NET features are supported (Moonlight/Silverlight user interface functionality is also not supported yet). Fortunately, LINQ is supported, making it friendly for data-driven applications. List of all supported features is here.
  • Small community, poor support, novelty of technology (MonoDroid was realized in April 2011). It is hard to find a good book (Amazon MonoDroid search result), small number of articles (and almost all the articles are on “hello world” level).
  • Development of common logic libraries for small projects may cause too complex architecture, that will be more expensive than developing of own small application for each platform by professional in concrete platform.
  • There may be a delay with release of new version of MonoDroid in connection with the release of new Android version.
  • Android Market publication policy may be changed at any time by Google and MonoDroid applications may be prohibited, however with current Google policy this is very unlikely to happen.

Summary

From these lists we can conclude that Monodroid can give big advantage for cross-platform mobile application development using another friendly technology - MonoTouch. To be able to use these technologies effectively, a good separation of UI layer from business logic and data access layers is needed. To accomplish that, we can suggest you to use MonoCross framework. MonoCross is based on modified MVC pattern and provides solution design where Model and Controller are shared between application and View is implemented for each target platform. It contains container project templates for MonoTouch, MonoDroid, Windows Phone and Mobile WebKit platforms.

If you do not have strong reasons to start cross-platform development, Monodroid has almost no benefits over Java development on Android. Rather, we should not recommend it to use for this purpose because it has some limitations such us inability of including external JARs to your project and additional APK file size.

Helpful links

1. Download trial, samples.
2. Documentation for android, get started section.
3. Xamarin Android FAQ
4. Limitations of MonoDroid and MonoTouch.
5. .NET feature support list.
6. List of MonoTouch/MonoDroid apps on AppStore and Market
7. MonoCross Wiki
8. MonoCross - The Technology
9. Tweet search – an example of cross platform mobile application

Comments

Re:Monodroid: new perspectives for cross-platform mobile develop

Hi

Its always nice to read your blog. The articles of your blog is actually price reading. It seems to be amazing if i also come to read the shares about Mobile Application Development, Web applications.

Kind Regards:
Amy Patrix
amy.patrix@xicom.biz