5

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?

nycynik
  • 7,371
  • 8
  • 62
  • 87
  • I like LavaSlider's answer here http://stackoverflow.com/questions/8421138/importing-appdelegate – Rhubarb Nov 02 '12 at 13:28

3 Answers3

13

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

Community
  • 1
  • 1
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • I want to use the managedObjectContext everywhere in my core data dependent app. I am unable to find any solution other that importing Appdelegate everywhere, to access it. Is there another way out? – nr5 Apr 02 '17 at 11:32
  • 1
    Move `managedObjectContext` to somewhere other than the app delegate. It can be a singleton of its own, or it can be injected into objects that require it. I personally inject it into model objects that need it, and let view controllers fetch it via a `ViewControllerServices` singleton. But that's not the app delegate. – Rob Napier Apr 03 '17 at 21:31
  • I have a singleton which manages the appstate (userinfo, settings, other user preferences). I created a strong property of managedObjectContext there and initialise this in 'applicationDidFinishLaunching' code. Is this flow optimal? I can use managedObjectContext from here throughout the app ! – nr5 Apr 04 '17 at 07:25
3

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.

onnoweb
  • 3,038
  • 22
  • 29
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.

Raymond Wang
  • 1,484
  • 2
  • 18
  • 33