AppController


#1

Im reading CoreData chapter and at the end of creating the model file, they rename the appDelegate, AppController.

Why? It doesn’t really say why…


#2

It’s just a style preference, based on a little history.

“AppDelegate” seems to infer the object has only one role: be the delegate of the UIApplication object. In reality, it is responsible for setting up all of the initial view controllers, the window and serving as the handler for OS<->Application messages. Therefore, a more appropriate name is AppController, since it is a “controller of controllers”.

This is more or less a naming convention from Mac OS X, where every application had an AppController that had similar responsibilities.

Something I’ve found interesting: The name AppDelegate has the connotation of having a very simple job, but many people put a lot of code in the AppDelegate. In other words, the name is “small” and the work it does is “large.” The name AppController is pretty apt: it’s a powerful word with an obvious meaning. The name says, “I’m the top-level guy, I don’t get into details, but I know all the guys who do get into details.”

Optimally, the class should be called AppController, and it shouldn’t dive into any details of the application. One way of picking out amateur code is to see the following line in some file:

    QuizAppDelegate *appDelegate = (QuizAppDelegate *)[[UIApplication sharedApplication] delegate];
    [appDelegate doSomething];

#3

Right, thats what Ive seen and that was my guess of what it should be. Of course that makes sense, Im a novice. Im reading a book that says Second Printing, Aug 2010 and it uses that AppController idea.

But I downloaded the code, at least what I thought was the latest code and you use just the AppDelegate and something called a PossessionStore which does what I would think is the same, holds the same fetchAllInstances method and some other Possession methods such as remove, move, create etc. Which leaves me with 2 questions:

  1. Isn’t it the same, just personal preference then, to use the AppDelegate, the AppController or a Possession NSObject to do those tasks?

  2. It seems to me like create, move and remove would naturally be methods of the Possession NSObject itself. Is it just personal preference that you have it split up like that?

I would like your thoughts on the matter because I would like to know when it would be important to follow the AppController & Possession/PossessionStore convention you follow.