Cross-Platform Mobile Development with .NET: It's All Up to Xamarin Now
Krystyna Rosicka-Blonska outlines her recent development experiences in MonoTouch and Mono for Android and points to a few shortcomings that Miguel de Icaza and his development team might want to address in the planned commercial .NET offerings from Xamarin.
Just last month I was tasked with evaluating the feasibility of cross-platform mobile development with commercial .NET tooling from Novell: MonoTouch for iOS and Mono for Android, which were built around the open source .NET framework Mono. The future looked bright for Mono, despite uncertainties caused by Attachmate's pending acquisition of Novell. MonoTouch 4.0 and Mono for Android 1.0 had just been released and Apple CEO Steve Jobs demoed a MonoTouch-built iPad2 app called Virtual History Roma during the iPad 2 launch event.
The evaluation process required a proof-of-concept application, with as much portable code as possible, running on iPhone, Android and Windows Phone 7. The demo app needed to replicate the functionality of a mobile Web site built for one of our clients. Creating a common data repository for all platforms; evaluating the pros and cons of one approach versus another; and finding the golden mean were the initial challenges.
The .NET Framework offers many ways of exposing services and accessing them on the client-side. The Mono frameworks supported ASP.NET Services, REST and some Windows Communication Foundation (WCF). However, WCF Web API, Async CTP and Reactive Extensions were not supported.
In addition, you can always count on subtle differences that will make the source code not portable between three platforms. As a result the details of implementation became as challenging as the design.
After a few, really frustrating, unsuccessful attempts I settled for Silverlight 4 generated proxies to access WCF services exposed via Basic Http Binding. I started by creating a Silverlight library for a Windows Phone 7 project to host the data repository code.
Next, without leaving Visual Studio, I moved to testing the library in the Mono for Android project. That did not work. Mono for Android turned out to still be an immature environment and refused to compile while referencing the Mono for Android class library. In the end, I created a Data Repository folder inside each platform-specific project.
The Windows Phone 7 application and its Android counterpart were running with acceptable success. I moved on to the iPhone project on a Mac and successfully created the navigation-based app requesting data via data repository classes created for the Windows Phone 7 app.
I planned for and achieved source code level reuse by using Visual Studio 2010 “Add as Link” functionality to reference the same physical files from projects targeting different platforms. My data repository design borrowed from concepts discussed in "6 Tips of Separation," (Visual Studio Magazine, April 2011) authored by Benjamin Day.
The User Interface Layer passed callback methods that made use of the data brought from asynchronous service calls. The user was authenticated and the resulting authentication cookie was used in subsequent calls to the repository with requests for business data. Both the authentication and the data services were hosted in the mobile Web application and the same code was used for accessing the site via browsers or mobile devices.
Mono at a Crossroads
A few weeks later, the next logical step was to pay the dues to Apple ($299 for iOS Developer Enterprise Program) and Attachmate ($999 for MonoTouch Enterprise Edition), the new owner of Novell, for the ability to run the application on iPhone. Then the rumors surfaced about massive layoffs of developers working on the Mono projects at Attachmate. My company's immediate reaction was to stop the cross-platform mobile development effort and wait for an official statement from Attachmate
or Mono creator Miguel de Icaza
. It took two more weeks to learn that de Icaza had left Attachmate and formed a new company named Xamarin
The Xamarin project will focus on building new commercial .NET offerings for iOS and Android. Miguel de Icaza, and his former Mono developers, many of whom now work for Xamarin, will continue to contribute, maintain and develop the open source .NET framework and its open source Silverlight sibling Moonlight. Source compatibility with MonoTouch and Mono for Android and exploration of Moonlight opportunities in the mobile space are top objectives, according to de Icaza.
The news about Xamarin's formation is a huge relief to the cross-platform mobile development community. In keeping with "the King is dead" and now "long live the King," I would like to point out a few shortcomings in MonoTouch and Mono for Android based on my recent experiences, in hopes of seeing improvements in the new commercial .NET offerings from Xamarin.
One frustration in working with MonoTouch was using MonoDevelop as an Integrated Development Environment (IDE) in place of the more powerful and stable Visual Studio 2010. While MonoDevelop is a mature IDE, it lacks solid integration with a source control system. The built-in SVN integration leaves a lot to be desired. Similarly, Visual Studio productivity tools and third-party extensions do not integrate with MonoDevelop.
I found a way to circumvent some of these deficiencies by putting the MonoTouch project files on a Windows network share and using the MonoTouch to Visual Studio Converter to switch between both IDEs.
I installed Mono for Android and worked on both Android and Windows Phone 7 projects at the same time to quickly resolve incompatibilities between the .NET and Mono APIs. I could compile and build both projects without leaving Visual Studio; and common components developed that way worked in iOS projects. I achieved source code level reuse for all three platforms by using Visual Studio 2010 Add as Link functionality to reference Windows Phone 7 project physical files from projects targeting iOS and Android platforms.
Dealing with the lack of full implementation of a few .NET APIs, especially in services related stacks in Mono, was another frustrating experience. After a few unsuccessful attempts, I had to settle for Silverlight 4 generated proxies to access WCF services exposed via Basic Http Binding. That seemed to work for the POC application, but I have seen enough warnings about HTTPS not working correctly with the WCF Mono stack to be concerned about the production readiness of this implementation.
I also noticed during my explorations that Mono for Android 1.0 is a tool still lacking maturity. The Android Emulator was very slow to start and run; and debugging was not working most of the time.
Wish List for the Xamarin Project
You can use Xamarin’s Sign Up form
to receive information about the planned commercial products and to tell Xamarin's developers what features and improvements you'd like to see in the Mono applications.
In my view, the Xamarin project should make Visual Studio a target IDE, as important as MonoDevelop, for its commercial iOS development offering. Taking that approach would allow .NET developers to use Team Foundation Server and Visual Studio Extensions. The ability to run iOS builds (with Mac still required, of course) from Visual Studio would be even better.
Another item on my wish list for the Xamarin team is to bring Mono services APIs to full compatibility with .NET 4 and to update Mono documentation to make navigating APIs less trying.
A top priority for the commercial Android offering is to improve the Android Emulator and make debugging faster, and work more consistently. During my test project, I could not get the emulator to run successfully.
The final item on my wish list, which may not be that realistic, is to support running Windows Phone 7 and Silverlight XAML on iOS.
One thing is certain: Making the decision on how to proceed, whether to move forward with a cross-platform mobile development effort with Mono, or switch gears and follow native paths with some help from Microsoft (Windows Azure Toolkit for WP7, iPhone and, this summer, Android) or go quasi-native with HTML5, is not going to be easy. Based on recent developments, there's reason to hope that Xamarin will extend Mono's capabilities for building cross-platform mobile apps.