This is part 2 of a series. In the first post I said something about the application structure.

A word about Twitter

I’m going to digress a little before telling you more about iPhone application structure. It is not essential for this series, but it is essential to completely describe the adventure that this first application brought on me.

When I found out about the MonoTouch project, it was in Beta and you had to apply to be admitted. I filled in the form (from my iPhone, just to impress them) and then waited. Nothing for a couple of days. I applied again, just to make sure you know. Nothing. Now I’m a modern guy, so I tweet. I tweeted my frustration (in Dutch), since I really wanted to get started. But hey, what where the 3 followers I have gonna do about that? Then it turned out that this guy Joseph Hill, somehow monitors all tweets in the world for the MonoTouch keyword. Joseph is one of the people in the MonoTouch project that is really a Person. He pulled some strings and presto! I got my Beta-account.

For me, that’s just amazing. I didn’t think that Twitter would give me much more than just the latest tips from Scott Guthrie, but this is a totally new way to bring people together and build communities.

The AppDelegate

When you create a new iPhone solution in MonoDevelop, you get a couple of things:

New Solution

1. A xib file called MainWindow.xib. This is where your user-interface is defined. It is an XML file that can be used by the Interface Builder. Simply double-click it and the Interface Builder opens up. More about the Interface Builder later. MonoDevelop monitors the file and regenerates the accompanying designer file when the XIB is changed by Interface Builder. The designer file maps the elements from the user-interface to the classes in your project.
2. A main.cs that contains the entry-point to your code. There is  a partial class called AppDelegate that is mapped to the main window of your UI. The most important method there is “FinishedLaunching”. It gets called when the iPhone is done with all the stuff it does when loading an application. The name is a bit misleading. Your application is definitely not done launching, at best it is done loading. All the stuff that you need to do yourself still has to happen. Like loading some files, initializing your controllers, setting-up your model classes.

Loading your application

There’s more to say about the loading process. Since it takes some time before you even get control about what happens, you have the option to show an image while loading. Add a file to your project with the name “Default.png” and set it’s properties to “Build Action – Content” and it will be picked up by the loader. Your supposed (according to the designer guidelines) to use an image of your app in action, but it is often abused to show a company logo or something. Some applications make a screen-shot of themselves when the application closes and save that as Default.png. That way, the next time you start your app it looks like it quickly continues where it left off.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// The name AppDelegate is referenced in the MainWindow.xib file.
public partial class AppDelegate : UIApplicationDelegate
{
	// This method is invoked when the application has loaded its UI and its ready to run
	public override bool FinishedLaunching (UIApplication app, NSDictionary options)
	{
		Console.WriteLine("Launched");
 
		window.AddSubview(yourViewHere);
		window.MakeKeyAndVisible();
		return true;
	}
 
	// This method is required in iPhoneOS 3.0
	public override void OnActivated (UIApplication application)
	{
	}
}

You should not be doing too much work in this method. The loader times the duration of this method and kills your application when it takes more than 10 seconds. Or so they say, I never tried it out.

You can use this method to build up your user-interface in code. I went that way first. I had such a hard time getting my head around the Interface Builder that I decided to drop it and build my interface by hand. That worked reasonably but caused unexpected crashes. I knew it had something to do with the way I hooked up the different views, so I went back to Interface Builder and tried and tried and tried. I got it, more or less, and my interface (using a tab-bar) is now stable. In the next episode I will dive into the Interface Builder.