I finished my first iPhone app this weekend. it is not a very impressing application, but it does what I meant it to do and that is to show movies with Dutch Sign Language coming from the website of the Dutch Gebarencentrum.
Developing for the iPhone is exciting. Well, let me re-phrase that: the result of your development for the iPhone is exciting. Mmmmh, let me re-phrase that again: it was a helluva job to build a working iPhone app, and now that I know how to do it I’m excited!
This post is the first of a couple of post I’m planning to do on development of iPhone applications with .NET. There’s simply too much to learn and to tell to do it all in one post. These posts will not only be about programming C#, but also about design principles, open-source programs, Twitter.
Where do you start?
As a .NET developer you have two choices to program for the iPhone:
- You learn the Objective-C programming language and the XCode development environment
- You use MonoTouch and MonoDevelop
I started out with the first option, since the second was not available at that time. I found it really hard. Using a c-like syntax is not the hardest thing, but I surely wasn’t used to manage my own memory any more! I got really frustrated since I also had to learn all the other things I’ll talk about in a minute.
The solution came in a podcast from DotNetRocks titled “Rory does iPhone” in which Rory Blyth raved against Objective-C. In that podcast there was a short mention of an open-source initiative called MonoTouch.
That changed my world radically. I went out looking for the Mono guys and found a very mature platform and active community. if you don’t know: Mono is an open-source initiative that brings the .NET framework to a lot of other platforms, especially the Unix-look-a-likes.
I had heard about Mono before, but always thought it was a project that was way behind the development of the .NET framework. You know, like Microsoft is releasing .NET 4.0 and the Mono guys are proud to announce they now support 2.0! Nothing like that! Mono is on .NET 3.5 and preparing for the changes that 4.0 will bring. They also have a very nice IDE called MonoDevelop that looks a lot like Visual Studio.
With MonoDevelop developing applications on the Mac is so straightforward that I never go back to my VMWare installation with XP and VS2008 to do some quick development. If you think about porting your application (since not all that is available on Windows is there on Linux too), install their Mono Migration Analyzer add-in.
But is is also a very special compiler that pre-JITs (the call it Ahead Of Time compilation) the entire application. Why? The iPhone OS will not allow you to run a virtual machine. Ever wondered why there is no Java or Flash on the iPhone? They cannot run since they depend on their own VM.
MonoTouch circumvents this problem by generating native code, removing all the unused libraries, classes and methods and then building a Mac App package from that.
What do I have to learn?
When you want to build your own application, you will at least have to learn about:
- The structure of iPhone apps
- The Cocao Touch library
- The Interface Builder
- Debugging in XCode
- Signing your application
- How to distribute your application
I will try to tell you about all of these subjects in different installments.
The structure of an iPhone app
It is essential to know what the iPhone expects from you and how the Cocao Touch library supports that. It is probably way different from the way you worked in C# and WinForms, and it takes some time to get used to finding out where to put your application logic.
The Cocao Touch library is full of Design Patterns, but the most pervasive, noticable, visible and wonderful is The Model View Controller. Below is an image from the Mac Development Library:
This post is not about Design Patterns, so I will not explain how the MVC pattern is supposed to work. The image is just their to help me explain which classes you will have to inherit from.
Cocao development is about inheriting from the classes that wire up the application for you. That means that you only have to override the methods that are of interest to you, but it also means that you essentially have no way to stray from this setup. You use the Cocao classes or you end up building your own library.
These are the classes that implement the MVC pattern for the often-used TableView:
The UITableView is in the NIB: the file that is generated for you by the Interface Builder and that holds all the GUI elements.
The UITableViewDataSource holds the data that is displayed in the table. It’s methods are called by the Controller to fill the cells in the table (e.g. GetCell, RowsInSection).
The UITableViewDelegate implements methods for dealing with user-actions that are performed on the view, like “RowSelected” when (yep) a row in the table is selected.
The UITableViewController is the man-in-the-middle. It sits between the DataSource and the TableView, and does things like passing the DataSource filtered data when some search criterion is entered and then telling the TableView to reload with this new data. The controller can use your own model to get this filtered data.
So far for this installment. Next time I will show some code and tell about the AppDelegate, the object that functions as the heart of your application since it receives a lot of interesting messages like “Hey you’re app is started!”.