Talking Mono for Android

I posed a few questions to Wallace "Wally" McClure, a partner at Scalable Development, Inc. and author of three books related to Mono-based development (including the upcoming Professional Android Programming with MonoDroid and .NET/C#, expected in July). He's also written about MonoDroid development for Visual Studio Magazine (Introduction to MonoDroid and Building a MonoDroid App). Here's what he had to say.

Michael Desmond: What noticeable or meaningful improvements can developers expect in the 1.0 release?
Wally McClure: I've watched the Mono for Android product evolve since the first preview bits in August 2010. It's been great to watch the problems slide away. I think the biggest improvement from the last few weeks are:

First, the API is considered to be fairly solid. Assuming that you write to the defined API, your mobile application should upgrade [fairly easily] as the Mono team roles out new versions.

Second, you can deploy apps to the app store. While we all like to play with pre-release products, it's hard to go that final step and deploy applications to end users based on a product that has the terms beta or "pre-release" associated with them. By removing this, it says that the Mono team feels confident that you can deploy an application to end users without the fear that your application will fail based on something in the Mono framework.

MD: What are your thoughts on what the Mono folks have delivered with MonoDroid 1.0? What might a .NET developer new to MonoDroid expect from the tooling and what limitations might they encounter?
WM: I think that the 1.0 release is a good foundation. It has support for .NET 4, which developers are using. It has support for Web services, databases, android services, and many of the features that developers will expect.

Building a user interface in Android requires patience, and Notepad, until recently. Google has started to address this in their tools, and developers have always been able to use a tool like DroidDraw for defining their user interfaces, due to the xml format of Android user interface files. One of the surprising features in Mono for Android is the IntelliSense [support] for building a user interface within Visual Studio.

When you deal with Microsoft on an issue with their development tools, due to their size and widespread acceptance in the marketplace, they are under tremendous pressure to make sure that any changes, such as service packs, are only sent out at defined times. This can mean a long wait for a fix, but the Mono team can get updates out in a much quicker timeframe.

For example, with the Mono for Android 1.0 release that shipped this week, there was a problem in my voice recognition and driving direction app. This application worked perfectly in the final preview two weeks ago. Joe Hill from Novell emailed me about a small update on Wednesday evening. I installed it and my voice recognition and driving direction application worked properly again.

What I am getting at is that the Mono team is able to address issues quickly and get those fixes out to the marketplace. This has happened with MonoTouch and I suspect that this will happen with Mono for Android as well.

This biggest limitation that I have found is that the Android emulator is definitely wanting. This is something outside the control of the Mono team. I wrote a pair of blog posts on how to get around this: Android Emulator - Increasing Performance Suggestions for MonoDroid and The Android Emulator Keyboard

MD: Any thoughts on the Visual Studio integration and how effective it is?
WM:I think the Visual Studio integration is a good first step. It allows Mono for Android to fit into the Visual Studio ecosystem easily. Overall, I have found it to work very well. I am able to write an Android application and run it in the emulator or on a device and see what is happening fairly easily. The only plug-in that I use is SVN and Mono for Android integrates with it perfectly. Other people in the mailing list are reporting that Visual Studio plug-ins work properly.

Admittedly, the Mono for Android debugging integration is problematic in the 1.0 release. Many users, myself included, are reporting poor performance and numerous timeouts in Visual Studio debugging. I fixed this when I got an update to my four-year-old development system. I suspect that the debugging will improve shortly similar to how MonoTouch initially shipped with no debugging support, and about six weeks afterwards the Mono team shipped an update with debugging support.

MD: What stands out as a key flaw or missing feature of the new release?
WM:I think the biggest missing feature at this point in time is the lack of a visual designer. Most developers are familiar with the concepts and greatly depend on them. A design surface allows a developer to get up to speed quickly. But a design surface is not perfect, and many advanced developers don't use them. The beginning developer can work around this by using DroidDraw to get up to speed. It's not an "in the box" solution, but it's a solution none the less. I used DroidDraw when I started with Mono for Android last summer in this exact scenario.

Posted by Michael Desmond on 04/07/2011