Xamarin welcomes MonoTouch and MonoDroid "home"

Great news! Xamarin has acquired a "broad, perpetual license" to the MonoTouch and Mono-for-Android work that was done while the dev team was part of Novell (prior to the Attachmate buyout kerfuffle). There's a press release on the Novell website and Miguel posted on his blog too. Congratulations to the Xamarin team!

Check out the product details at:

• Xamarin home
• MonoTouch (for iOS)
• Mono-for-Android (for Android:)
• plus the store & bugzilla are back... and the products are available to purchase immediately (with upgrades for 'existing customers')

Start with the iOS Roadmap to find out what's coming up next.

Monospace is going to be great! Have you downloaded the app yet :-) ?

"M"osetta Stone II: ViewController → Activity

After my recent posts I received a question asking for tips on porting a MonoTouch app to MonoDroid. I'm going to take a crack at that over a couple of days - with the warning that you probably shouldn't rush out and buy either tool but wait for Xamarin's future Mono-on-iOS and Mono-on-Android products.

The purpose of the original "M"osetta Stone post was to give cross-platform developers a 'head start' with some high-level concepts. This post will look a little closer at a screen from the Monospace11 app: the Speakers list.

This may be a massive oversimplification, but...

if you have ___ in iOS	then you want ___ in Android	to
UIViewController	Activity	subclass to present a screen/form/page to the user
ViewDidLoad()	OnCreate()	setup the UI
Add() or AddSubview()	SetContentView()	use in ViewDidLoad/OnCreate to 'attach' UI to display
ViewWillAppear()	OnResume()	load/re-load data that might change and bind to UI
UITableView	ListView	visual control that presents a scrolling list
UITableViewSource	Adapter	subclass to broker the display of a data collection to the UI
GetCell()	GetView()	to build the layout(UI) for each cell/row, including re-using cells/views for performance
RowSelected()	ItemClick EventHandler	perform an action when a row is touched
RowsInSection	Count	tell the table/list how many rows to cater for

Here's how it looks in a Visual Studio Class Diagram*

* I've greyed out some of the methods not relevant to the discussion - the iOS implementation of the alphabetic index down the right edge doesn't have an Android equivalent, for example

Notes:

• UITableViewSource has been implemented as an nested class to resemble the iOS pattern of implementing the equivalent Obj-C protocols on the ViewController - this pattern makes no sense in Android so the classes are separate.
• The MonoTouch example code builds the UI in C# (eg. tableView=new UITableView();AddSubview (tableView);) whereas MonoDroid loads layout XML files SetContentView(Resource.Layout.Speakers);. This can happen in both ViewDidLoad/OnCreate and GetCell/GetView where UI controls must be created and presented to the user.
• The 'touch event handler' is in a different class: in MonoTouch the TableViewSource handles a touch for a specific row (NSIndexPath); MonoDroid implements the ItemClick EventHandler<ItemEventArgs> on the ListView for a given GetRow(e.Position).
• Both examples use the constructor (TableViewSource/SpeakersAdapter) of the 'broker' class to pass the actual business object collection for display. This pattern lets the data be filtered/sorted/whatever before being passed in for display.
• Calling refreshSpeakers() from ViewDidLoad/OnResume is kinda redundant in this example since the list never changes - but in other spots (eg the Favorites screen) you would want to refresh the list each time because it may have changed.

The Code
You can have a look at the MonoTouch code SpeakersViewController.cs and the MonoDroid SpeakersActivity.cs, SpeakersAdapter.cs to see the actual implementation. For MonoDroid you'll also need to check out the layout XML files Speakers.axml and SpeakersItem.axml.

One more thing...
One final piece which takes some getting used to... in MonoTouch this screen is part of a UINavigationController stack and your RowSelected creates a new ViewController object (passing whatever parameters you need) and calls NavigationController.PushViewController(). The ViewController instances in the navigation stack are 'stateful' and it is really easy to pass business objects around as parameters.
In MonoDroid, the ever-present 'back-stack' does not require a specific 'navigation controller' BUT at it's simplest the mechanism is much more primative and involves passing simple type parameters (eg. strings) like this
var intent = new Intent();
intent.SetClass(this, typeof(SpeakerActivity));
intent.PutExtra("Name", speaker.Name);
StartActivity(intent);
There are more sophisticated approaches but it is probably best to keep your parameter-passing to a minimum - this way the Android hardware 'Back' button "just works".

HTH Slava ;-)

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!

MonoDroid for Monospace

