MonoTouch 1.0 goes live.

by Miguel de Icaza

MonoTouch is a commercial product based on Mono and is made up of the following components:

  • MonoTouch.dll The C# binding to the iPhone native APIs (the foundation classes, Quartz, CoreAnimation, CoreLocation, MapKit, Addressbook, AudioToolbox, AVFoundation, StoreKit and OpenGL/OpenAL).
  • Command Line SDK to compile C# code and other CIL language code to run on the iPhone simulator or an iPhone/iPod Touch device.
  • Commercial license of Mono's runtime (to allow static linking of Mono's runtime engine with your code).
  • MonoDevelop Add-in that streamlines the iPhone development and integrates with Interface Builder to create GUI applications.

The MonoTouch API is documented on the Mono site. The MonoTouch API is a combination of the core of .NET 3.5 and the iPhone APIs.

We have created some tutorials on how to use MonoTouch and you can read the design documentation on the MonoTouch framework.

Some History

Almost a year ago when we released Mono 2.0 for OSX, I asked the readers of this blog to fill a survey to help us understand where we should take Mono.

Many developers asked us to provide Mono for the iPhone.

A year ago, it was possible to use Mono's static compiler to compile ECMA 1.0 CIL bytecode for the iPhone. This is the technology that powered Unity3D's engine for the iPhone.

Users of Unity3D have published more than 200 applications on the AppStore.

We debated internally what exactly Mono for the iPhone would be. We considered doing a Windows.Forms port, to bring Compact Framework apps to the iPhone, but that would have required a complete new backend for Windows.Forms and would have required also a "theme" engine to make it look like the iPhone. We discarded this idea early on.

We decided instead to go with a native binding the iPhone APIs. It would not be a cross platform API and it would tie developers to the iPhone platform, but it would also mean that applications would look and feel native, and developers would get closer to the iPhone.

Creating a binding for the Objective-C APIs with .NET in the past has relied extensively on dynamic code generation, and this feature is not available on the iPhone (the kernel prevents JIT compilation from taking place). As we started doing the work to bind the low-level C APIs, Geoff started prototyping a new Objective-C/C# bridge that was specifically designed to work within the iPhone requirements.

By the time we had sorted out the foundation and the Objective-C bridge we had gained some fresh experience from binding the C++ PhyreEngine to .NET and we decided to create a new binding generator to simplify our life (I will blog about this new approach to binding creation in another post).

At this point, we started investing into supporting not only the device, but support the simulator. This would prove to be incredibly useful for quickly testing the code, without having to wait a long time to compile and deploy on the device.

The Developer Experience

At this point, we had enough to create mix-mode GUI applications (they were mostly Objective-C apps hosting Mono) and the pipeline was horrible: it involved using some 3 compilers, having 3 Mono checkouts and applying individual patches to all trees.

We were aware of how easy Unity had made things for their users, they had set the bar pretty high in terms of usability for us. Unity had some advantages, they could "debug" without deploying the code to the device, something that we could not really do ourselves.

We were still far from this.

We introduced a command that would isolate all of the complexities of creating simulator and ARM executables, the mtouch command.

With the mtouch command and the bindings complete, we started trying out the API by porting the Apple iPhone samples from Objective-C to C#. And in the process finding two things: C# 3.0 constructor initializers are a thing of beauty:

UIControl SliderControl ()
{
	var slider = new UISlider (new RectangleF (174f, 12f, 120f, 7f)){
		BackgroundColor = UIColor.Clear,
		MinValue = 0f,
		MaxValue = 100f,
		Continuous = true,
		Value = 50f,
		Tag = kViewTag
	};
	slider.ValueChanged += delegate {
		Console.WriteLine ("New value {0}", slider.Value);
	};
	return slider;
}
	

And also that the samples ported were half the size of the equivalent Objective-C programs.

As we were doing this work to iron out the kinks in the API design, Michael got started on designing the MonoDevelop support for the iPhone. This included the regular bits that you would expect like templates, building, running and deploying, but most importantly the Interface Builder integration.

Interface Builder produces an XML file that describes your UI, and it is able to generate some header files for you, but in general developers that want to refer to components in the UI and implement their backing store have to repeat the same stuff over and over. For example, controlling the contents of a label on the screen requires the developer to declare the same variable three times: 2 in the header file, and one in the Objective-C file (if you are lucky).

We took a different approach. We made it so that MonoDevelop would automatically generate a code-behind partial C# class for each Interface Builder file. This meant that to users the entire process would be transparent.

