MonoDroid v MonoTouch : a comparison

The past few days I've posted MonoDroid and MonoTouch apps for Monospace - and while they aren't perfect examples of the sort of code-sharing and efficiency that's possible with Mono I thought it would be interesting to compare them as the functionality they offer is very similar.

First, these are the high-level code metrics (as calculated by Visual Studio):

Unfortunately I didn't align the namespaces very well. Here's the explanation:

Total lines of code (TLOC)
Mono-for-Android: 802 lines
MonoTouch: 1,420 lines (2,033 - 613 in SQLite)
At first glance, the MonoDroid app 'wins' with just half the code of the MonoTouch version. I've ignored the SQLite library and the MonoTouch.Dialog framework as they aren't "user code", and any non-.cs files (eg XML markup).

Common code
Although difficult to 'see' because I've rushed these codebases into the public domain, there is a bit of 'code re-use' in these apps (ie. it was only written once, and the c# shared across both platforms using the power of Mono :)
ConfXml == MIX10Xml == approx 200 lines of business objects (DTOs mainly) that match the serialized conf.xml format that is the shared data structure for both platforms.

The ConceptDevelopment.Kelvin code is also shared (different sizes in each aren't relevant for now).

Removing the common code from the comparison results in these totals:
Mono-for-Android: 575 lines (802-199-28)
MonoTouch: 1,145 lines (1,420-178-97)

"Re-used" code
Mono-for-Android's Main.cs::DeserializeConferenceFile, LoadWhatsOn and MonoTouch's AppDelegate.cs::FinishedLaunching both contain "very similar" code in the form of the conf.xml deserializer and parser. In MonoTouch it's 70 lines and in MonoDroid it's 307 lines. The MonoTouch version is heavily assisted by the Linq/MonoTouch.Dialog code in HomeController (another 150 lines or so) which explains part of the difference... but what is shared is the deserialization logic and a number of Linq statements that help parse it for display. These would be harded to shift into a common library due to the dependency on MonoTouch.Dialog - but there was definitely an efficiency gain by having the code already written and tested on one platform before porting to the other. I'll adjust both by the same 'average' LOC count to try and reflect the 'copy/paste but modify' efficiency gain.

Mono-for-Android: 375 lines (575-200)
MonoTouch: 945 lines (1,145-200)

Feature parity
Adjust the MonoTouch solution to allow for the fact that it implements the Map feature that is not available on MonoDroid - 118 lines of code across a few classes.
MonoTouch: 827 lines (945-118)

What's left?
Once we've removed the libraries, the shared data structure, common code and allowed for some "copy/paste re-use", what's left to differentiate the two codebases? Basically just the UI and the code that binds our DTOs to it.

	Mono-for-Android	MonoTouch (iOS)
Code	375 lines	827 lines
'markup'	14 AXML	1 XIB
Views	7 Activities	9 ViewControllers
DataSources	6 Adapters	5 TableViewSource

Some notes on the difference:

• There are 350 lines of AXML to define the layouts used in MonoDroid - the equivalent task in MonoTouch is done mostly in C#, significantly contributing to the LOC difference. I could have implemented a lot of that MonoTouch layout in XIBs using InterfaceBuilder - I just don't like doing it that way.
• The UITabBarController takes more code to setup than
  OnCreateOptionsMenu.
• The iOS SQLite implementation of saving Favorites is more verbose than the XML-serialized-file solution used on Android.
• The MonoTouch source is almost 2 years old, and in some places isn't as succinct as it could be.

Conclusion
So is MonoTouch instrinsically more verbose than MonoDroid? I don't think so - it depends greatly on your preference for constructing your Views (XIBs or in-code). The more important question: does building with Mono* make it easier to port your app to other mobile platforms... and the answer is YES! In future this code might get tidied up into a good example of a cross-platform app... in that case I'll re-examine the stats to make an even better case.

Look at it this way: the iOS app took 1,400 lines of code (it was written first). For an additional 375 LOC (plus some layout XML) we got an Android port - almost for free!

Thankfully it sounds like Xamarin Studio is coming along nicely.

MonoTouch for Monospace II

Further to the MonoDroid version, I've just submitted an iOS version of the Monospace 2011 conference app to Apple (fingers crossed it gets approved, and in time for the conference!).

Here's how it looks:

Even if it doesn't get approved in time, the code is open-source and can be found at github.com/conceptdev/Monospace11. It is based on the original Monospace09, PDC09 and MIX10 apps. A couple of guys helped out with the MIX10 version: @migueldeicaza, @kangamono and @chrisntr. I know Miguel in particular was keen for this code to be open-sourced... I think (?) it was one of the first outings of his awesome MonoTouch.Dialog library. I'd like to thank them again for their help (and to note that any remaining bugs or problems are mine). Also note: there is some old code in there (like, almost 2 years)... it scares me a little to put it up on Github, so please, be gentle.

I'll update with an AppStore link if/when Apple is done; but for now just enjoy the code :)

See you at Monospace!

MonoTouch/MonoDroid and Xamarin - what now?

If you are in the mono community then you'd have to be living under a rock not to have read that Novell was purchased by Attachmate then (first) heard the rumors that Attachmate Lets US Mono Developers Go and (second) seen Miguel's confirmation/announcement of the creation of Xamarin.

What I think this means is:

• Mono should be fine. It has always been open-source (see github.com/mono) and receives contributions from a variety or people regardless of who they work for.
• The MonoTouch and Mono for Android (aka MonoDroid) products published by Novell will effectively stop being supported "as of now". This is based on the fact that none of the devs work there any more.
• Attachmate hasn't announced any plans for those products - even whether they'll continue to be available for sale (along with the associated activation servers). It's impossible to predict what will happen here... various people are trying to get answers from Novell/Attachmate. Personally, even if Attachmate attempted to continue selling/supporting the products I would choose not to be their customer as soon as alternatives are available.
• Miguel and the team who built MonoTouch and MonoDroid have publicly announced they're working on comparable/compatible products to be sold by Xamarin (their new company). These new products are 3-4 months away, betas first prior to a real release. They've done it before, they can do it again!

Lots of people (myself included) have invested plenty of time and money purchasing, learning and using MonoTouch and MonoDroid. I even helped write a MonoTouch book (and some guys have been busy with a MonoDroid one too). We are all collectively upset, disappointed and angry (imagine how the devs themselves feel).

All of this uncertainty has provoked a number of reactions, among them suggestions that all the work done on MonoTouch/MonoDroid projects to-date has been wasted or that people should start learning the native SDKs for iOS and Android instead of committing to the Mono alternatives.

Learning the native SDKs has always been an option for anyone interested in mobile dev, but who wants to go to all that effort!? The value proposition for Mono* remains: .NET developers can leverage their existing language and framework knowledge AND code can be written once and re-used across three platforms (iOS, Android and Windows Phone). Those advantages continue to be true - the two products are definitely useable right now (MonoTouch obviously more mature than MonoDroid) - and if you care to take Miguel at his word they have a 'compatible' future. So what to do in the next 3 or 4 months...

I already have a MonoTouch/MonoDroid app written and published (or almost published)
Keep going! If everything is working for you right now, why change? In future you "might" need to port your work to native IF Xamarin's products are late/don't work. But if you start porting now and spend three months doing the conversion and Xamarin succeeds then you'll have wasted a lot of effort! What's more, your existing codebase will form an excellent 'regression test' for the Xamarin previews/betas... make sure you sign up at xamarin.com and participate! Your knowledge and experience with the existing products will be very helpful testing the new bits.

If you are really pessimistic you can still continue on this path - but maybe allocate some of your dev time learning the native SDKs and possibly prototype/porting some of your code. Don't do all of it - just get comfortable with the fact that it's possible while waiting to see how Xamarin develops.

I have purchased MonoTouch/MonoDroid and was planning to use them in future
Why not give them a try anyway? There are multiple benefits of using Mono*, including learning the native SDK APIs from the comfort of a language you know and also being productive more quickly. Think of it like prototyping - you get something working quickly and along the way learn a lot that can be re-used (you WILL learn the iOS/Android APIs).

If your app is single-platform I can imagine this decision might be a close call (and perhaps you should just learn Objective-C or Java) BUT if you are planning a cross-platform solution then you are still going to save time and effort with Mono* and code-sharing. One obvious risk would be the possibility of hitting something that isn't supported/doesn't work in Mono* yet - so do your research.

On the other hand, imagine spending the next few months learning BOTH Objective-C and Java, and producing two incompatible codebases for your app, only to discover that Xamarin rocks!

I'm a consultant and I've recommended MonoTouch/MonoDroid to clients
Ouch. This is bound to 'look bad' since the less your clients understand about the risk/reward of a tool like Mono*, the more they are going think you've stuffed up. In reality, though, the above points still apply - you can offer them the same bet: switch tools now and potentially waste some time or risk 'maybe' porting at a later time but take advantage of the benefits Mono* provides now... after all you recommended Mono* for a reason and many of those reasons are still valid.

I have done this myself - so I know how uncomfortable it feels.

I am interested in MonoTouch or MonoDroid but haven't purchased yet
This is a tough one. I'm not sure that the Novell Shopping Cart or the Activation Server are even working at the moment (activation behind an authenticating proxy is not supported at all). Even if they were, I'm not sure I'd want to give Attachmate my money. Maybe this will become clearer in the coming days/weeks.
You can definitely try out the 'free trial' (emulator only) editions but for a real project that you want to publish on AppStore/Marketplace soon I'm afraid you might need to consider learning the native SDKs or waiting a while... :-(

In conclusion...
I'll be the first to admit this is a very "glass half-full" point-of-view. Lots of bad s**t could happen: support issues with the current products that can't be resolved, legal issues with Attachmate, product delays from Xamarin, unexpected costs or incompatibilities for the new stuff, etc, etc, etc.

At the end of the day, you'll make a decision based on your risk-averse-ness (triple word score!) regardless of my rainbows and unicorns. Just keep in mind that the apparent 'end of life' of the current MonoTouch/MonoDroid products, while sad, is not (yet) the end of the world. In some ways, you can best support Xamarin by continuing to use the existing tools so that you've got something to migrate to their new stuff.

Make sure you've got some peanuts and a towel, and above all DON'T PANIC.

Mobile Camp Oz

Went along to Mobile Camp Oz today, saw some great presentations from @dglover, Scott Vandonkelaar and @markaufflick as well as an interesting keynote by Darren Burden of Fairfax Media. Thanks to the speakers for their time and also to everyone that came along to watch (finally special thanks to Nick for organising and convincing me to come along!).

As for my pres, here are the slides:

Cross-platform mobile dev with Mono

and you'll find example source at github.com/conceptdev. The pres was a bit slide-heavy... will do more live-code/examples next time.

Also check out these past posts:

• Mosetta Stone
• MonoDroid meet MonoTouch & WindowsPhone7

Finally - check out the result of Scott's presentation on the Android Market Mobile Camp Oz!

MonoDroid meet MonoTouch & WindowsPhone7

This post follows the previous one about building for MonoTouch and WindowsPhone7 by porting the example to Google's Android platform using MonoDroid.

Here's how it looks (no need to identify which platform is which :)

As before, the code is available on github/conceptdev/RestaurantGuide - for comparison here is a shot of the three .sln files.

A couple of observations:

• One of the reasons the iOS/MonoTouch solution is so 'neat' is because I have not used the 'UI Designer' for that platform (ie. Interface Builder) so there are no 'markup' files for the user interface (ie. .xib files). The entire layout is done in C# for the MonoTouch example, whereas the WP7 and Android version use Xaml and axml respectively.
• These examples 'just work' - they don't claim to be best-practice in designing an app for any of these platforms*.

* for a quite neat cross-platform design (at least across MonoDroid and WP7) see @gshackles TwitterSearcher sample

p.s. does anyone know what the Android equivalent of an "indexed list" is? Pls comment or @conceptdev... thx

More MonoTouch Machine-translation Madness!

In addition to the recent dodgy Spanish localization, my TweetStation fork now has dodgy French, Japanese, German and Italian translations (courtesy of the Microsoft Translator API that was introduced at MIX10). Here's how they look:

The following two code snippets were added to ngenstrings so that once the text has been extracted from TweetStation, it is automatically translated and written to .strings files ready for inclusion in the correctly-named .lproj folders (this code hasn't been committed to github - but it should be easy to add to your local copy).

add code to the end of MainClass.Main

string[] languages = new string[]{"fr","ja","it","de"};
foreach (var language in languages)
{
   foreach (var table in tables.Values)
   {
      foreach (LocalizedString locstring in table.Values)
      {
         locstring.Value = Translate(locstring.Key, language);
      }
      table.WriteStringsFile(assemblyName, outputFormat, language);
   }
}

add method to MainClass

//http://msdn.microsoft.com/en-us/library/ff512421.aspx
static string Translate (string text, string toLanguageCode)
{
   string appId = "REGISTER_AND_INSERT_YOUR_APPID";
   string translation = text;
   text = text.Replace(" ", "%20").Replace("&", "").Replace("#","%3F");

   string detectUri = "http://api.microsofttranslator.com/v2/Http.svc/Translate?appId=" + appId +
  "&text=" + text + "&from=en&to=" + toLanguageCode;
   Console.WriteLine(detectUri);
   try {
      System.Net.HttpWebRequest httpWebRequest = (System.Net.HttpWebRequest)System.Net.WebRequest.Create(detectUri);
      System.Net.WebResponse resp = httpWebRequest.GetResponse();
      Stream strm = resp.GetResponseStream();
      StreamReader reader = new System.IO.StreamReader(strm);
      translation = reader.ReadToEnd();
   }
   catch (Exception e)
   {
      Console.Write("Translation failed for " + text + " - " + e.Message);
   }
   return translation;
}

Hopefully that gives you some ideas (or inspiration) on how to increase the market for your apps across the world. Remember that machine-translation is NOT a substitute for a professional human translation, however it can be useful to test your application's ability to handle and display different languages (eg. the size of the strings, etc).

TwitEstaçion: MonoTouch TweetStation en español

If you are a MonoTouch developer then you should already be familiar with the two subjects of this post:

• Miguel's awesome TweetStation open-source/MonoTouch Twitter client (also on iTunes); and
• the recent release of the Professional iPhone Development with MonoTouch/c# book from Wrox

It just so happens that Chapter 12 - Localizing for an International Audience of the book introduces a small utility called ngenstrings that helps you to translate your application into other languages. Today I updated ngenstrings to use the latest Mono.Cecil version, and to test it out I decided to have a go at localizing TweetStation into Spanish. You can download the Localizable.strings file that was created (and translated courtesy of Bing). Here's a screenshot showing where it fits into the solution:

...and here are a couple of screenshots showing TwitEstaçion in action ;-)

NOTE: Miguel had already made a good start building an internationalized app - many of his strings were wrapped in a Locale.GetText() method which was easy for me to work with. None of his code needed to change except for Locale.Get() and Locale.Format() to add NSBundle.MainBundle.LocalizedString(str,"");
NOTE2: this was a MACHINE TRANSLATION - of course you would arrange for a real person to translate your apps before taking them to the AppStore!
NOTE3: I have not translated 100% of Miguel's app - this is for demonstration purposes at the moment.
NOTE4: It's called TwitEstaçion because "TweetEstaçion" is too long for the iPhone home screen, and gets shortened unreadably. I don't speak Spanish so who knows if that makes any sense at all!

UPDATE: a few more screenshots... (again, apologies for the machine translation:)

UPDATE2: localized code forked from TweetStation main now available on github.

When Mono "just works" - Searcharoo 'ported'

Decided to have another play with Mono today, in preparation for MonoTouch to come out of beta (or for my beta-participation to be approved)...

It was very easy to install Mono and MonoDevelop on my Mac, and because MonoDevelop supports Visual Studio 2008 solution files the current release of Searcharoo opened straight away*, compiled and could be tested with the 'provided' XSP2 webserver:


* I removed the Silverlight project from the Searcharoo solution (playing with Moonlight is a project for another day), but the Silverlight XAP from my Windows machine runs happily on the Mac against the Mono-version of the website:


The other cool thing about MonoDevelop is that it already supports the iPhone/MonoTouch 'project types'. You can't compile/test/run anything (you need MonoTouch.Foundation and MonoTouch.UIKit which are in 'private beta'), but you can browse the MonoTouch Samples - so at least you can see what C# code for the iPhone looks like. Fingers crossed Miguel and the team release the bits publicly ASAP :-)