Objective-C Here I Come!
Have I blabbed enough about the PaceMaker app I released for Android yet?
First month of sales are over, and it was much better than I had expected. About 75 purchases in the first 30 days. Not a huge amount, but that is almost with no advertising, most people who found the app found it in the market.
So what is the next step for PaceMaker?
Well, with the iPhone coming to Verizon this month, I think it is pretty obvious that it is time for the iPhone version.
Only problem is…
I know nothing about iPhone development!
Well I didn’t last week, but I am slowly learning.
I bought my first Mac ever last week, a MacBook Air.
I have to say, the operating system on Macs has come a long way since I last used one. (Did I mention I also don’t even know how to properly run a Mac? But I know Unix, so I should be ok.)
I feel like the Mac interface is so much more polished and uniform than Windows, but it is pretty scary inside when you consider all the low level C and Objective C code.
Then again you have to consider that the wonderful .NET CLR is written right on top of a really crusty win32 API layer which is a bunch of scary C code that is about 20 years old.
So I am setting out on a brave new quest to learn Mac, iPhone and Objective-C and somehow port my application over to the platform.
Objective-C is kind of like an alternate universe
I was trying to think how I would describe Objective-C and here is what I came up with:
Objective-C is like one of those movies where there is an alternate universe where the same people exist as in this universe, but in some areas their technology is really advanced, but in others it’s really ancient. Like a bunch of people flying around in flying cars, but their weapons are still bows and arrows.
I used to be a C++ programmer, so not too many things scare me, but some of the magical constructs in Objective-C are very frightening indeed.
I was just reading about a strange construct today that allow you to basically create the equivalent of a C# interface, but in Objective-C it is called a “Protocol.” This seems fine and normal until I read the paragraph that says you can define some of the methods as “Optional.” What?
Let me put it in C# terms so you can understand it. In C# it would look like this:
This is not a joke. I still can’t quite figure out what this is for, but it is kind of interesting.
Another thing I found interesting is Objective-C has this thing called a “Selector.” It is not a function pointer, it is a variable that references the name of a method.
How is this different than a function pointer?
It is actually the name of the method being referenced. So if you have a class Dog that has a method “Wag” and you have a class WildGuesser who has a method “Wag”, passing them the “Wag” selector will cause very different results. How bizarre.
It’s weird to get sucked into the Mac world
It’s actually kind of funny. Here were all us Java and C# programmers off basically doing the same thing; creating our interfaces and arguing about dependency injection and mocking our unit tests and these Mac geeks with their bow ties and designer jeans were going a totally different direction.
It was only by random chance that our two parallel universes should violently collide. The iPhone came out and suddenly all these strange “Mac boys” were teaching us this new old language and reminding us to free up own memory again.
FOR GOD'S SAKE I JUST IMPORTED A C HEADER FILE FOR THE FIRST TIME IN 10 YEARS! THIS IS CRAZY!
But, I have to admit it is actually kind of fun.
Sometimes a change of pace is refreshing
I don’t mean my harsh language to be derogatory towards you Mac heads out there. You know you are cool, your boy Steve is leading this century's computing revolution.
I honestly mean that. Good job guys, you may just take over the world.
I’m actually enjoying this experience and beginning to think that if I come out alive, I will have gained some very valuable insights into programming in C# and Java. It is good sometimes to view something from a totally completely different perspective.
Who knows maybe I’ll get to write that Objective-C vs Java vs C# post I've been dreaming of.
But what about…
Meh. If I am going to program for a platform, I am going to program for that platform. I’m not going to half learn how to program for the iPhone and learn on the C# crutch. I didn’t do that for Android and I’m not going to do it for iPhone either.
Because I am stubborn and cranky? Partially, but I actually have a few sensible reasons also:
- MonoDroid and MonoTouch both implement another layer over the phone’s framework. Adding this additional layer makes it harder to do low level stuff, and with something as low level as a phone, doing low level stuff is often important.
- You are still using the underlying framework for either Android or iPhone. It is not like using C# code behind the scenes allows you to write a Silverlight UI that you can use on any of the mobile platforms. You still have to learn the entire phone development framework, which dovetails into point three…
- It is much easier to get help and find resources for raw Android or iPhone development than for MonoX development. Not trying to bash the Mono projects here, but most of mobile programming is spent googling for how to do things. By sticking with C# you are really limiting yourself in terms of finding answers.
- Change and learning different things is good. I’m not sure you can fully appreciate the design of a framework or platform unless you develop against it the way it was designed. I could be wrong, but I think there is a potential “lost in translation” problem in using C# on the iPhone or Android platforms.
After I learn iPhone development, I might try MonoTouch and see if it makes my life easier, but I need a good baseline first.
Well, I’m off on my journey. Going to head on to the back of the wardrobe in the “Spare-Oom.” I have to meet Mr. Tumnus, we are having tea with Mr. Wozniak and Mr. Jobs.