I have a posted an update on Mono and the upcoming release of Mono 2.12.

We are getting flooded with paid support requests for Mono. Developers looking for us to fix bugs in Mono, to do some custom work, to port applications, libraries and adjust Mono for some specific needs.

But we are trying to be a product company as opposed to a support company.

We still want to help the Mono user community, and with all of the Mono talent out there, at least we can use this opportunity to get both groups in touch: the users that want custom engineering done, with the talented list of hackers.

If you are a consultant available to do custom engineering and support for customers, we would love to put you in touch with people that need the custom engineering done. Email us at [email protected], in the subject line, specify that you are available for custom engineering, and in the body of the message list both your Mono skills (C# or C coding) and your availability to engage on those gigs.

We will then get you in touch with users that needs the work done.

Setting up a new company consumes a lot of time. Specially as we are developing as fast as we can not one, but two products: .NET for iPhone and .NET for Android.

Structurally, we are better off than we were the first time that we built these products. We have more developers working on each product than we did the first time around, so progress is faster. But we also had to swap the developers around: those that wrote Foo, can not work on Foo again. This is just one of the things that we have to do to ensure a clean room implementation.

Our vision is to create happy developers. We did that in the past by bringing the C# language, garbage collection, LINQ, strongly typed APIs, Parallel FX, intellisense and inline documentation to iPhone and Android developers. And by making it possible for the world's 6 million .NET developers to reuse their skills on the most popular mobile platforms.

This time around, we are doing even more. We are addressing many of the frustrations that developers had with the old products and making sure that those frustrations go away.

Nat and myself complement each other very well here. This means that there are a lot of new things that will be present in our offering that we never did in the past.

There is a new level of polish that those familiar with Nat's previous products had (SUSE Studio, NLD/SLED, Ximian Desktop). Everyone at Xamarin can feel that Nat is hard at work when they noticed that one of the first things Nat did was to engage six design firms and an army of technical writers to ensure that our products go from "Nice" to "Amazing". And that was on his second week as CEO, a lot has happened since.

I do not want to give away everything that we are doing, it would ruin the surprise, but we are here to deliver joy to programmers everywhere.

If you are interested in working with us, and making mobile development and .NET development a joy that everyone can enjoy, check out our Jobs page

Where we are now

It gives me great pleasure to say that we have elevated the discourse on the iPhone simulator and my Chicken-powered TweetStation is up and running with the new iOS product. The picture on the left is TweetStation powered by MonoTouch, the picture on the right is TweetStation powered by Xamarin's iPhone product:

TweetStation on MonoTouch
TweetStation on Xamarin iOS

Update: TweetStation now starts up on Device! We have the static compiler working!

We also have the delicious iOS5 APIs exposed as strongly-typed and intellisense-friendly C#. We are now updating the APIs from Beta1 to Beta2, which should be completed today or tomorrow.

Our Android efforts are moving fast. Only this morning we got Layouts to render on the device. This is a lot of work, as it gets Dalvik to start Mono, and initializes our entire bridge and exercises the C# and Java bridge. In addition, we have identified and fixed a serious problem in the distributed garbage collector.

We also have a number of surprises for everyone in MonoDevelop, we believe that you guys are going to love the new features for iPhone and Android development.

There is still a lot of polish left to do. We are working as hard as we can to have Preview releases in your hands, but we feel confident that we will have a great product for sale by the end of the summer. We hope you will all max out your credit cards buying it.

I could not be more excited about this.

Nat Friedman has joined Xamarin as a company founder and CEO this week.

Nat and I have known each other and worked together on and off since the early days of Linux. In 1999, we started Ximian to advance the state of Linux, user experience and developer platforms - with many of our efforts brought to fruition after our acquisition by Novell in 2003.

Anyone that has had the pleasure to work with Nat knows that ideas come in one side, and objects of desire come out on the other end.

In mobile development, we've discovered a great opportunity: a need for products that developers love. And we are going to fill this need with great products that will make everyone's eyes shine every time they use our software.

Update: Nat's most recent product was SUSE Studio.

Today we start Xamarin, our new company focused on Mono-based products.

These are some of the things that we will be doing at Xamarin:

• Build a new commercial .NET offering for iOS
• Build a new commercial .NET offering for Android
• Continue to contribute, maintain and develop the open source Mono and Moonlight components.
• Explore the Moonlight opportunities in the mobile space and the Mac appstore.

We believe strongly in splitting the presentation layer from the business logic in your application and supporting both your backend needs with C# on the server, the client or mobile devices and giving you the tools to use .NET languages in every desktop and mobile client.

Development started early this morning, we will first deliver the iPhone stack, followed by the Android stack, and then the Moonlight ports to both platforms.

The new versions of .NET for the iPhone and Android will be source compatible with MonoTouch and Mono for Android. Like those versions, they will be commercial products, built on top of the open core Mono.

In addition, we are going to provide support and custom development of Mono. A company that provides International Mono Support, if you will.

As usual, your feedback will help us determine which platforms and features are important to you. Help us by filling out our survey. If you give us your email address, we will also add you to our preview/beta list for our upcoming products.

Fighting for Your Right to Party

We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers. Although Attachmate allowed us to go home that day, we opted to provide technical support to our users until our last day at Novell, which was Friday last week.

We were clearly bummed out by this development, and had no desire to quit, especially with all the great progress in this last year. So, with a heavy dose of motivation from my music teacher, we hatched a plan.

Now, two weeks later, we have a plan in place, which includes both angel funding for keeping the team together, as well as a couple of engineering contracts that will help us stay together as a team while we ship our revenue generating products.

Update: although there was a plan to get Angel funding, it turns out that we self-funded the whole thing in the end.

Next Steps

Our plan is to maximize the pleasure that developers derive from using Mono and .NET languages on their favorite platforms.

We do have some funding to get started and ship our initial products. But we are looking to raise more capital to address the shortcomings that we could not afford to do before, these include:

• Tutorials for our various developer stacks
• API documentation for the various Mono-specific APIs
• Dedicated Customer Support Software (assistly or getsatisfaction)
• Upgrade our Bug system
• Training
• Consulting and Support
• and Marketing: we have a best of breed developer platform, and we need the world to know. Our previous marketing budget is what the ancient Olmec culture referred to as Zero.

Stay tuned for more, meanwhile, hope to see you in July at the Monospace conference in Boston!

I am a fan of Dropbox. It is a great tool, a great product, and clearly they have a passionate team over at Dropbox building the product.

Dropbox recently announced an update to its security terms of service in which they announced that they would provide the government with your decrypted files if requested to do so.

This is not my problem with Dropbox.

My problem is that for as long as I have tried to figure out, Dropbox made some bold claims about how your files were encrypted and how nobody had access to them, with statements like:

• All transmission of file data occurs over an encrypted channel (SSL).
• All files stored on Dropbox servers are encrypted (AES-256)
• Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)

