Designing and Developing Cross-Cutting Features
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.

Posted by Jonathan Allen on Aug 01, 2011
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:
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:
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:
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:
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.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
Alex Russell talks about the shortcomings of the web platform and how it is evolving in order to adress them. He also explains about how browsers are improving and shares his vision on things to come.
Jeff Lindsay discusses creating distributed and concurrent systems using ZeroMQ – a lightweight message queue-, and gevent – a coroutine-based networking library.
Brian Ketelsen introduces Skynet, a platform for polyglot, distributed and composable services that communicate with each other over RPC/JSON.
Carin Meier tells the story of Alice discovering Monads, meeting three types of monads – Identity, Maybe, State-, and learning how to implement them in Clojure.
The need for agile, queryable, reliable, scalable storage without the pain of SQL schema migration is real. This article uses MongoDB to introduce NoSQL concepts to Java, PHP, and Python developers.
Jérôme Giraud introduces Wink Toolkit, an open source mobile JavaScript framework for HTML5 web or hybrid apps, showing widgets and interactions.
Greg Wilson and Christophe Coenraets demo Adobe Edge, a motion and interaction tool, CSS Regions and Shaders, and PhoneGap.
No comments
Watch Thread Reply