X-Code
I knew what roughly what Objective-C was like before I decided to learn it. I hadn’t really ever written C or C++ (or even C#) before, but I had tweaked and compiled code written by others in all of them and I had a really solid grounding on Object-oriented programming from years working in Visual Basic.NET and object-oriented JavaScript, insofar as either of those languages support object-orientation, but when I actually applied myself to the task, I found I was in for a much tougher ride than I had expected.
My first instinct was to just start a project blind and try to find my way by feel. I quickly realised Objective-C and X-Code were just too different than anything I was familiar with, so I posted on the Apple Developer forums asking for recommendations on some online learning resources. On a recommendation from a user, I picked up a copy of Beginning iPhone Development. Another recommendation was for a series of video lectures from Stanford University that were available on iTunes U for free. I have read about the first third of the book and watched about half of the videos. Both were excellent learning resources and I recommend both to anyone starting out. Learning by reading though or even watching is something I prefer to avoid wherever possible. As soon as I’m off and running with a new system or language I prefer to learn by exploration.
Apple’s documentation is actually fantastic (far, far better than MSDN that comes with Visual Studio from Microsoft) and gives you real world sample code for most of the things you might want to do when starting out, and now that the NDA has been lifted the blogosphere and forum communities are starting to come alive with ready made solutions to problems and sample code for the taking. The community over at the Apple Developer forums has been a tremendous source of help with my many questions too.
After completing about seven of the sample apps from the book I couldn’t face doing any more so I started a real project and figured I’d work the rest out as I went along. This approach worked really well because I chose a suitably modest goal for your first application for which I knew I would only need entry level iPhone programming skills. There were a lot of new concepts to learn and I knew I’d end up rewriting a lot of code as I learned the right ways of doing things so it was essential that I didn’t start off with a project that was more than I could handle.
The first surprise I had was how difficult I found it adopting X-Code as my new IDE. I’d only ever used Visual Studio for native platform development and Adobe Dreamweaver for the web, but I wasn’t expecting to have any trouble adapting to a new IDE for the iPhone but this was one of the more difficult learning experiences. X-Code has a concept called “NIB Files” which are a visual representation of views and windows, created in a tool called Interface Builder. Unlike Visual Basic forms, NIB files are not tightly coupled to a source code file. In Visual Basic all the IDE is doing for you is generating hidden source code at the top of a class file. In Interface Builder, the NIB files represent a packaged set of object instances that are “unbundled” at runtime when they are needed. Because they are not tightly integrated with one particular source code file, you can reuse them.
The re-usability of NIB files is a key element in the Model-View-Controller application architecture that Apple so love to evangelise about. The principal behind MVC is incredibly simple – it states that you the code that deals with your model (the data in your application) should be separate from the code that deals with your view (the presentation of the data to the user) which should be separate from the controller code, which is basically the glue that binds the model to the data. At first, MVC seemed to me like one of those vacant management acronyms you hear so often in the corporate world that really have much practical application, but it isn’t, not at all. I have always tried to write code that is reusable and always struggled, and the reason is because I wasn’t following the principals of MVC. My first piece of advice to anyone starting out in iPhone programming is that if you don’t already have a good understanding of MVC, go and read up on it before you do anything else.
After getting to grips with Interface Builder and NIB files, my next major problem was learning which classes and methods to use in which circumstances. It’s easy to take for granted the years of accumulated knowledge you build up when using a framework language like VB.NET or Java which provides an enormous library of ready-made code for you to consume, and to forget how frustrating it can be having to relearn that knowledge for a new framework.
Cocoa is like .NET – it contains classes for nearly everything you might want to do but it also contains some curious omissions. For example, it has no native support for JSON – incredible when you consider that JSON is fast becoming the language of choice for data transfer all over the Internet and the iPhone is touted as the mobile Internet device, but there you have it. Support for regular expressions is also scant – there’s a very old C implementation of POSIX regular expressions (which has a very limited feature set), and in the iPhone OS 3.0 there is proper support for them, albeit in quite an obscure and unexpected corner of the framework (NSPredicate if you’re curious).
The Objective-C language syntax, though very different than JavaScript and PHP and especially Visual Basic, was surprisingly easy to pick up because the language features are fundamentally no different than any other language, they’re just written differently. I did struggle with was understanding when to use C variables and when to use Objective-C objects – “int” variables vs “NSNumber” objects for example. I’m still getting the hang of this.
Debugger in X-Code
Then finally, there’s debugging. Oh, how I have been spoiled by Microsoft with Visual Studio’s debugging suite and Firebug for debugging JavaScript. I didn’t realise just how much. For performance reasons, iPhone OS doesn’t support garbage collection and comes with a fairly feeble 128MB of RAM (although this has doubled in the iPhone 3GS). That means you have to manage your own memory allocation, and do it well. Having to do this made me realise just how lazy I was with memory management. I found I was forever crashing because I had released objects too early or leaking because I wasn’t releasing objects at all. Getting the balance right is harder than it seems, but it’s actually a lot easier if you follow some basic rules which Apple has set out has a very good document about memory management for iPhone development.
Frankly I find the debugging tools in X-Code piss poor compared with what I’m used to. When your instance variables are pointers for example, instead of showing you the data at the memory address to which the pointer points, the debugger shows you the hex address of the memory address. Really helpful I’m sure. Theoretically VB’s “Edit and Continue” is present in X-Code with the “Fix” command, but I couldn’t get it to work. And there’s no immediate window or console command line for executing arbitrary code whilst the application is running. Some of the tools, particularly in performance analysis with “Instruments” are second to none, but overall I have found debugging to be the biggest source of frustration as I have been working my way slowly but surely into the exciting and hopefully lucrative world of developing for the iPhone.
Tags: .NET, cocoa, Javascript, Objective-C, Programming, vb, visual basic
