News

Miguel de Icaza on MonoTouch

Miguel de Icaza is Vice President at Novell and head of the open source Mono Project, which builds tools and frameworks for extending .NET-compatible applications across platforms. Earlier this year, the Mono Project released an updated version of its MonoTouch tool for building .NET-compatible that run on the Apple iPhone and iPad devices. We spoke with de Icaza just a short time before Apple announced it was loosening developer restrictions from its AppStore licensing terms.

Mono has been very busy in the mobile space? Why?
It was a fairly fragmented space, both the embedded space and mobile space. For many years, most mobile devices were not very mobile -- you could not carry them because they weren't very practical.

We are now shipping fairly sophisticated devices, in both CPU power and the graphics chip sets. That means you can write the kind of applications that are more interesting. I don't think anyone foresaw that phones were going to be this powerful right now. We kind of went where the users went. The movement to build mobile applications took everyone by surprise."

On the one hand, the diverse nature of mobile platforms seems to create a real opportunity for Mono, MonoTools and MonoTouch. On the other, I suspect there are plenty of challenges involved. Can you talk about some of the most difficult aspects of enabling multi-platform support for targets like iPhone and Android?
That actually a good point because... um, this is something that we kind of learned the hard way. We've supported in the past some other embedded systems. But the iPhone is the first time we went through the whole length of attributing the platform.

You don't have this whole toolchain that is Visual Studio integration. You don't have the pipeline where you create a solution and five minutes later you have the application running. When it came to the unique features of the platform, like the user interface, accessing the GPS, accessing the gyroscope or the compass, the camera, the microphone. Instead of trying to come up with an abstraction layer, we kind of created a native binding for these things.

What we did with MonoTouch was basically provide a one-to-one mapping for C# developers to access the API. When you are building UI code or when you are building in the mobile app for the iPhone in particular, it feels very, very different from if you are building a Windows Phone 7 app or a Windows Compact Framework app. All the user interface and all of the sensors, and where they can program these things, it is completely different.

The platform enablement was really the key driver for MonoTouch. That's what made it stand out in comparison with things that we had done in the past. We are trying to replicate that now with Android, with Mono on the Android as well.

So the Android solution will be very similar to the MonoTouch model?
Absolutely. We built a platform called MonoDroid and what it does is it exposes the native Android API to the C# world. So again, every time you want to deal with a sensor or interface with a native operating system or display something on the screen, you would go through an API that is very specific to the Android platform. So far we haven't tried to do any platform abstraction.

They want to have mobility across platforms. They want so they can bring Windows Phone 7 and Android and the iPhone. They design their software so there is s split between the core of their program -- the soul of the program -- and the user interface. You have to basically rewrite the UI with the native APIs on the platform.

Has Apple had anything to say about the latest MonoTouch version? Do you work with them directly on these releases?
No, we don't work with them at all. We did contact them when we launched the product, and they said they never endorse or provide quotes for any third party products. Strictly no collaboration there.

We do have Mono for the iPhone, we will have Mono for Android, we have it running on Meego, we have it on the Playstation, the Wii, on the Mac, on Linux and mainframes. We like to think that we are fairly independent when it comes to which platforms we support.

So it's not at all unusual to start supporting a platform without the buy in of the platform owner?
No. When we started Mono with Mono for Linux, we had absolutely no relationship with Microsoft. And I think that some people at Microsoft liked it, from the early days, but that some people didn't like it from the early days.

Microsoft didn't have an official position about it back in 2000 or 20001. But today we have a fairly good relationship with them and we collaborate with them on Moonlight, which is our Silverlight implementation for Linux today. We're hoping to put it into other systems and devices in the future.

What advice do you give developers hoping to target iPhone, Android and other mobile targets from a single code base?
You have to split your business logic from your presentation layer, right? You want the same app to run for multiple UIs. You really want to split that up. And it's helpful to split that up in more ways. But that's a good way to having your business logic, your transport, your algorithms and so on to be completely UI neutral, and build the UI pieces after that.

The other thing we do see a lot are people who port enterprise apps that have all kinds of computations and processes in place that are already being used by their clients or they already had their business logic separated as a separate library, and they just take those and run those libraries on MonoTouch or MonoDroid. They work on that and then they put on a UI.

I would say the one exception where you can ever reuse both the UI is if you build applications with OpenGL. If you have OpenGL applications we work the same API between Android and the iPhone, so at least you'll get that. You won't get that ability with Windows Phone 7, since Windows Phone 7 uses a different set of graphics APIs. But you can at least do that between those two platforms.

What's next from the Mono Project?
Right now we're coming down on Android. There's still a number of open issues [but] right now our focus is going to be on making sure that it's fully baked, and that it really supports the new APIs that are outstanding.

We have to make sure we have parity for every single API that developers need and that iPhone developers are never at a disadvantage with an Objective C developer in terms of API [support]. We are doing that. We're doing Mono for the Android, and it's still premature to say which other platforms we're going to support. For one because I don't know what the next big one, or whatever platform people are really interested in developing for.

One thing that we hear is that when people port applications from MonoTouch or Android to Windows Phone 7 is that we exposed a larger surface area than Windows Phone did. So MonoTouch and MonoDroid, at least from a core library perspective, are a superset of what's available on Windows Phone 7. So one of the things we are thinking of doing is extracting from our source tree the libraries and features that people are using on MonoDroid that are not present on Windows Phone 7. So it's kind of an add-on pack, and API blade if you will, that will expand a little bit the functionality you get out of the box in Windows Phone 7.

What challenges did the .NET Framework 4 release pose to the Mono Project?
The reality is we like what Microsoft is doing in the framework. Whenever they push something we really like, we try to get it implemented. The next release [of Mono] includes a lot of the .NET 4 bits and .NET 4 APIs. A lot of the things are there except really big things like Entity Framework.

That was achieved either by people like my team, people in the open source community helping us out, or this is the best part, Microsoft open sourcing key pieces of the technology to the public.

In Mono 2.0, we actually bundled a number of Microsoft libraries that they open sourced. One of them is the Dynamic Language Runtime. And also the C# Dynamic Engine -- not all of it, but some of it. We had to write some pieces there. Also the Managed Extensibility Framework for building composable applications. The OData client API -- that was all open sourced. ASP.NET MVC 1 and 2 were also open sourced. We certainly had to do the ASP.NET 4.0 core, but ASP.NET MVC we just were shipping the exact same bits as Microsoft is shipping. We had to make a couple of changes here and there to make them work for Mono, but I think the changes were minimal.

It's challenging, but you know, it's not the end of the world. It's actually really fun.

What do you say to developers sitting on the fence with MonoTouch today?
It feels like both the iPhone and Android, and the Mac, have had a fairly big resurgence in the last few years. I feel that we no longer have to be convincing developers to move to these platforms. There was a time when we said, 'Hey, please make your software run on Mono. It will run on Linux.' There was a little bit of begging going on there.

Certainly the iPhone, Android and the Mac made our job a lot easier. We don't really need to pitch these anymore. Our pitching has become a lot easier. But it's still a complicated matter. But at least from the client we are no longer in kind of a begging position we were a few years ago.

About the Author

Michael Desmond is an editor and writer for 1105 Media's Enterprise Computing Group.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube