What is the Objective-C equivalent to main()?

Question

Hi everyone!

I'm just a beginner at Objective-C and its syntax is just knocking me out of my mind.

I'm 'trying' to work on iphone 3.0.

Up till know I have learned that:

1. there is .h file which contains the declaration for every class; like we have in C++ where we can declare the name of the variables/data_fields and later define the functions/methods outside
2. *The functions/methods are declared in a .m file so for every class there will be a .h file, a .m file and a.xib file

So how do we call the functions/methods of our choice?

In good old language format of C,C++,JAVA,C# we have a main() function which does our control work but what's the equivalent of it main() here in Obj-c?

I know there is a main() function too but I hardly know how it works.

Answer 1

the main function starts the main program event loop, generally you dont touch it.

the AppDelegate is where you want to put your own user code. If you generate a sample iphone project called Sample you will generate a class called SampleAppDelegate, it has a method called - (void)applicationDidFinishLaunching:(UIApplication *)application which is the entry point i think you are looking for.

The SampleAppDelegate class implements a delegate (like an interface in c#) from the UIApplicationDelegateProtocol some of the methods are optional applicationDidFinishLaunching is not. This is generally where you set up your first view controller to do your inital screen.

Calling a method is done via message passing. If i have a class Tom with a method print i will initialise and call the method as so

Tom *tom = [[Tom alloc]init];
[tom print];

oh no where did my method arguemts go ? i feel lost without brackets.

If i have a method that prints page numbers and returns void i might define it as such

-(void)printPageNumbers:(int)pageNumber{   
}

and call it like this

Tom *tom = [[Tom alloc]init];
[tom printPageNumbers:2];

multiple parameters

-(void)printPageNumbersFrom:(int)fromPageNumber toPageNumber:(int)toPageNumber{
}

and call it

Tom *tom = [[Tom alloc]init];
[tom printPageNumbersFrom:2 toPageNumber:5];

Its not a very type safe language, you can do some funky stuff like if you had an array of Tom objects, you could just send one of them a message. If at runtime it turned out that the object in the array wasn't a Tom you would get an exception.

   [[myArray objectAtIndex:0] printPageNumbersFrom:2 toPageNumber:5];

Some comments on the above "so for every class there will be a .h file .m file .xib file" - this is incorrect. Each class has a '.h' and a '.m'.

A '.xib' is a view file, if your class has no ui element it wont have a '.xib'. the '.xib' called a nib file is not part of the class anyway, it just refers to it. (you link the two)

I found the learning curve fairly steep. Objective-C is not a hard language if you have C and some OO backing. However putting it all together with the ui can be a bit of a pain. Stanford uni has an online course which they have distributed through iTunes U ive watched them all they are worth the time, see here

enjoy the curve, im glad im not sitting where you are :)

Answer 2

You really should work your way through the introductory documentation on Apple's developer website first. It is sometimes very helpful to work through things in a systematic matter when you're a beginner: Learning Objective-C: A Primer and Your First iPhone Application

Answer 3

I think iPhone development presents two challenges for programmers experienced in other languages/APIs:

1. The API does so much for you that it is difficult to get a grasp for how the program is actually structured. People used to starting apps from scratch keeping expecting to have to do more a lot more work to get an app launched.
2. The Interface-Builder/nib technology hides a lot of complexity that experienced programmers are used to dealing with. It seems like views, controllers etc just pop out from nowhere into classes.

As a result, experienced programmers always feel like they've missed something in learning the API because they expect the complexity that is hidden.