Question

For most of my apps, I have placed all the logic in classes, that each ViewController would get a reference too the class, or create/release the object itself.

I just started reading a book on IOS, and the author seems to like to put the app logic in the appDelegate, and the viewcontrollers just relay the actions to the appDelegate methods who do the real work.

Is the author just doing this because they are simple examples, or is this something I should learn, and start to do in my apps?

Answer 1

First, see What describes the Application Delegate best? How does it fit into the whole concept?

The application delegate is the delegate for the application. It is not the place to hold everything you don’t know where else to put. It is not the storage place for globals. It is the delegate for the UIApplication object. So it is the correct place to put code related to starting the application, terminating, switching to and from the background, etc. Things that have to do with how the application fits into the OS.

The app delegate is a controller, so it should not hold data. Data goes in the model. The app delegate may create the model at startup and hand it to other controllers, but it isn’t the API to the model. Often the model is a singleton instead of being created by the app delegate. Both approaches have advantages.

Most example code puts the model code in the app delegate because for simple examples it requires a little less code. But in real programs it makes the app delegate far too complicated, and significantly hurts code reuse. Your app delegate should generally be pretty small, and most of the methods in it should be part of <UIApplicationDelegate>.