Thus, I typed this snippet into my Objective-C code:

labelTimer.text = [NSString stringWithFormat:@"%2d:%2d", minutes, seconds ];
[/code]


labelTimer.text = [NSString stringWithFormat:@"%02d:%02d", minutes, seconds ];


A lot of people do not like it for reasons of their own and I do not want to get into those.

What I do want to discuss is that in an environment in which you are responsible to allocate and free memory yourself (like Delphi, C++, Objective-C), you might stumble about issues with frameworks or base classes you use.

In my case it was the libxml part of the iPhone OS which allows you to parse XML documents. (I even now of Delphi developers using this library to parse large documents). Its biggest advantage is that the xml document is not read in one go but step-by-step in chunks. The developer can hook into it with an event-driven approach and can thus interpret the file. However, during the parse operation the library tends to produce memory leaks that cost me two hours of debugging.

With iPhone applications it is very simple: the iPhone is a mobile device with limited memory. If you produce too many leaks in a certain amount of time, you will not have many customers using your application as it might crash frequently (it might not even be accepted if you want to deploy to the Apple AppStore due to this fact). This makes you very aware of producing code that produces absolutely no memory leaks of any sort. Apple delivers Instruments so that you can debug your code for memory leaks. As I was not familiar with the tool, I did not realize at first that the leak did occur in the library and not in or because of code I had written.

Now comes the important part: formulate a rule. I do not want to waste another minute because of issues that are in 3rd party code. However, it is not as easy, because it might not be the 3rd party library but you not handing over the data to the library correctly (especially when dealing with different languages and use DLLs e.g.). To state the rule ‘Always check the call stack where the leak originates.’ will not suffice. An example for this is that you allocate memory for an object instance and then hand a reference to this instance to a function or method. The method allocates memory again and returns another reference instead of using the one you provided. In that case you are responsible for the leak. Documentation needs to be clear in cases like this.

I think that fact is the biggest pro for garbage collection. Some people might call it lazy, but I prefer it considering how much time I spent when writing iPhone applications thinking  of proper memory management. iPhone OS comes with strict guidelines how to name methods so that you know if the caller or the function is responsible to allocate and free the memory which makes it easier, but it is still difficult enough.

As a final point, please be aware that my googling and analysis really points to a method in the parser of libxml leaking some bytes when parsing a document. In case you develop an iPhone app and use libxml, do not worry about the leaks that Instruments shows you that derive from a call to the parse mehod of the xml parser — not your fault.

Why different? Well, not only is the syntax of the programming language on Mac very odd getting used to for a Delphi or C# developer, but even more using the computer is also needing some time getting used to. Shortcuts are different, there are way less visible shortcuts than on a Windows system and the general approach how to get things done is very much different. With regard to the shortcuts it is sometimes a real pain to find them and they often differ from application to application. Mac OS is very much designed for mouse users, it seems, and keyboard enthusiasts will have to read the docs carefully. A lot of people claim that it is easier and more intuitive to get started, especially if you have not used Windows before. I would not sign that statement as Mac OS has also quite some oddities just as Windows has. Just yesterday, I dragged a file onto my desktop which did not show. When I dragged it again, Mac OS told me the file was already there and if I wanted to overwrite it. Thus, it is not without flaws either. And ever since Windows 7 one can completely forget the generalization “Mac is more stable than Windows”. My Windows systems are just as stable. However, I am derailing from my train of thoughts…

“How would one get started to code on the Mac or code applications for the iPhone?” was the question I had to get an answer to. Firstly, give yourself time to get used to the system.  Do not try to start developing right away. It will not work. Believe me. I tried. Give it some time. Fiddle around with a Mac system at least for 1 or 2 moths before you start developing. You need to get some insight in how the system works, how applications are assembled etc. This will not happen in a week and you definitely cannot read it in a book and hope to get the same understanding as learning by doing. Of course, a book to get started with Mac OS can help. Maybe, you are as lucky as me and have some hardcore Apple Affiliates at your workplace you can nag all day long… They will forgive you for the frequent interruptions sooner or later (thanks, Volker… ).

Secondly, get the tools for the job. With Apple it is very easy to get the right tools in order to develop Applications for the platform as the company publishes the development environment with the operating system itself. Be sure to have a look at your Leopard DVD and install the additional features. Besides, you will miss the command-line tools after a month or so anyways and they are there as well.

