Question

What’s the main point behind putting variables and method signatures inside ApplicationDelegate.h in Objective-C ? By doing this, all those methods and variables are seen by another view controller classes? Is that the point?

And also: is there only one application delegate class inside each project?

Answer 1

“By doing this, all those methods and variables are seen by another view controller classes? Is that the point?”

Of course, any class that imports the app controller’s header can access public properties and methods (and ivars), but that goes for any class, not just the app delegate.

It’s pretty common to put a few important objects and methods that are needed all over the app in the app delegate. In that way, yes that’s often the reason why you see variables and methods defined on the app delegate class.

This makes sense sometimes, but it can very quickly deteriorate into very bad design. You should make sure not to use the app delegate as some basket where you can just throw all shared state and functionality in the app. I’m working with some code where someone did this right now, and it’s extremely hard to change and refactor functionality.

This is just a version of the well-know problems of using global state for everything. In short, you should analyze functionality and divide it into separate classes, or groups of classes. Try to keep your app delegate as slim as possible!

EDIT: …and read Matt Gallagher’s post on this issue.