February, 2009


12
Feb 09

iPhone SDK impressions and Objective C rumblings

I’ve been doing some work with iPhone SDK lately and of course that introduced me to the world of Objective C. So here are some of my opinions, likes, dislikes, etc…

iPhone SDK

I think the SDK is great. Very similar to Cocoa (which I have no experience in using, outside of some readings). I’m really liking XCode and some of it’s features, but it’s hard to “love” it, after developing with IntelliJ IDEA over the last few years. IntelliJ is the king of all IDEs and any future IDE project should at the least take notice. And if you can’t produce anything that even closely resembles IntelliJ in its functionality and code editing abilities, then don’t call it and IDE. Ok, enough of the IntelliJ biases here, XCode is good enough at least for the language at hand, Objective C, more on that later.

Building iPhone apps is a breeze, especially after a few days of playing with the SDK, reading a good book (there are a few out there already), and beating your head against the wall trying to figure out how UINavigationController works. After you figure it out, you’ll realize that it’s not that it tooks so long because you lack brain power, it’s because we’ve been conditioned to think that something like this should be more difficult than this. No, really, UINavigationControllers are very powerful and very very simple. So throw away all your past baggage and open up your mind. You should be proficient in the SDK in a day or two.

Objective C

Well, what can I say. I like some of it’s features, but I hate many more. I guess after programming in Perl, Java, Python, AS3, Ruby, etc…, one can’t really get excited about a language build on top of C preprocessor and inherit all of its limitations. But one would also think that if they already build so many powerful features on top of the C preprocessor, why not do more?

Here is one example. Interfaces are great. I use them all the time in Java, AS3. I defined them as abstract classes in Perl, Python, Ruby, etc… that don’t have an explicit interface concept, but you are not forced to. There are classes that don’t have and/or need an interface accessible outside of the internal package where it will be used. Sometimes I just want to define a class. I know I can have @interface and @implementation sections in one file, but WTF is the @interface section for, just so I can type the definition twice? Ok, I think what I’m really pissed about is something else, and I’m taking it out on @interfaces. I can live with interfaces if…

Where are private methods? Please help me? I’ve searched and searched and searched. There are numerous techniques.

  • Convention
    Define your private method with an underscore, but then it’s still visible to XCode completions, which is annoying. I know that at runtime, dynamic dispatch doesn’t differentiate between private/public, but convention would be OK I guess (it is in perl), but apple discourages it. Because they use the underscore convention, they don’t want you to. Ok, that doesn’t make much sense. So what do we have to do, write 500 line files and repeat our code in every public method? Or just define 40 different private helper methods as public? WTF????

  • Categories
    This is a better solution. I love the way Objective C has a concept we call mixin in other languages. You can basically augment behavior of objects by defining categories. That’s cool, but I just want to define a simple #$@%ing private method. So I have to define a category, but I don’t want to define it in the public header file, so I have to also have yet another header file ClassNamePrivate.h, where I will define @interface ClassName (Private). So now, I need to have 3 files for a simple class that never needed a public and private interfaces, just a simple helper class that I want to reuse. Would that would more than double the # of files in a project as compared to some other language that doesn’t have that constraint. I don’t say tripple, because interfaces are important and there are many cases where one would want to define a public interface. Dynamic languages don’t require that, static languages like Java do, but I can live with an extra file in Java, but not extra 2 files.
    You can also define your category @interface and @implementation inside your .m implementation file, but to avoid compiler warnings, you have to define your @implementation for the category as the first construct in the .m file, otherwise using these methods will cause a compiler warning. Well, that is fine, except I usually define private methods towards the end of the file and cluttering up my code with 10+ definitions for private methods right when someone first glances at the file is not really a clean coding practice.

There are many other small quirks that bother me and other things that I’m beginning to like. After all, I can live with it, being that I’m not really given another choice by Apple.

So my final words are: Apple, please listen to developers, take a look at the language innovations and get out of the stone age. Objective C 2.0 has some very cool innovative features, but some are so restrictive and ridiculous that one might wonder why you’d actually get someone to use it if you didn’t force them. Also, if you choose not to improve the language at least open your platform for a more modern language that folks will have a pleasure working with.