But anyone that tried to look further came out empty handed. There really are no more details on what procedures Dropbox has in place or how they implement the crypto to prevent unauthorized access to your files. We all had to just take them at their word.

This wishy-washy statement always made me felt uneasy.

But this announcement that they are able to decrypt the files on behalf of the government contradicts their prior public statements. They claim that Dropbox employees aren't able to access user files.

This announcement means that Dropbox never had any mechanism to prevent employees from accessing your files, and it means that Dropbox never had the crypto smarts to ensure the privacy of your files and never had the smarts to only decrypt the files for you. It turns out, they keep their keys on their servers, and anyone with clearance at Dropbox or anyone that manages to hack into their servers would be able to get access to your files.

If companies with a very strict set of security policies and procedures like Google have had problems with employees that abused their privileges, one has to wonder what can happen at a startup like Dropbox where the security perimeter and the policies are likely going to be orders of magnitude laxer.

Dropbox needs to come clear about what privacy do they actually offer in their product. Not only from the government, but from their own employees that could be bribed, blackmailed, making some money on the side or are just plain horny.

Dropbox needs to recruit a neutral third-party to vouch for their security procedures and their security stack that surrounds users' files and privacy. If they are not up to their own marketed statements, they need to clearly specify where their service falls short and what are the potential security breaches that

Unless Dropbox can prove that algorithmically they can protect your keys and only you can get access to your files, they need to revisit their public statements and explicitly state that Dropbox storage should be considered semi-public and not try to sell us snake oil.

