Tag Archive for 'mono'

Rosetta stone of mobile development for WP7, iOS, Android

Cool link with a side-by-side comparison of WP7, iOS, and Android development features and classes from a mono (C#) perspective.

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).

Crossplatform mobile dev with Mono

Cool post over on Chris Hardy’s blog talking about a non-trivial twitter app on winphone 7, iphone and android with the mono toolset.

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.

Documentation Driven Development

Interesting post from a mono hacker about taking Test Driven Development to the next level, Documentation Driven Development. I like it, at least in theory. It definitely sounds like a great way to approach development from a mind-set perspective, if not actually from a practical perspective.

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

C# for the iPhone

Awesome post from an Aussie no less which is a non-trivial iPhone application using c# on monotouch.

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.

Monotouch for iPhone goes 1.0

According to miggie, Monotouch for iPhone goes 1.0.

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.

PHP Toolkit for ADO.Net Data Services

Found this interesting link on this post over on monologue.

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.

Managed Port of Sqlite

Over on Miggie’s blog, a post about a line-by-line port of Sqlite to C#.

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.

Microsoft extends community promise to ECMA C# and CLI

First seen over on monologue, Miguel writes to say that Microsoft has extended it’s Community Promise (around patents etc.) to the ECMA standardised C# and CLI components.

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.

Mono VPC appliance

Over on monologue, a mono virtual PC appliance.

Retargeting P/Invoke to managed code

Chris Toshok over on monologue post’s about minvoke, a tool to retarget p/invokes out of unmanged land and into managed code.

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.