Where does the AppDelegate file fit into MVC?

Question

I'm learning iPhone/iPad programming. I believe I understand the concept of MVC; what I'm having difficulty with is understanding how some of the files in a normal iPhone/iPad application fit into MVC.

When you create a new application using the "View-Based Application" template an AppDelegate.m and AppDelegate.h file is created.

Is that a Model, View, or Controller file? I'm guessing it's actually none of those. I wish I could see a diagram or a process flowchart that shows what category each file in the application falls into.

Answer 1

I view the AppDelegate as a controller because that kind of code

- (BOOL)application:(UIApplication *)application 
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Override point for customization after application launch.

self.window.rootViewController = self.viewController;
[self.window makeKeyAndVisible];
[application setStatusBarHidden:YES withAnimation:NO];
return YES;
}

AppDelegate is a place to setup links between models and views.
In the AppDelegate you place code that is specific to your application.
View and Model should be able to live in an other application (Like a UIView class), because they are not application specific.
This is more obvious in a Mac Desktop application, there is more to do in that Delegate.

Answer 2

The application delegate is a controller object. By default, it is the owner and controller of the main window -- which is a view -- in an iOS app. The app delegate receives messages from an object representing -- or modeling -- the application itself (an instance of UIApplication). It mediates between the application object, which is the contact point between the app and the system, and the display of the app.

Answer 3

Not every file will fit a particular category, however, I would have to say in this instance the AppDelegate is a controller, it doesn't visually present data (a view) nor does it represent the actual data (a model) but it does determine what view controllers to show etc and manage other views (status bar etc) at the start of the application.

I wouldn't worry too much about trying to classify every file into MVC, some just won't fit perfectly, if at all.

Answer 4

This is an old question but I just asked myself the same question today. I think that the AppDelegate class cannot be classified as just a Controller only. It does control the Window and establishes its root controller so it can be classified as View Controller (note: UIWindow inherits from UIView). But it also performs more Model related tasks, like data persistence when the app is terminating. So it can be considered a Model Controller or involved with the the Data Access Layer as well.

It is also responsible for handling URL opening. This can cause a View change but also will definitely require Model related tasks like parsing, persisting, updating, authenticating, etc. If the View/Model are bound via KVO simply updating the model could cause the required Views to update. I feel that this would be a be a much better setup. Also, the fact that by default all of the Core Data stack is added to the AppDelegate moves it away from just being View-related.

It think the fact that it is responsible for anything dealing with the app causes it to have multiple purposes. Perhaps this is why developers end up throwing any and everything in here. It is the manager of the app both in the sense of root controller, the app service layer, and app model manager.

Since the AppDelegate is the entry-point to the app (for the developer), it makes sense to talk of it in terms of the App. App is terminating, app is entering background, etc. We are talking about the app as a Model entity.