BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Wally McClure on the Future of MonoTouch and Mono for Android

Wally McClure on the Future of MonoTouch and Mono for Android

Bookmarks

Wallace B. McClure is the co-author of Professional iPhone Programming with MonoTouch and .NET/C# and the soon to be released Professional Android Programming with Mono for Android and .NET/C#. Our interview took place prior to and just following the announcement that Xamarin would be taking over maintenance of Mono from Attachmate.

InfoQ: It’s been two months since Miguel announced the Attachmate layoffs and the creation of Xamarin. What’s your opinion of the situation?

The first question was asked on July 16th, 2 days before the public announcement of Xamarin and Novell parternering.

Wally McClure: As a .NET developer that wants to target mobile, there are a number of issues that I have to consider. The biggest question I have is "How do I target mobile platforms that are going to make me the most money?" For me, that means "How can I target the iPhone and Android?" The people that I talk with are asking about iPhone always and Android sometimes. How can I as a .NET developer easily and quickly target these platforms? I could go and build an HTML5 application, but a web app doesn't target all the features of a device and customers are asking about native applications, not web applications. HTML5 applications have their place, but they won't solve all the problems for every customer everywhere.

As a .NET developer, I have some options for writing a native application on a device. I can learn ObjectiveC/Java. Learning each of these languages takes time as well as the time required to learn the new development IDE. While developers like to think that learning a new language is easy, I have found that my reality is different. Learning a new language and IDE is not something you can pick up in a couple of hours over a weekend. I can use other products that will take an HTML app and allow you to use that as the basis for a native app, however, I have always been concerned about cross platform vs. native apps, so I continued looking.

Now, I knew much more than most people, because while I am a developer, I also pay attention to various financial networks. In late 2009/early 2010, I heard about issues at Novell and that they were looking for a buyer through a CNBC report. For me, this meant some level of trouble was possible. In addition, I've known that there had been some friction between Novell's business units. It’s into this that the Novell firings and Xamarin startup have occurred. A few thoughts on this are:

  • The marketplace has not abandoned MonoTouch. I've talked with some paying customers. Some have put MonoTouch/iPhone on hold; however, not everyone has abandoned MonoTouch. Some are continuing on with iPhone and MonoTouch.
  • Nothing stops the existing MonoTouch product from working today. I can create an app and run it on the iPhone and iPad today. It works and I expect it to work for a while. They think that they are going to be able to produce a product within 3 months of their beginning development. They started approximately June, so this would be in September, which is also the timeframe for the next version of iOS.
  • There is risk associated with MonoTouch. For example, there may be copyright concerns in the future regarding Xamarin and their iPhone .NET product. This is valid. I've talked to some people closer to the legal aspects than I. These people question:
    • Xamarin would expose themselves to such risk. Miguel de Icaza has already spoken for Xamarin saying that they feel that they are covering themselves in this area.
    • The API for MonoTouch will be defined based on the iOS APIs. The same is true on the Android platform. There is most likely little risk of copyright issues due to this.
  • I personally used the first 2 weeks after the announcement of the Novell firings to revisit ObjectiveC and Java development. I came to the same conclusion that I did in 2009. ObjectiveC is not for the faint of heart. It would be a significant learning curve for a .NET developer. The only way that one is going to be proficient in it is to invest significant time. For those of us that have significant work in other things, this is barrier to entry.

After reviewing these issues, for me, MonoTouch and Mono for Android make the same sense that they did two years ago.

InfoQ: When we started this interview it was just before Attachmate announced that it was giving Xamarin a perpetual license for "Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio". Now that the legal issues are settled, do you see any barriers to adopting Mono for iPhone and Android?

Wally McClure: It has been an amazing week. One week ago, I woke up to a tweet pointing at http://ios.xamarin.com and we found out that Xamarin had obtained a perpetual license for the intellectual property for these tools. The week ended with my attending the Monospace conference and getting 2 full days of information from Xamarin as well as interacting with other attendees. I spoke with a potential client last week that was interested in MonoTouch that has just made a commitment to iOS and is using .NET for their custom business applications. They are a Fortune 500 company. Now, realistically, some companies are still concerned. I think that the legal issues with regards to Attachmate have been resolved. It is my understanding that there will be some upcoming agreements with some other companies that will further reduce legal risk and that these will be announced in the coming weeks. From a legal standpoint, I don't see any issues at this time. Aside from some type of perceived unknown risk, I don't see a reason to hold off on working with MonoTouch and Mono for Android. Personally, I was full speed ahead over the last 6 weeks and I'm continuing in that.

One issue that I have been hearing something about is "MonoTouch and Mono for Android have bugs, so we shouldn't use them." Every piece of software has some type of bug. Android and iOS are continually being updated. Problems in them are being fixed all the time. Xamarin is going to be updating their software regularly, just like they have been doing over the past 24 months. When a bug is found, it’s fixed in their trunk, and it is packaged with their next update. They have been pushing updates out fairly regularly before, so I suspect that this will happen again. These updates occur about every 2-3 weeks or so. The upside for this type of deployment is that you don't have to wait months for a service pack, you get the update fairly quickly and you are able to add value to a solution quickly. As we all know, end users get sick and tired of waiting.

InfoQ: Is there anything that you feel MonoTouch and Mono for Android do especially well?

