What Describes the Application Delegate Best? How Does It Fit into the Whole Concept

What describes the Application Delegate best? How does it fit into the whole concept?

In Cocoa, a delegate is an object that another object defers to on questions of behavior and informs about changes in its state. For instance, a UITableViewDelegate is responsible for answering questions about how the UITableView should behave when selections are made or rows are reordered. It is the object that the UITableView asks when it wants to know how high a particular row should be. In the Model-View-Controller paradigm, delegates are Controllers, and many delegates' names end in "Controller."

At risk of stating the obvious, the UIApplicationDelegate is the delegate for the UIApplication. The relationship is a bit more obvious in Cocoa (Mac) than in Cocoa Touch (iPhone), since the NSApplication delegate is able to control the NSApplication's behavior more directly (preventing the application from terminating for instance). iPhone doesn't permit much control over the UIApplication, so mostly the UIApplicationDelegate is informed of changes rather than having an active decision-making process.

The UIApplicationDelegate isn't strictly available from everywhere in the app. The singleton UIApplication is ([UIApplication sharedApplication]), and through it you can find its delegate. But this does not mean that it's appropriate for every object in an app to talk directly to the app delegate. In general, I discourage developers from having random objects talk to the app delegate. Most problems that are solved that way are better solved through Singletons, NSNotification, or other delegate objects.

As to its creation, on Mac there is nothing magical about the app delegate. It's just an object instantiated and wired by the NIB in most cases. On iPhone, however, the app delegate can be slightly magical if instantiated by UIApplicationMain(). The fourth parameter is an NSString indicating the app delegate's class, and UIApplicationMain() will create one and set it as the delegate of the sharedApplication. This allows you to set the delegate without a NIB (something very difficult on Mac). If the fourth parameter to UIApplicationMain() is nil (as it is in the Apple templates), then the delegate is created and wired by the main NIB, just like the main window.

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

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

What is the AppDelegate for and how do I know when to use it?

I normally avoid the design approach implied by Andrew's use of the term "heart of your application". What I mean by this is that I think you should avoid lumping too many things in a central location -- good program design normally involves separating functionality by "area of concern".

A delegate object is an object that gets notified when the object to which it is connected reaches certain events or states. In this case, the Application Delegate is an object which receives notifications when the UIApplication object reaches certain states. In many respects, it is a specialized one-to-one Observer pattern.

This means that the "area of concern" for the AppDelegate is handling special UIApplication states. The most important of these are:

• applicationDidFinishLaunching: - good for handling on-startup configuration and construction
• applicationWillTerminate: - good for cleaning up at the end

You should avoid putting other functionality in the AppDelegate since they don't really belong there. Such other functionality includes:

• Document data -- you should have a document manager singleton (for multiple document applications) or a document singleton (for single document applications)
• Button/table/view controllers, view delegate methods or other view handling (except for construction of the top-level view in applicationDidFinishLaunching:) -- this work should be in respective view controller classes.

Many people lump these things into their AppDelegate because they are lazy or they think the AppDelegate controls the whole program. You should avoid centralizing in your AppDelegate since it muddies the areas of concern in the app and doesn't scale.

#define for AppDelegate

If it's a more recently started project, your delegate is probably called AppDelegate. To find out, you have to find the class in your project that implements NSApplicationDelegate or UIApplicationDelegate (depending on your target platform).

Where does the AppDelegate file fit into MVC?

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.

What is an the function of AppDelegate and Context in swift?

Have a look at the following figure for visual understanding of Key objects in an iOS app:

Role of AppDelegate:

The app delegate is the heart of your app code. It handles app initialization, state transitions, and many high-level app events. This object is also the only one guaranteed to be present in every app, so it is often used to set up the app’s initial data structures.

AppDelegate is used for the whole app, you can use it to manage the app life cycle, on the other hand, ViewController is used for a single view. you can use it to manage life cycle of a view. One app can have multiple views. but only one AppDelegate.

Role of NSManagedObjectContext:

The NSManagedObjectContext is a fundamental concept of Core Data.It is like transaction in a relational data. You can fetch objects, you can create objects , update and delete them, save them back to the persistent store, etc. Basically for all the core data operations, you will need to interact with NSManagedObjectContext.

What are AppDelegates in Objective-C?

Let's back up a little bit.

The square brackets ([ ]) are Objective-C's method calling syntax. So if Cocoa had a C# syntax, the equivalent syntax would be:

TodoAppDelegate appDelegate = UIApplication.sharedApplication.delegate;

In C#, you would use a static class for a class that only has a single instance. In Cocoa, the Singleton pattern is used to accomplish this. A class method (in this case, sharedApplication) is used to retrieve the single instance of that class.

Delegates in Cocoa are not like the delegate keyword in C#, so don't be confused by that. In C#, you use the delegate keyword to reference a method. The delegate pattern in Cocoa is provided as an alternative to subclassing.

Many objects allow you to specify another object as a delegate. Delegates implement methods that those objects will call to notify them of certain events. In this case, UIApplication is the class that represents the current running application (similar to System.Windows.Forms.Application, for example). It sends messages to its delegate when things that affect the application happen (e.g. when the application launches, quits, gains or loses focus, and so on.)

Another Objective-C concept is the protocol. It is similar in principle to a .NET interface, except that methods can be marked as @optional, meaning they classes are not required to implement the methods marked that way. Delegates in the iPhone SDK are simply objects that conform to a specific protocol. In the case of UIApplication, the protocol delegates must conform to is UIApplicationDelegate.

Because it's not required to implement every method, this gives the delegate flexibility to decide which methods are worth implementing. If you wanted to, for example, perform some actions when the application finishes launching, you can implement a class that conforms to the UIApplicationDelegate protocol, set it as the UIApplication instance's delegate, and then implement applicationDidFinishLaunching:.

UIApplication will determine if its delegate implements this method when the application finishes launching and, if it does, call that method. This gives you a chance to respond to this event without having to subclass UIApplication.

In iPhone applications, developers also frequently use the app delegate as a kind of top-level object. Since you don't usually subclass UIApplication, most developers keep their global application data in the app delegate.

---

Related Topics