The main development environment is called Xcode and if you ever dare to load one of the sample projects you will be overmanned. Yes, you will. There is no way around it. The code simply hits you and it might result in an abrupt thought that may say something like “How did I ever think to develop for this platform in that language?” — It definitely feels like that at first.

Thus, get a book. Or get two actually. One is free, the other is not. I started learning the language with a book that is just about the language. Not about any platform. Just the language. The book is called ‘Programming in Objective-C 2.0′ bz Stephen Kochan and it gives you a very good introduction and gets you used to the funny syntax. Funny is an adjective every Delphi developer I know has used so far for that particular syntax.

For me it was very clear that I wanted to develop applications for the iPod Touch and iPhone. Thus, book number two. Apple has a huge archive of free documentation that comes in a very printer-friendly PDF format. The PDFs are seperated by certain topics, not just a simple reference that has been generated from source files or generated in some other way. It is like a big library at your fingertips. I read quite a few of them and they are very good to read and contain lots of useful information. Access is granted if you join the iPhone Developer Program. Unlike frequent misinformation about this topic, joining this program is free of charge. You get all the documentation and all the programming tools for free. No charge. Not once, not yearly. The only thing you are being charged for on a yearly basis is the ability to deploy to physical devices. There are several different subscription packages available, but in order to get started, you can use the free account. The software development kit (SDK) even comes with an iPhone simulator that allows you to test your application like it was running on an actual physical device. There are only a few restrictions that make using a physical device a necessity. But believe me, these will not affect you in the first couple of weeks of developing applications.

When you got your login details, you can use your iTunes Account as a sidenote, you can download the SDK which includes all the tools you need. Furthermore, during the download I had lots of time to read as the SDK is huge and take a long time to download through my pitiful bandwidth of 2MBits.

After the download, installation is only a double-click away and takes from 10 to 30 minutes. Be sure to drag Xcode into the dock - you will need it all the time.

But how to get started? Well, Daniel Magin suggested a book to me and that really got me started:

• iPhone SDK 3 (Visual QuickStart Guides) by Duncan Campbell

It gives an introduction with use-cases to the most important classes that you need to use in any project and it also describes all the visual components hands-on. After reading this book - it is not that big, so I did read it completely -  you are able to write little apps and are ready to dive into the details. Oh, and be sure to download the free bonus chapters of that book. I did that with two books from Apress from the same group of authors:

• Beginning iPhone 3 Development: Exploring the iPhone SDK by Dave Mark and Jeff Lamarche
• More iPhone 3 Development: Tackling iPhone SDK 3

Those will keep you busy, but afterwards you will be ready to write applications for the iPhone for sure. Patience is most important while typing the new language. Furthermore, Xcode is very different when entering source code. If it felt strange using Visual Studio when being used to Delphi, it is like that…

For the German audience one additional hint. The German Mac keyboard is a bit odd as it has not all keys printed completely. E.g. the {} and [] are nowhere to be found. I have no idea why the German Apple keyboards are built that way. Furthermore, typing source code on a German keyboard is very clumsy. Due to that,  I have coding-keyboard with US typeface, so that I can type source code more easily. It helps quite a lot.

Next time I will introduce you to some architectural ideas and implementations I am dealing with right now. I have some applications that need to work on a Windows Desktop as well as offer access using the iPhone. Furthermore, a web application is not an option  I consider for the iPhone. The usability employing a native iPhone application is just so much better in my opinion.

The first question one might pose is why one would want to write to NTFS having a Mac. Well, simple. I still do a lot of work on Windows systems and if I want to create files bigger than 2 (or is it 4?) GB, I cannot use any FAT derivative which can be used with Mac. Windows cannot read the Mac file systems either. Furthermore, I used Windows exclusively, so all my harddrives I used for backing up contain NTFS partitions with huge disk images. I cannot write any files to these partitions with a default Leopard install.

Today, I found a project called “MacFuse”. It is a developer SDK/API of some sort that allows you to develop 3rd party file-system support. Of course, there already exists an implementation for NTFS. The one I found is called “NTFS-3G” written by Erik Larsson.

In case you want to write to NTFS partitions as well, the following links will help you to get started. Please note that the latest release of  NTFS-3G does not require the installation of MacFuse as it comes “in the package” as well.

• MacFuse: http://code.google.com/p/macfuse/
• NTFS-3G: http://macntfs-3g.blogspot.com/