The dates for the MonoSpace conference have been announced: July 23rd to 25th, 2011. The event will take place at the Microsoft NERD Center.

The organizers have just made a call for speakers. If you have an interesting topic to discuss, please submit a talk, we would love to hear from you.

The dates for the MonoSpace conference have been announced: July 23rd to 25th, 2011. The event will take place at the Microsoft NERD Center.

The organizers have just made a call for speakers. If you have an interesting topic to discuss, please submit a talk, we would love to hear from you.

Today we are happy to release Mono for Android 1.0 as well as MonoTouch 4.0.

Both products allow you to use the C# language to write applications that run on Android and iOS devices.

Both products are based on the latest Mono 2.10 core. The Parallel Frameworks can be used to write more elegant multi-threaded code across all devices, and automatically takes advantage of multiple cores available on the iPad2 and Xoom devices. The C# 4.0 is now the default as well as the .NET 4.0 APIs.

Mono for Android

Our Mono for Android debuts today after almost a year worth of development.

Perhaps the most important lesson that we got from MonoTouch's success was that we had to provide a completely enabled platform. What we mean by this is that we needed to provide a complete set of tools that would assist developers from creating their first Android application, to distributing the application to the market place, to guides, tutorials, API documentation and samples.

Mono for Android can be used from either Visual Studio Professional 2010 for Windows users, or using MonoDevelop on the Mac.

Mono code runs side-by-side the Dalvik virtual machine in the same process:

This is necessary since code running in Dalvik provides the user interface elements for Android as well as the hosting and activation features for applications on Android.

APIs

The Mono for Android API is made up of the following components: Core .NET APIs, Android.* APIs, OpenGL APIs and Java bridge APIs.

Let us start with the most interesting one: Android.* APIs. These are basically a 1:1 mapping to the native Java Android APIs but they have been C#-ified, for example, you will find C# properties instead of set/get method calls, and you will use C# events with complete lambda support (with variables being automatically captured) instead of Java inner classes. This means that while in Java you would write something like:

	// Java code
	button.setOnClickListener (new View.OnClickListener() {
             public void onClick(View v) {
		button.setText ("Times clicked: " + Integer.toString(counter));
             }
         });
	

	// C# code
	button.Click += delegate {
		button.Text = "Times clicked: " + counter;
	};
	

In addition to the UI APIs, there are some 57 Android.* namespaces bound that provide access to various Android features like telephony, database, device, speech, testing and many other services.

In what is becoming the standard in the Mono world, OpenGL is exposed through the brilliant OpenTK API. OpenTK is a strongly typed, Framework Design Guidelines-abiding binding of OpenGL. The benefit is that both Visual Studio and MonoDevelop can provide intellisense hints as you develop for the possible parameters, values and their meaning without having to look up the documentation every time.