Waay back in 2009 I threw together MonoTouch for Monospace as an early example of using C# on the iPhone using MonoTouch.

Fast-forward two years... to MonoDroid for Monospace:

The schedule for Monospace 2011 was just announced today, and since there didn't seem to be a mobile app announced along with it I've re-used some old code to get a basic Android app working using Mono for Android.

Download/try it out
You can install Monospace11 from the Android Market

OR

Download the Mono for Android code from Monospace11 on Github

and visit the 'homepage' at monospace11.confapp.com

Leave any comments or feedback below.

OzALT.NET MonoDroid Presentation

Slides from tonight's OzALT.NET '20 minute' presentation on Mono-for-Android. I didn't actually make it through all the slides, but we got through a few demos including this simple HelloWorldActivity.cs example and the Restaurant Guide demo.

OzAltNet Fast-ANDroid-Furious

Also enjoyed @thomasjo's pres on CoffeeScript and Joshua Roth talking about NBuilder.

Mobile UI Design ramblings...

Mobile UI design has come up a couple of times the past few days (as has Xamarin),

• I'm looking to port an existing iOS app to Android - how 'same' should it look?
• Nielsen Norman Group released their latest Useability of iPad Apps and Websites report
• Ongoing discussion with @russaus

...so seemed like a good time to make some notes (and for UI, read UX and IA as well :)

Porting apps...
Porting apps from one platform to another (iPhone to Android, iPad to Android, or to Windows Phone, or from 'web', etc) always brings with it a challenge to make each version feel 'native' and embrace the platform's UI idioms & metaphors (while simultaneously re-using as much code as possible and keeping your application consistent across each). This can be seen in previous posts on the MIX11 app and the Restaurant Guide sample being ported to iPhone, Android and Windows Phone 7. Should the new Android app be a 'UI clone' of the iOS version? Should it be redesigned from scratch, removing any traces of iOS-ness? The answer is probably somewhere in between, being guided by your usability and branding goals, and by feedback from your users.
UPDATE: some thoughts on Why Are Android Apps Ugly? :-)

"Usability of iPad Apps and Websites": 2 reports
Coincidentally, while planning the UI for the Android app, Nielson Norman Group released an updated Usability Report for iPad Apps and Websites. The new edition (and the previous) are great reads (free to download) - some points will seem obvious, some will trigger "a-ha" moments and other's you'll disagree with; but overall you'll probably find it worthwhile to download them both.

References...
There are a couple of great websites worth looking at when you are doing UI design

• mobile-patterns.com is a cool collection of screenshots from iPhone apps grouped into 'UX categories' like User Profiles and Lists. My favorite is Empty Data Sets - so often overlooked! (by @mari18)
• ui-patterns.com is a more general collection (ie. not mobile) with categories like Getting Input and Navigation. It is a LOT deeper in terms of content (articles/discussion as well as screenshots) and likely to be thought-provoking no matter what platform you're working on. (follow @uipatternscom
• UPDATE: Windows Phone 7 for Designers — Cheat Sheet kinda similar to the mobile-patterns site above but for Windows Phone. Poster-layout for easy printing/reference (by @teppo).

...and what about that whole MonoTouch/MonoDroid 'thing'?
Novell (Attachmate) says (my underline)

Focusing on what matters most to customers is the key to our innovation strategy and will drive the growth of our business. This has meant reductions in certain areas, such as Mono. However, Mono remains part of the SUSE business and should customer demand for Mono products accelerate, our development efforts will rapidly respond. Regardless, we will continue to provide maintenance and support for all Mono products – MonoTouch, Mono for Android, Mono Tools for Visual Studio and SUSE Linux Enterprise Mono Extension.

But it sounds disingenuous considering they have already sacked the entire team... and WTF does "should...demand...accelerate" mean? How is demand going to grow when they've killed any chance of enhancing the product and do not market it?? If they were truly "Focusing on what matters most to customers" they wouldn't have sacked the engineers in the first place, or else should have released/sold/transferred the Touch/Droid IP to Xamarin where it has some hope of a future (IMHO, anyway). </2centsworth>

Also, in related news, @migueldeicaza announced that Nat Friedman has joined Xamarin as CEO. Nat previously worked with Miguel as a co-founder of Ximian.

p.s. I'm *guessing* that we will be saying goodbye to the MonoTouch and Mono for Android product names since Novell probably owns them... wondering what I should use for Twitter hashtags now to replace #monotouch and #monodroid? Something with an 'X'? :)