IOS/xcode: what methods are getting executed by default

Question

I am IOS newb with background in procedural scripting languages such as PHP. After trying to learn Xcode for several months I realize I still don't understand something quite fundamental i.e. what methods get called when.

I can understand methods getting called in response to user actions as in IBActions. However, the process by which other methods gets called remains mysterious. I gather in subclasses of view controller there is a life cycle with ViewDidLoad etc. where these methods all get called automatically. It seems there are some methods in app delegate that get called automatically. However, other than that is it safe to say that any method I put into an NSObject or view controller will not get called unless triggered by an event or called from a lifecycle method?

It does not seem possible to put code into the file as you would in a procedural file outside a function and method and know it will be executed. Instead, you have to put it inside a method. But how do you get that method called?

Does all code ultimately have to link back to either a life cycle method or method triggered by an event?

What if you are in an NSobject How do you make sure code gets fired--or do you have to include NSobject method in NSviewcontroller in a lifecycle method?

Thanks for explaining this fundamental concept.

Answer 1

Cocoa, the set of frameworks that power OS X and iOS development, is event-driven. That means that, generally speaking, code is executed as the result of some event – a user touch, a timer firing, an animation completing, a network request being received, etc. From the programmer's perspective, code is not executed in an obvious order, but instead in response to things happening.

You mention UIViewController lifecycle hooks as a way to get some of your code running, by overriding methods like viewDidLoad and friends. Note that these methods are called as a result of some event – it's in the name! viewDidLoad is called to give you a chance to do something custom after the view did load.

Later on, you'll find that there are endlessly complicated ways to get code to run, depending on your needs – you can submit blocks to a Grand Central Dispatch (GCD) queue, spin up an NSOperation for more complex, interdependent tasks, schedule a future event with an NSTimer, and much more. But, again, because of the system's event-driven nature, you could theoretically trace the execution of all of this code back to some event.

Answer 2

Great to know that there are people coming from other environments now looking into iOS development. First, note that all your questions relate to the fundamental concepts of object-oriented programming, so if you'd go e.g. into Java land you'd experience the exact same issues.

Let me mention a few things:

1. You pointed out that you noticed that some methods are called automatically, like applicationDidFinishLaunching in your AppDelegate or viewDidLoad in UIViewController. This is indeed correct, however these circumstances are given and determined by your development environment and the frameworks that you work with. So, indeed on iOS, the basic building blocks of your application are UIViewControllers, these are classes provided by Apple itself for us iOS dev to work in their environment. Apple determines, and gives recommendations, as to how we can work with those. If you're going to Android, you won't deal with UIViewControllers in particular, however also there the platform will provide you with basic building blocks that guide you in your application development.

2. If you want to experience raw object oriented programming, you can always go by starting to write some Objective-C classes and compile and run them in the Terminal, you (most likely) won't be able to build an iOS app like this, but you will be able to solve computational problems and build applications.

3. Another point that you mentioned relates to what if you're just an NSObject and you want code to get executed. Well, in this case it's special because NSObject itself is actually just the base class of all other classes that you'd want to use on iOS. It implements the basic operations (like being put into an NSArray) that you'll need once you subclass it. You'll almost never want to use NSObject directly, but always subclasses thereof.

I can't go further into object-oriented programming in this answer, that would exceed the scope of Stackoverflow I believe. Just know that what you have to look into are the fundamentals of object-oriented programming. Once you get acquainted with those, all in Xcode and iOS will start to make more sense!

There are tons of materials out there that teach these principles, I'd recommend you the Stanford lectures on iOS 8 development where these principles are greatly covered!

Good luck! :)