Wally McClure: Ideologically, they open up the two most popular mobile platforms to the approximately 6 million .NET developers. For me, as a .NET developer, I was trying to figure out how to get on the iPhone back in early 2009. The announcement of MonoTouch was a godsend. I still had to learn the specifics of the platform (platform-isms), but I didn't have to learn a new language. In this case, ObjectiveC. For me, this was a big win. The combination of the iPhone-isms and learning the nuances of ObjectiveC just seemed like an almost insurmountable mountain to climb. Now, I still have to get a Mac, and I have to use MonoDevelop for my development, but this was still worth the price of entry. Being able to make http web requests to call a service and get results back and then process the results using LINQ and have that same code in so many places is a huge win.

From a technical standpoint, I look at some of the basics. I read a certain newspaper's iPad version every morning. I have found it to be rather cranky with numerous crashes. I'm assuming that the problem is some type of pointer arithmetic or memory utilization. Having to worry less about memory with the garbage collector is valuable as well as not having to worry so much about pointers.

Another feature that I think is an advantage is the fact that they are "true to the platform" that they are running on. Basically, this means that they create a C# callable layer between your code and the underlying operating system. You still call into the native APIs on the platform, just in a C# callable way. This is a big win for developers. While I would recommend several books on MonoTouch and Mono for Android, it is entirely possible to learn Mono for Android by starting with an Android book on Java. The advantage to this is that they aren't creating a generic container for user interface controls. Users get the exact same controls as everyone else on the platform. A MonoTouch application looks exactly the same as an ObjectiveC application. A Mono for Android application looks exactly the same as a Java application running on Android. For users, this a big win.

InfoQ: Likewise, what areas need the most improvement?

Wally McClure: Software is never done. There is always something that can be added, fixed, improved, whatever. With MonoTouch, there are a few items that don't work properly. For example, development on Mac OSX Lion is currently problematic with MonoDevelop. This needs to be resolved and will be resolved over the next few days. There is support for iOS 5 beta that will need to be added. I'm sure that there are other things as well. These aren't really big concerns as I write this on July 25. I feel confident in the MonoTouch team to add them in fairly short order.

Mono for Android is a fairly new product. It was released in April and had some rough edges. Given the track record I saw with MonoTouch, the Mono for Android team will resolve these issues. These issues were:

  • Debugging an application in Mono for Android. For a long time, I've been talking about the debugger and the problems I have been having. I spent about 1 1/2 hours with two guys on the Mono for Android team and the person in charge of the Mono debugger. We were able to repeat the issue and they have a reproducible test case. This is going to get resolved in short order, most likely in the next update or two.
  • Support for mapping, Android Honeycomb, and third party libraries. As it exists right now, there is no support for third party libraries in Mono for Android. This means that interacting with maps is a problem as well as support for Android Honeycomb tablets. I worked with the person handling the issue, and he explained the issue that they found and how they are tackling this. They will be updating the product, most likely in 2-3 releases to resolve this problem.

Basically I am saying that the technical issues are solvable given some time and patience. My personal suggestion is that .NET developers that want to jump into iPhone and Android development should start using MonoTouch and Mono for Android right now. These issues that I have mentioned are small potatoes compared to getting started, learning the specifics of development on the devices, and getting used to the new development methodologies that you have to spend time with.

InfoQ: During the MIX conference Miguel announced a prototype for Moonlight on Android phones/tablets. There are three possibilities here:

  1. Out-of-browser Silverlight applications repackaged for the Android marketplace.
  2. Windows Phone 7 applications repackaged for the Android marketplace.
  3. In browser Silverlight applications can compete with Flash.

Do feel that any of these possibilities are worth pursuing?

Wally McClure: Silverlight/Moonlight didn't get a lot of discussion at Monospace. Given that these were early products when they were being discussed at MIX and then the changes to Xamarin, I would recommend against waiting on cross platform Silverlight to solve this development problem. At Monospace, I learned about some other tools that I am going to be looking at to help in this area. These tools were incomplete at the time of the conference, but I am hoping to hear more about them very soon. I think the best thing to do is for .NET developers to jump into MonoTouch and Mono for Android. This will teach you about the specifics of the platforms. Dive in, the water is definitely warm.

InfoQ: Do you have anything more to add?

Wally McClure:

  1. I have been through 3 situations where Mono has been declared *dead*. Each time, I have found the reports of its death greatly exaggerated. For me, there is no more risk in Mono than there is using Silverlight, .NET, or HTML5. There are twists and turns along any journey. There is always someone that wants to scream out that we're going the wrong way. I find with a little patience, that these types of issues are resolved.
  2. MonoTouch and Mono for Android are really good products. They do work. If you are a .NET developer that needs to get on the iPhone and Android immediately, then MonoTouch and Mono for Android are great products to do so with. There are multiple books out on MonoTouch (mine as well as others). Our book on Mono for Android will be out this fall. I'm going to have a video series out soon through AppDev on MonoTouch. All of the development magazines will have coverage of MonoTouch and Mono for Android this fall. The community for these products is growing rapidly.

About the Interviewee

Wally McClure specializes in building applications that have large numbers of users and large amounts of data, as well as user interface specific technologies, such as Ajax, iPhone and Android. He is a Microsoft MVP, ASPInsider, and Author. His company (Scalable Development, Inc.) has courses in iPhone/Monotouch and Android/Mono for Android programming. Wally has authored books on Monotouch and Mono for Android amongst his eight books for Wrox.

 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT