First baby steps in iOS

Everyone seems to be developing iPhone / iPad applications lately. And let’s be honest; it’s great hardware. Long battery life, good UI, looks great. I must admit that I’m one of those “I don’t like the way Apple treats its customers and therefore I do not buy Apple” people. So I have a HTC phone, an Acer laptop, a Popcornhour media streamer, anything but Apple.

But recently someone asked me if I would be able to develop an iPad application and I had to say no. However, the fact is that business is still slow and that I’m still using my reserves frequently to make ends meet (living in a somewhat country side area doesn’t help my opportunities either). So I decided do a trial project for myself, just to see what iOS is like. Having done Objective-C somewhere in ancient history and remembering I liked it back then, was a good motivator, and I figured I would be able to pick it up fairly easily considering all of the programming languages I have coded. So I bought a book and spent a number of evenings reading through it, until I felt ready to give it a try.

I’m a strong believer in that every trail project should take on a real world situation, so you will be forced to tackle actual problems and not just the ones you think are interesting. We have a hour registration system we use internally and is used by a few of our customers. The main hour entry is done via an applet and I figured that would be an interesting test case; hour entry on the iPad / iPhone. It required me to do GUI and communicating with the back-end.

The first hassle I had to overcome was that I need to develop on a Mac. The platform is not available on Windows, but I was not going to buy a Mac just for a trail project. The second issue is the fact that you cannot deploy an application on an iPad, even if it is directly connected to your PC, unless you have obtained a certificate from Apple at the price of 100 USD per year. Talk about fueling my anti-Apple feelings. But I overcame that moral dilemma and purchased one, so nothing was keeping me back anymore…

XCode turns out not to be a bad IDE at all. I had to remap a number of the Apple-combination keys to CTRL (e.g. Apple-S became CTRL-S) otherwise I would go crazy of the key-not-bound error beep every other second (I never realized I hit that combination that often). And since I’m used to Eclipse, I’m a bit uncomfortable with the window layout, but after some time I got a somewhat enforced but working layout.

iOS and its toolkits are ok. They’re logical, well structured and have their quirks; like for example that creating a new UIButton returns an instance of an embedded classes or something, so you cannot extend UIButton and use the default look-and-feels. What I find strange is the fact that the model-view-controller (MVC) pattern is only used at the toplevel, so the screen has a MVC setup, but if you chop it up in separate parts, that are simple views. Coming from a Java background that took some time and refactoring to grasp.

The biggest challenge turned out to be Objective-C. If you’ve read my previous post, you know about my “ohhhh” feeling for a language/platform; I didn’t get it here. Java has had its share of criticism about the use of native types (int, double), but Objective-C takes this to a new level; it actually combines old style C coding with Smalltalk style inter-object messaging. So depending on which toolkit you use, you either switch to an OO interface (Cocoa screen widgets) or C functions (Quartz 2D drawing), and naturally these have to be mixed when actually writing code.

The inter-object messaging is derived from Smalltalk; an object sends a message to another object, which is the equivalent of calling a method. The object may, or may not, process that message. If it does not, the message is passed up to the parent and further up until it is either processed or a kind of “method not found” exception is thrown. There is no real compile time checking, just exceptions at runtime, except a warning by the IDE that the message might not be processed by the receiver. (Anyone still complaining of Java’s runtime classpath?) Since I’m a fan of strong typing this concept of “weak calling” is giving me a real nervous feeling.

Another challenge was the memory handling. Java has a memory manager taking care of releasing memory blocks that are no longer used. So if you start programming Java, you can focus on the code and leave the rest for when you have a better understanding, and start doing more complex things and memory leaks may become an issue. In Objective-C it’s practically the first thing you learn, and it’s most definitely not for the weak hearted, rated at at least PG-16. It took me two complete parses through my source code, reading out loud what the memory issues were for each line of code, to get it working (and me understanding). But I must say, now that I’ve got a working “style” on how to do it, I do realize that this kind of memory management has it mertis; you make mistakes way too quickly and the resulting errors give no clue whatsoever where things went wrong, but there are definite some advantages compared to the bulky garbage collector. That said, I’m still thinking that the autorelease pools should be considered simplistic garbage collectors, and when they clean up, they also can have a lot of objects to release with the same performance issues. It’s just that they run more frequently (usually after each UI event is processed) and do not tend to accumulate that many objects. So the question on whether this is a better approach, or just a more frequently running GC is still out.

And last but not least; the hour entry servlet uses Hessian to talk to the backend. There also is an Objective-C implementation called HessianKit and it turns out to work quite well. Naturally there are some mapping issues, but I got it working quite quickly. The one thing that this taught me, is that libraries in Objective-C are not very practical. Libraries are compiled to native binary, so you need different versions for Mac Intel CPU, PowerPC CPU and the iOS platform. So the best way to include a library, is to pick up its source code. This is what I ended up doing with HessianKit.

In light of my previous blog which mentions things like readability, compactness (expressiveness), packaging and deployment, Objective-C does not score high. I have mentioned a number of do-not-likes above, and Objective-C most definitely feels like a step back on the easy-and-quality-of-development ladder compared to the current standard set by Java and DotNet. The one thing I actually really like is syntax of the way messages (methods) are called and especially that the parameters are described, which makes for very readable code: [someObject renameThingy:<par1> to:<par2>]; One of the biggest annoyances I have with Java is the fact that you cannot name parameters, so you can get cryptic calls like: someObject.process(true, false, false, true); Unreadable!

The hour entry project is not finished yet, so that would make this blog a “to be continued”…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.