Is it ok to place most logic and models in the appDelegate?

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 j

Answer 1

I would say that's because the examples are probably simple. For any reasonably complex, real-world app the appdelegate class would become unwieldy pretty soon.

Answer 2

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>.

Answer 3

Technically you could do it. In terms of programming practice, don't. Once you put a lot of things in the appDelegate, it will become very messy. My advice would be leave it alone.

You don't need to put anything in appDelegate except global variables. And if you do need it sometimes, my suggestion would be use something else like singleton pattern. Generally speaking, global variables are not good practice.

Hope this helps.