They would define outlets or messages, and those would just become part of their class. Intellisense and code completion would become available to them without any extra coding.

Posted on 14 Sep 2009


CodePlex Foundation

by Miguel de Icaza

Microsoft today launched the CodePlex Foundation a non-profit organization to promote the open source collaboration between companies and open source communties, projects and individuals.

This is another step in the right direction for Microsoft. I have been working on open source software since 1992, and back then a world where open source played a major role was a dream to many of us. Microsoft adopting open source licenses, releasing some of their code under open source licenses and being a better community member was the stuff of fiction.

There are still many things that I would like to see Microsoft do, and many things that I believe Microsoft has to change to become a full member of the open source community, but it is encouraging to me to see Microsoft evolve. I hope that the CodePlex foundation will help us continue to build bridges between our communities.

I am glad that I was asked to be part of the board of directors of the foundation. And to work together with some great advisory board.

I hope that I can last more on this foundation than I lasted at the FSF, where I was removed by RMS after refusing to be an active part of the campaign to rename Linux as GNU/Linux.

Posted on 10 Sep 2009


MonoDevelop 2.2 Beta 1: We go cross platform.

by Miguel de Icaza

MonoDevelop goes cross platform.

Since the beginning of time, man has yearned to get a cross platform .NET IDE. Homer's Odyssey described one man's effort to achieve such a thing. And it was not until today, September 9th of 2009 that the world can test out such a tool.

With this release MonoDevelop leaves its cozy Linux nest and embarks on a wild adventure into the hearth of MacOS and Windows. The MonoDevelop team made this one of their major goals for this release: to turn our loved IDE into a cross platform IDE.

If you are curious about the details, check out the What is new in MonoDevelop 2.2 page.

MonoDevelop on Windows

We are not only bringing MonoDevelop to OSX and Windows as a plain GUI port, but we are also providing installers, deep operating system integration and support for native debugging on each platform.

MonoDevelop on MacOS X

In addition to becoming a cross platform IDE, there are many new features in MonoDevelop.

For instance, MonoDevelop can be used to develop ASP.NET MVC applications on OSX and Linux and Silverlight applications on OSX and Linux.

Debugger

MonoDevelop now has integrated debugger support. Not only it is able to debug Mono applications, it also can work as a frontend to GDB to debug native applications.

In addition, on Linux it is possible to debug ASP.NET pages.

New Add-ins

New exciting add-ins: ASP.NET MVC, Silverlight and iPhone (for use with MonoTouch).

Policies

A common problem that we face as open source developers is that not every project uses the same coding style. Different teams use different coding conventions. MonoDevelop now supports policies to describe how files should be edited and what defaults should be used in each:

Editor Improvements

My favorite new feature is Dynamic Abbrev (Alt-/) a feature that we brought from Emacs and that fills me with joy. That being said, for the non-Emacs lovers there are plenty of features that you asked for, and that we implemented:

  • Extensive refactoring support. And I mean, it is extensive.
  • Code templates.
  • On the fly formatting.
  • Acronym Matching in Code Completion
  • XML Documentation Shown in Code Completion
  • VI mode for those users hooked up on VI commands, they can now use those within MonoDevelop.

Another pretty cool feature is the code generation support that is triggered with Alt-Insert. When you press Alt-insert it will popup a context sensitive dialog box that offers a few options of code that could be generated at this point: ToString methods, Equals/GetHashCode methods all based on existing fields and properties.

Why go Cross Platform?

Going cross platform means that developers will have the same tool across all of the operating systems they use: Windows, Mac and Linux.

.NET developers that have been enchanted by OSX will be able to continue developing software with their favorite programming languages while enjoying OSX and will be able to go back and forth between Windows, OSX and Linux as needed. This also means that they can work with developers in other platforms, regardless of the personal choices of other team members.

As many of you know, the number of contributors to a project is linked to the number of users of that project. By expanding our market presence from Linux, we expect to get contributions, fixes, improvements, bug reports, code and add-ins from developers in other platforms.

We intend to make MonoDevelop the Eclipse of the .NET community. Just like Eclipse became the foundation for Java development, we hope that MonoDevelop will become the foundation for .NET development, and hopefully for much more than that.

A multi-system IDE

We are not religious when it comes to supporting other programming languages [1]. We want to embrace not only .NET-based projects like Gtk#, Silverlight, ASP.NET, Boo, C#, F#, Visual Basic and Windows.Forms. We are also embracing other developer platforms like Python, C/C++, Vala, and we want to expand our presence to work with the Flash, PHP, Ruby, Rails, Flex and any other communities that need a cross platform IDE.