Finally, for the sake of interoperability with the native platform, we exposed many types from the Java.* namespaces (31 so far) that you might need if you are interoperating with third party libraries that might require an instance of one of those Java.* types (for example, a crypto stack might want you to provide a Javax.Crypto.Cipher instance. We got you covered.

Core Differences

Mono for Android has a few differences from MonoTouch and Windows Phone 7 when it comes to the runtime. Android supports JIT compilation while iOS blocks it at the kernel level and Windows Phone 7 has limitations.

This means that developers using Mono on Android have complete access to System.Reflection.Emit. This in turn means that generics-heavy code like F# work on Android as do dynamic languages powered by the Dynamic Language Runtime like IronPython, IronRuby and IronJS.

And of course, you can also use our own C# Compiler as a Service

Now, although those languages can run on Mono for Android, we do not currently have templates for them. The Ruby and Python support suffer due to Android limitations. The Dalvik virtual needs to know in advance which classes you customize, and since it is not really possible to know this with a dynamic language, the use of Iron* languages is limited in that they cant subclass Android classes. But they can still call into Android APIs and subclass as much .NET class libraries as they want.

Native User Interfaces

MonoTouch and MonoDroid share a common runtime, a common set of class libraries, but each provides different user interface and device specific APIs.

For example, this code takes advantage of iOS's UINavigationController and animates the transition to a new state in response to a user action:

void OnSettingsTapped ()
{
	var settings = new SettingsViewController ();
	PushViewController (settings, true);
}
	

This is an equivalent version for Mono for Android:

void OnSettingsTapped ()
{
	var intent = new Intent ();
	intent.SetClass (this, typeof (SettingsActivity));
	StartActivity (intent);
}
	

We chose to not follow the Java write-once-run-anywhere approach for user interfaces and instead expose every single bit of native functionality to C# developers.

We felt that this was necessary since the iOS and Android programming models are so different. We also wanted to make sure that everything that is possible to do with the native APIs on each OS continues to be possible while using Mono.

For instance, if you want to use CoreAnimation to drive your user interactions, you should be able to leverage every single bit of it, without being forced into a common denominator with Android where nothing similar to this is available.

Craig Dunn, one of the authors of the MonoTouch Programming Book, has written a nice Mosetta Stone document that compares side-by-side some of the key UI differences across platforms.

He also has written the Restaurant Guide Sample which sports a unique user interface for Android, iOS and Windows Phone 7:

You can take a look at this cross platform sample from GitHub.

Split your Presentation from your Engine

• MonoTouch for iOS.
• Mono for Android for Android.
• Silverlight/Mobile for Windows Phone 7.
• MonoMac for MacOS X.
• Gtk# for Linux, Mac and Windows.
• Silverlight 4 for Linux, Mac and Windows
• ASP.NET, ServiceStack, and Manos de Mono for HTML presentations.

To give your code the most broad reach, you should consider splitting your backend code from your presentation code. This can be done by putting reusable code in shared libraries (for example, REST clients) and shared business logic on its own libraries.

By splitting your presentation code from your business logic code for your application, not only you gain the ability to create native experiences in each platform, you also get a chance to test your business logic/shared libraries more easily.

Linking

In Mono for Android when you build an application for distribution, we embed the Mono runtime with your application. This is necessary so your application is entirely self-contained and does not take any external dependencies.

Mono for Android uses the Mono Linker to ensure that only the bits of Mono that you actually use end up in your package and that you do not pay a high tax for just using a handful of functions.

For example, if you want to just use a method from XElement, you would only pay the price for using this class and any of its dependencies. But you would not end up bringing the entire System.XML stack: you only pay for what you use.

During development a different approach is used: the Mono runtime is installed on your emulator or test device as a shared runtime. This minimizes both the build and deploy times.

Mono for Android References

Start with our documentation portal, there you will find our Installation Guide, a tutorial for your first C# Android application, our tutorials (many ported from their Java equivalents) and our How-To Guides and a large collection of sample programs.

You can also explore the documentation for the Mono for Android API in a convenient to remember url: docs.mono-android.net.

The first book of Mono for Android will be available on July 12th. In the meantime, we have created many tutorials and guides that will help you go

I also strongly suggest those interested in parallel programming to check out the Patterns for Parallel Programming: Understanding and Applying Parallel Patterns with the .NET Framework 4. This is a free PDF, and is a must-read for anyone building multi-core applications.

Thank You!

Mono for Android would not have been possible without the hard work of the MonoDroid team at Novell. The team worked around the clock for almost a year creating this amazing product.

The team was backed up by the Mono core team that helped us get C# 4.0 out, WCF, the linker, the LLVM support, improve the VM, extend the MonoDevelop IDE, scale Mono, improve our threadpool, support OpenTK, implement the Parallel Frameworks, ship dozens of betas for MonoDevelop, Mono and Mono for Android.

We have been lucky enough that Google accepted Mono as a mentoring organization for the Google Summer of Code 2011

This is a great opportunity for students to get involved with open source, contribute, learn and get paid for their work during the summer.

We have a lot of ideas to choose from in our student projects page, ranging from virtual machine hacking, MacOS X improvements, MonoDevelop extensions, language bindings and even improving the Manos web application framework.

Do not let our limited imagination stop you. Although there are plenty of ideas to choose from, students should feel free to come up with their own ideas. In the past years projects based on students' ideas have been very successful and we want to encourage more of those.

Proposal submission is open until Friday April 8, so now is the time to join our wonderful community, discuss your project ideas and start working on those proposals.

The Mono Summer of Code IRC channel is #monosoc on irc.gnome.org