 |
|||||||||
|
|||||||||
|
|
Those of you who have been reading my blog for a while know that I'm not always just about .NET - I'm a pretty huge iPhone guy as well. In fact, I'm a fan of all technologies and programming languages that don't suck, regardless of who makes them or on what platform they run.
At one point I was actually thinking about writing a book for .NET developers to learn Cocoa but other plans, time constraints, and life issues all got in the way. I have posted countless times comparing the worlds of Cocoa and .NET and have twice presented at Apple's WWDC comparing both the desktop and mobile programming environments of Apple and Microsoft. So you can imagine the raw, unfiltered, pure geek joy that coursed through my veins when I heard about Monotouch, a programming library coupled with an IDE (MonoDevelop + Interface Builder) that would let me write my iPhone applications using C# and the .NET Framework (the mono version).
To get Monotouch working you're going to need the following:
Understanding all of the plumbing of how this works requires a time investment that I just can't put forth right now. So, for now, assume that little magic elves within the MonoDevelop IDE perform post-build tasks on your compiled mono application that can then convert it to native iPhone code. When you're working with C# classes like UITableViewController, all you're really doing is telling the post-compile steps that your final C type in the native app will be a UITableViewController. It's smoke and mirrors, but it's damned powerful smoke and mirrors.
So what's it like to build a monotouch application? It's actually pretty similar to building a regular Cocoa Touch application. You create a new project in monotouch (there are several really good "hello world" tutorials available on monotouch from their site). Drag UI elements into your XIB using Interface Builder and, here's where some of the magic starts, create outlets and actions and link your C# code to your interface builder UI elements. I am pretty sure portions of my brain liquified when I first created a C# view controller and ctrl-dragged to link UI actions to the controller.
This is where many of my avid .NET readers are going to think I've simply flipped and gone off the reservation...
Despite the fact that I can now quickly and easily create C#/.NET classes and use them to power my iPhone applications, which gives me access to things like WCF and the absolutely, definitively better XML libraries of .NET... I am not going to be using monotouch for real application development.
ok, I'll pause here to let you all stop shouting, "OMFGWTFTRAITOR!!!1"
A little history: I learned C# in 2000 on .NET 1.0. I published my first book on the .NET Framework in 2001 and have been writing blogs, books, articles, and flaming truckloads of code on this framework for the past 9 years now. If there ever was a human being on the planet who should by all rights reach out to and lovingly hug the Monotouch box - it should be me. However, all of that time and experience has made me wary of layers of abstraction. I learned how to write Cocoa for the Mac when Leopard was in beta. I found the learning curve steep, and painful. I felt like I was being deprogrammed - but it was a good thing. If you remember my blog posts from that era, you'll recall that I felt like I was growing as a programmer and architect. My skills in .NET increased dramatically as a result of the enlightenment that I found while learning Cocoa and Objective-C. My .NET skills also increased (though not as dramatically) when I suffered through writing enterprise Java applications.
I literally spent hours trying to write down the list of reasons why I didn't want to use Monotouch and some of them were extremely valid reasons concerning the fact that monotouch is always going to be behind the leading SDK revision from Apple and blah blah yadda yadda... The bottom line is I just love the way it feels to write Objective-C and Cocoa code. Period.
Bottom line:
[self heart:Cocoa];
That said, there are a thousand reasons for people to use monotouch, including the ability to re-use .NET (mono) code across the client (iPhone) and server as well as to allow .NET developers who have absolutely no experience with Cocoa or Objective-C to quickly and easily get rolling building iPhone apps. In the real world we don't always have the luxury of learning new languages and environments - if you're a .NET developer and your boss tells you write an iPhone app for your company and to do it in 3 weeks or you're fired - you're going to use Monotouch (and so would I). I have the luxury of knowing both .NET and Cocoa and so I can pick and choose. Knowing both, I'll be writing my iPhone apps in Cocoa and the back-end servers that support them in .NET.
Can you integrate the .NET code with normal cocoa code? For instance,
suppose you had some library written in C# that you wanted to use on the
iphone. can you build it, then link against it from ObjC?
I am a guru with Cocoa and a novice with .Net. I often feel like .Net is
making it hard for me to accomplish anything - particularly nice GUI
refinements. However, I just assume that I haven't learned how to use the
framework effectively. Many newcomers to Cocoa express the same feeling
until they learn the Cocoa patterns/idioms and receive the advice to "stop
fighting the frameworks" for the hundred and fifth time. You are an expert
with .Net and still say you love the way it feels to write Objective-C and
Cocoa code. Is it possible that I will never feel comfortable with .Net
after literally decades of using Cocoa and it predecessors? Why aren't
there any important shipping applications with WPF or have I just missed
them?
The vast majority of "shipping" WPF applications are being used for line of
business applications, internal apps, or for media and demo systems. Hands
down WPF is way better than Windows forms. The problem with WPF is that
Silverlight is outpacing its development, and Silverlight is
cross-platform... this is giving rise to a huge increase in the number of
"Shipping" applications written in Silverlight. As for never getting the
hang of .NET, that all depends on your ability to switch perspective. If
you can think like a .NET programmer while working on .NET and think like a
Cocoa programmer while working on Cocoa - things will be great. The problem
comes (IMHO) from trying to make .NET programmers think like .NET
programmers when working on Cocoa - hiding the truth (and beauty) from
them.