[1] we are just religious about the fact that C# is a better programming language to build an IDE than Java is.

Thanks!

This release could not have been possible without the endless nights and the collaborations of our contributors and all of the end users that reported bugs and gave us feedback.

Posted on 09 Sep 2009


Mono Survey Time!

by Miguel de Icaza

Is it that time of the year when I unleash Google Docs' Survey platform on the users of my blog.

Every once in a while people ask us "When will you support Mono on..." and our answer is usually "thanks for your feedback, we will carefully consider it".

The reality is that all we have at this point is a lot of anecdotal data. Since my previous surveys on Mono, Mono for OSX, Mono for the iPhone and Mono for Visual Studio turned out to be great tools to understand what people actually want, I have created a new survey.

In this survey, I want to know how much people are willing to pay for (or not pay) for Mono commercial support on a variety of platforms: Red Hat Enterprise Linux, HP-UX, AIX, Solaris on a variety of architectures.

Go to my survey

Posted on 08 Sep 2009


Mono/.NET CodeCamp in Catalonia, Spain

by Miguel de Icaza

The .NET and Mono user communities are working together in Spain to organize a joint .NET/Mono Code Camp. This Code Camp is going to be interesting because it is putting together two communities with very different points of view, but between which there is a lot of synergy. It will be a good chance to talk about Mono, Moonlight, MonoDevelop, MonoTouch and all the stuff we are working on.

Lluis just announced that the call for papers is ending this Friday, so not much time is left if you want to participate with a talk. There are more details in his blog post

Posted on 08 Sep 2009


GitSharp making progress

by Miguel de Icaza

Meinrad Recheis emailed me to inform me that he has forked the Gitty project (a project that was doing a line-by-line port of a Java version of GIT) and that the project is making progress on having a full C# based GIT implementation.

GitSharp source code can be downloaded from github and they are making sure that GitSharp works on both .NET and Mono.

I can not wait for a MonoDevelop UI for it!

Posted on 01 Sep 2009


MonoTouch Resources

by Miguel de Icaza

While I was gone, a pretty nice site called MonoTouch.infowas created that is aggregating all kinds of MonoTouch samples, posts, and discussions.

From the MonoTouch Bill Splitter page.

It is aggregating many of the samples being discussed in the tweetosphere and from the MonoTouch mailing list.

The samples are particularly useful as MonoTouch merges two worlds: .NET development and Objective-C programming on the iPhone/iTouch.

MonoTouch supports the Objective-C like setup where classes can respond to messages and you have to structure your code with MVC patterns. But it also supports the C# event-style programming mode, where developers can use lambda functions to hook up to interesting events.

You can also follow @monotouchinfo on twitter.

Posted on 01 Sep 2009


Silverlight/C#, Flash/ActionScript 3 and Canvas/Javascript

by Miguel de Icaza

Been following some of the discussion around Action Script 3 on the tweetosphere. Here are three implementations of the same model from Joa Ebert (he works on a fabulous Flash product for doing music that I absolutely love).

From his Flirting with Silverlight post:

Lately a lot of discussion had the ActionScript language as its focus. People start complaining about complex language features but I think they are great because the end user will benefit from that. Yesterday evening I had my very first test with Silverlight — and I am really impressed.

It took me a short amount of time to port the strange attractor to Silverlight. I agree that this is may be not a fair comparison because I know C# already but have a look at the source code. I make heavy use of type inference and the Matrix4x4 class has the plus, multiply and array-index operator overloaded. The code is more readable. And besides: it executes really fast. Faster than my heavily optimized ActionScript version. Imagine I would write var bleh = 1.0 in ActionScript. Framerate would drop to something like zero. But this is sad since there is no reason for me to write var bleh: Number = 1.0. A modern compiler should be able to figure this out. haXe can do it, C# can do it, OCaml can do it and lots of others as well.

Remember: This was my first time using Silverlight. To achieve the same result with Flash you have to be kind of an expert in strange player and language “features”. Now tell me again that the end user will not benefit.

Here are the three implementations:

Posted on 12 Aug 2009


C# 4's Dynamic in Mono

by Miguel de Icaza

C# 4.0 introduces the dynamic type into the language. The language will ship in Visual Studio 2010.

Once a variable is declared as having type dynamic, operations on these value are not done or verified at compile time, but instead happen entirely at runtime.

