MonoDroid: IronPython on Android?

By Michael Foord -
MonoTouch is a cross-compiler IDE and toolchain for the iPhone OS series. It allows you to write iPhone / iPod Touch / iPad applications with .NET languages like C# and take advantage of nice features of the .NET framework (actually Mono) like the extensive class libraries, proper garbage collection and so on.

Because of the rules against interpreters and code generators MonoTouch didn't include the System.Reflection.Emit apis that are needed for Dynamic Language Runtime languages like IronPython and IronRuby. Despite this restriction  MonoTouch was a victim of the controversial Section 3.3.1 of the iPhone developer agreement that requires iPhone apps to be written in objective-C, C or C++. (Modern developers who prefer the reliability of garbage collection based languages need not apply...)

Apple's main goal seems to be sticking two fingers up to Adobe and banning their Flash cross compiler, but other tools like MonoTouch are collateral damage. If there was ever any doubt about whether you could write iPhone apps in Python (Python and objective-C are both running fine on jailbroken iPhones) that question has been decisively answered. The Adobe Flash cross-compiler does introduce an intermediate layer between your application and the device - the UI won't look and feel native and using any new APIs introduced in OS updates will be dependent on Adobe updating the tool. This is the reason that has been cited as the motivating factor for section 3.3.1. Although MonoTouch has a "runtime" providing some of the .NET features you still compile directly against the iPhone OS APIs: your UI can be native and there is no intermediate layer. Despite section 3.3.1 MonoTouch is still allowed for companies distributing internal apps and not using the app store (something that became possible in a recent OS update), but it's use is now doubtful for general app creation.

Fortunately the iPhone isn't the only game in town, you may possibly have heard of the google mobile OS called Android. Novell, the folks behind Mono and MonoTouch, have been creating an equivalent tool for Android and Miguel de Icaza announced it in a recent blog entry:

We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
Most interesting is their feature list:

  Here is what you can expect from Mono on Android:
  • C#-ified bindings to the Android APIs.
  • Full JIT compiler: this means full LINQ, dynamic, and support for the Dynamic Language Runtime (IronPython, IronRuby and others).
  • Linker tools to ship only the bits that you need from Mono.
  • Ahead-of-Time compilation on install: when you install a Monodroid application, you can have Mono precompile the code to avoid any startup performance hit from your application. 
So, it looks like it will "soon" be possible to write applications for Android using IronPython - great!

Comments

  1. Laurence Rowe5/22/2010 11:38 pm

    For Python developers, I'm not sure what this gives over and above CPython on android in the ASE - it will still have to use RPC to access the java based APIs. There was an attempt to port Jython to Android, but I believe this was abandoned as Dalvik (Android's JVM) did not do JIT compilation. Now there's a JIT in Android 2.2, maybe that will be revisited.

    ReplyDelete
  2. Michael Foord5/22/2010 11:43 pm

    I doubt MonoDroid uses RPC to call the Java based APIs - I *expect* that instead it compiles to Dalvik bytecode and calls them directly.

    ASE is not a way of writing full applications but a scripting environment instead. Running CPython natively on Android would be interesting, but you then still have to have a way of calling the APIs. IronPython compiled by MonoDroid sounds like a great way to bridge that gap.

    ReplyDelete

Post a Comment

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

By Michael Foord -
An intriguing blog entry about an Adobe experimental project. It is a C/C++ cross- compiler for the flash player and AIR. This means that you can (will be able to?) cross-compile the Python / Ruby/ lots of other language runtimes and then run them in Flash. The blog entry contrasts this approach to the DLR which requires the re-implementation of dynamic languages - hence IronPython and IronRuby. The project is already beyond proof-of concept, they even have Quake III cross-compiled and running in Flash. Extending Adobe Flash Player and AIR with C/C++ Cross-Compiler Quake 3 has already been ported to managed code , but this is even more impressive. Whether the Python interpreter can be cross-compiled to run on top of another runtime (with completely different basic types), without changing the language semantics at all, has yet to be proved - but it is a very interesting project. (It also means that Python/Ruby will possibly be enabled only by additional optional downloads - but don'
Read more

Should Python Projects Support IronPython and Jython?

By Michael Foord -
The maintainers of the Spring Framework for Python ( Spring Python ) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies? This question sparks a good discussion and is relevant to many other Python projects and applications: Need for supporting IronPython, Jython? " One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing. " " For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this
Read more

Further Adventures of the Debugger

By Michael Foord -
Harry Pierson (Microsoft IronPython PM) has been experimenting with writing an IronPython debugger ( ipydbg ) on top of the .NET MDbg APIs. When we last left him , he had implemented Just My Code (JMC) support allowing you to step into IronPython code. Since then he has made a lot of progress including a colourful REPL (interactive console) and solving some difficult problems around getting to real values behind boxed IronPython variables (needed for showing local variables). He has blogged extensively on what he has been up to (more recent posts last): Showing Source Code Colorful Console IronPython ConsoleColorMgr (the colorful console code pulled out into a separate IronPython module) A Little Hack...err...Cleanup Getting Local Variables Displaying Values Command Routing Getting Arguments REPL Console A lot of functionality is now present. In the command routing entry Harry outlines the seven commands supported by the debugger so far: Continue, Quit, Show Stack Trace, Show Locals,
Read more