Introductions

You know what I hate about tutorials on Xamarin? They either assume you want to do exactly what they're doing, or they very carefully lead you by the hand to a place where you can do one thing really well, but have no idea how to integrate it into the rest of a finished app.

My goal here is to help you really draw the owl in part by capturing the lessons I'm learning about Xamarin as I'm learning them. I'm a decent C# coder, and have primarily been working with Microsoft stacks since 1998. But I'm also a Mac fanatic, having written for xlr8yourmac.com, Inside Mac Games, even a tiny bit for one edition of the Mac Bible.

My bias here is to create iOS apps first, and then see where code reuse takes us. Here are some tentative post topics.

1. First, I'll talk about how I picked the first application I was going to write -- and how I changed my mind twice.
2. Then, I'll talk about how I've split up my code. I'm always surprised when I hear people say that they have about a 40/60 or 50/50 split of UI/business code in a Xamarin app, and I'll show you the way I've been partitioning my code using a very thin console application project to test my business logic before coupling it with native UIs.
3. Then we'll look at a few different ways to create a UI for iOS. I'm really afraid iOS 8 and its new devices (ie, the iPhone 6) are going to complicate this very quickly.
4. I'll also take some time to look at writing and hosting web services. I've got one set up and running now, and managed to do it in one late night's worth of free time.

At the end, the hope is that we'll have walked through a pretty simple iOS MonoMac app, cradle to version 1.0 grave, detailing as we go along all the steps needed to create the app in Xamarin, including not only technical howtos but the business requirements of getting set up on the iOS Mac App and other stores. I mean, heck, for $19, iirc, you can start throwing apps on the Windows Phone Store now. (Course they were apparently paying folks a Benjamin per app not that long ago.)

I'm still doing this as a moonlighting project, so now guarantees on publish dates. As soon as I think I've figured something out well enough to share, and can find the time to share it, I will.

If you're just interested in the what and why, you can stop there. This is a blog showing how to draw an owl in Xamarin. If I'm lucky, I'll finally catch Mono. If you want more backstory, feel free to keep reading along.

---

So the first question, if you primarily want to write an iOS app, is why don't you start with Objective-C and/or Swift? For me, it's all about the platforms. I've always been interesting in picking viable technologies that would help me maximize reuse, and I really don't want to be limited to iOS, or even iOS and OS X.

I've actually tried a few different "write once, use everywhere" technologies, initially naively hoping to write The Great Email Client. At first, I wrote apps in Java, including a shareware email application for email digests. Later, I tried out REALbasic. Java support on the desktop turned out to be a dead end, and I never really felt REALbasic's IDE was up to snuff. I eventually stopped trying to force a desktop app and put my "at home" time into php/MySQL contracting, which was both fun and paid a few discretionary bills.

Enter Mono. It was exciting enough just to consider using C# to target OS X, Windows, and Linux, but at first, Mono's UI toolkits were really, really weak. Picking a UI toolkit for Mono has always been a bit of a pain, but before Xamarin allowed us to easily connect to native UIs, there really wasn't much you could do about it. Banshee is probably the best one could do with the old Mono toolchain, and GTK#, to me, just isn't quite good enough to consider marketable -- and the Windows.Forms port to Mono is, though really cool, to be kind, incomplete. You can use it to create some simple crossplatform utilities, but that's about it.

Xamarin seems to fix all of this for us with one smart trick: Nearly unfettered access to native UIs. Now we're on to something! The best part about the Xamarin setup is how it all but forces you to separate your code's interests. Business logic has to stay out of the UI, because the UI has to be modular. So you get possibly the best combination of "write once, run anywhere": Completely reuseable code, until you should've been writing for the target platform anyhow.

We get LINQ and apps that behaving natively, because they, for all purposes, are.

Which is all just to say that I want to write code that targets just as many platforms as possible as efficiently as possible, and it looks like Xamarin's a great way to do it where Java and REALbasic weren't. Honestly, you can use the same business logic backend for iOS, OS X, Windows, Windows Phone, and Android -- you could even throw in WCF, .NET MVC, and friends. That's pretty impressive.

So let's catch some Mono.