Marek has been working on Mono's C# 4 implementation and it is coming along nicely. Zoltan wrote a small "PInvoke" dynamic class using Mono's C# compiler that allows you to call C library methods like this:

	dynamic d = new PInvoke ("libc");
	d.printf ("I have been clicked %d times", times);
	

In this case "printf" is resolved at runtime to be a method in the "libc" library. This is similar to Python's ctype library in about 70 lines of C# leveraging LINQ Expression, the Dynamic Language Runtime and C#'s dynamic:

The code is:

using System;
using System.Dynamic;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using System.Threading;
using System.Linq.Expressions;

class PInvokeMetaObject : DynamicMetaObject {

    public PInvokeMetaObject (Expression parameter, object o) :
        base (parameter, BindingRestrictions.Empty, o) { }

    public override DynamicMetaObject BindInvokeMember (InvokeMemberBinder binder, DynamicMetaObject[] args) {

        var self = this.Expression;
        var pinvoke = (PInvoke)base.Value;

        var arg_types = new Type [args.Length];
        var arg_exps = new Expression [args.Length];

        for (int i = 0; i < args.Length; ++i) {
            arg_types [i] = args [i].LimitType;
            arg_exps [i] = args [i].Expression;
        }

        var m = pinvoke.GetInvoke (binder.Name, arg_types);
        var target = Expression.Block (
			    Expression.Call (m, arg_exps),
			    Expression.Default (typeof (object)));
        var restrictions = BindingRestrictions.GetTypeRestriction (self, typeof (PInvoke));

        return new DynamicMetaObject (target, restrictions);
    }
}

public class PInvoke : DynamicObject {
    string dll;

    AssemblyBuilder ab;
    ModuleBuilder moduleb;
    int id_gen;

    public PInvoke (string dll) {
        this.dll = dll;
    }

    public override DynamicMetaObject GetMetaObject (Expression parameter) {
        return new PInvokeMetaObject (parameter, this);
    }

    public MethodInfo GetInvoke (string entry_point, Type[] arg_types) {
        if (ab == null) {
            AssemblyName aname = new AssemblyName ("ctype");
            ab = AppDomain.CurrentDomain.DefineDynamicAssembly (aname, AssemblyBuilderAccess.Run);
            moduleb = ab.DefineDynamicModule ("ctype");
        }

        // Can't use DynamicMethod as they don't support custom attributes
        var tb = moduleb.DefineType ("ctype_" + Interlocked.Increment (ref id_gen) + "_" + entry_point);

        tb.DefinePInvokeMethod ("Invoke", dll, entry_point,
			    MethodAttributes.Static|MethodAttributes.PinvokeImpl,
			    CallingConventions.Standard, typeof
			    (void), arg_types,
			    CallingConvention.StdCall, CharSet.Auto);

        var t = tb.CreateType ();
        var m = t.GetMethod ("Invoke", BindingFlags.Static|BindingFlags.NonPublic);

        return m;
    }
}

public class Tests
{
    public static void Main (String[] args) {
        dynamic d = new PInvoke ("libc");

        for (int i = 0; i < 100; ++i)
            d.printf ("Hello, World %d\n", i);
    }
}    
	

You can download the C# 4.0 Future document for details.

Mono's C# 4 compiler so far implements optional parameters, named parameters, has support for the new covariant and contravariant specifiers and the dynamic keyword is evolving very quickly (as shown by the example above).

If you want to test drive Mono's C# 4.0 compiler, you need Mono from Git and you must pass the "--enable-profile4=yes" argument. Once you do this, the new compiler will be installed as dmcs on your system.

Nikhil has a nice sample that shows JSon integrated directly into C#.

Posted on 11 Aug 2009


C# Sqlite

by Miguel de Icaza

Noah Hart did a line-by-line port of Sqlite to C# and has uploaded the code to code.google.com/p/csharp-sqlite.

The frequently asked questions on the web site talks about performance (it is about 5 times slower than native code, but still, it can do 1.5 million selects per second, 300k inserts per second).

Still, not bad for a line-by-line port; Folks on the #mono channel on irc.gnome.org a couple of days ago were commenting on the possible ways of tuning it up by not forcing the C way where the C# way would work just fine.

The potential for this library is huge. It could be used for ASP.NET servers running in medium trust mode, or it could be used by Silverlight applications.

It seems like Tim Anderson is attempting to remove all the P/Invokes from it to make it run on Silverlight (the P/Invokes are mostly used for doing file-level locking; Again part of the line-by-line history of it).

Posted on 06 Aug 2009


« Newer entries | Older entries »