iOS	WP7	Android
“View”	XIB (Interface Builder)	Xaml	axml
	UIViewController	PhoneApplicationPage (codebehind)	Activity
	n/a (UIAutoResizing)	StackPanel	LinearLayout
	UITableView	ListBox	ListView
	UITableViewCell	ListBox.ItemTemplate	n/a (any view)
	UITableViewSource	n/a (binding, IEnumerable)	BaseAdapter
Navigation “Controller”	NavigationController. PushViewController()	NavigationService. Navigate()	StartActivity()
	n/a (object)	Xaml Uri	Intent.SetClass()
	n/a (object properties)	Xaml Uri querystring params	Intent.PutExtra() .AddFlags()
	n/a (object properties)	NavigationContext .QueryString .TryGetValue()	Intent .GetXXXExtra()
Threading	InvokeOnMainThread	Dispatcher.BeginInvoke	RunOnUiThread
“Model”	C# .NET objects – shared thanks to Mono on iOS & Android. Also WebClient, Linq, Generics, Xml, Serialization, etc…

And while we are on the mono subject, they just released a Mono droid update, which means they now have comprahensive tool chains for C# development for the following systems, iOS (including app store), Mac (including app store), Android (including app store).

Stick with the preso, the last few slides have the best info about cross platform dev and limitations, and the videos at the actual post are quite cool.

So a standard workflow looks something like this:

1. Write guide for feature A
2. Write unit tests for feature A
3. Implement feature A
4. Eat Burrito
5. Write API docs for feature A
6. Update tests with issuelets discovered while writing class docs
7. Update feature A

The thing I love about monotouch is that it lets me leverage my .Net Skills (not just c#, but how the .Net run time works) and marries it to the low-level iPhone development infrastructure. The hardest part about getting into iPhone development for me was Objective-C, and now I don’t need to go there.

Points to note:

• Obviously since interpretation is not allowed on the iPhone the guys at the mono project had to put together monotouch, which statically links the parts of the .net framework needed into each iPhone app.
• Monotouch is a payed for product.

This enables you to use a static version of .Net (actual mono) with native C# bindings of the iPhone API, so no Compact Framework concepts for iPhone just yet. I agree with this decision, since people developing for the iPhone want their apps to look like they were developed for the iPhone.

Basically it’s a PHP toolkit to get access to the data exposed by ADO.Net Data Services, which exposes data in a RESTful manner.

It obviously takes a performance hit (something like 5 times slower) but think of all the opportunities it opens up. I’m thinking mainly about Windows Phone development using Compact Framework and no longer needing the external Sqlite dll linkage (figuring out which one to use was a nightmare).

Miggie mentions using it in Silverlight apps, which is an awesome idea, or in medium trust ASP.Net servers. The Silverlight use will have to wait till they pull all the P/Invokes out of it, which doesn’t seem to be too far off, as is the possibility for some performance improvements by capitalising on the .Net Framework features instead of being a line-by-line port from C.

Quote from the announcement by Peter Galli at MS:

It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions.You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications.

The Promise applies to developers, distributors, and users of Covered Implementations without regard to the development model that created the implementations, the type of copyright licenses under which it is distributed, or the associated business model.

Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

Full Community Promise over at Microsoft.

Note: as Miguel says in his post, mono implements a whole bunch of .Net technology above and beyond ECMA C# and CLI and those parts (ASP.Net ADO.Net etc) aren’t currently covered by this promise.

The potential of this tool is absolutely awesome. As I understood it, the primary reason is to enable the guys to shoe-horn portability onto .Net apps with over-zealous p/invokes into windows api calls. Makes sense.

But that’s not the only reason you’d use it. You could use this tool to force managed applications that call into native land to be completely managed, enabling you to ensure that the .Net security model is applied to every aspect of the code, or simply freeing yourself of the need to have developers around that can develop in more than just .Net.

As stupid as that sounds, it’s getting increasingly hard to find developers around that understand more than one language/framework. Even those that do, generally only understand multiple web-development languages. So if you ever find yourself in a situation where you are working on a Winforms app that needs to interface with a device of some sort you’d be shit out of luck.