Is It Ok to Place Most Logic and Models in the Appdelegate

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

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

Best location for data and logic for possibly shared iPhone/iPad app

You can move your common data and business logic into a separate set of model classes outside of the UI layers and appdelegates. This is one of the main benefits of the MVC pattern - by separating and making a clear distinction, it's easy to have separate view layers (one for phone and one for iPad).

That means all the data (dictionaries), logic with your random numbers and timers would be encapsulated and shared. That also allows you to cleanly unit test the majority model and logic programmatically. It also means you can make substantial changes to your algorithms and minimize the code churn.

When the timer goes off it can either post a notification or you can have a delegate pattern where it does a call back.

Related Post: Delegates vs. events in Cocoa Touch

If you do a shared model, one option is to use a singleton pattern where you access the model like:

[MyModel sharedInstance];

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.

importing AppDelegate

Is this the the correct way for accessing these variables or should I
be doing something differently?

You'll find that different people have different opinions about this. The style that I prefer is to have the app delegate pass the necessary information to the first view controller, and have that view controller pass it on to whatever view controllers it creates, and so on. The main reason for this is that it prevents child view controllers from depending on things that they have no business knowing about.

If you have some detail editor, for example, you want to be able to pass that editor exactly what it needs to do its work. If you give it that information, the editor is completely flexible -- it'll edit any information that you give it. If the editor knows that it should get its data from some external object, like the app delegate, then it loses some degree of flexibility -- it can only get data from the thing that it knows about.

So, it's fine to set up your data model in the app delegate. But when it comes to providing access to the model, think: tell, don't ask. That is, have the app delegate tell the first view controller what model object to use, and have that controller tell the next one, and so on. If you have to ask, you have to know who to ask, and that's where the dependencies start heading in the wrong direction.

every time I import AppDelegate into a .m file to access these
variable's data I feel like I'm doing some wrong.

Trust that instinct. Think about why it feels wrong.

Code in app delegate vs View Controller

AppDelegate is a singleton instance where as viewControllers are not. So adding a AppDelegate as delegate to GIDSignInDelegate gives you flexibility to trigger Firebase authentication methods from whichever the view controller you want and without worrying about setting your view controller as delegate in viewDidLoad. Because usually login states are gloabal to app and not just to specific ViewController it makes sense to add singleton as a delegate to GIDSignInDelegate but then app delegate need not be a place to dump all code, rather u can create a separate singleton class of your own – Sandeep Bhandari 23 hours ago
upvote
flag
and enjoy all the benefits of singleton while keeping your app delegate clean. There may be scenario where login/signup appears on different ViewControllers in app, rather than adding each such VCs as delegate every time in ViewDidLoad it makes sense to have one common instance that deals with authentication process. Because this instance needs to be available to all Classes in your app making singleton instance makes sense but using app delegate does not. AppDelegate is not a dump yard for all common code in your app – Sandeep Bhandari 23 hours ago

Where to place the Core Data Stack in a Cocoa/Cocoa Touch application

Summary: There is no need to create a singleton to manage the Core Data stack; indeed doing so is likely to be counter-productive.

The Core Data stack happens to be created by the application delegate. Importantly, however, as all the examples show, the stack (principally the managed object context) is not retrieved directly from the stack(*). Instead the context is passed to the first view controller, and from them on a context or a managed object is passed from one view controller to the next (as described in Accessing the Core Data Stack). This follows the basic pattern for iPhone all applications: you pass data or a model controller from one view controller to the next.

The typical role of the singleton as described here is as a model controller. With Core Data, the managed object context is already a model controller. It also gives you the ability to access other parts of the stack if needs be. Moreover, in some situations (as described in the documentation) you might want to use a different context to perform a discrete set of actions. The appropriate unit of currency for a view controller is therefore usually a managed object context, otherwise a managed object. Using and passing a singleton object that manages a stack (and from which you retrieve a context) typically at best introduces a needless level of indirection, and at worst introduces unnecessary application rigidity.

(*) No example retrieves the context using:

[[UIApplication delegate] managedObjectContext];

Is the app delegate class needed? (design suggestion)

The app delegate provides a centralised, application-wide class that can be used to co-ordinate behaviour across your entire application. You can consistently access your App delegate using the [[UIApplication sharedApplication] delegate] method - this is incredibly powerful.

It's also responsible for handling iOS invoked behaviour (applicationDidBecomeActive, applicationWillTerminate, etc) so with that in mind it's a good place to wire some of your application together (perhaps you're loading from xib's and need to add views, for example) or to handle application lifecycle logic.

Note of caution; it is a little too easy to overuse the app delegate. Without considered design and development it can quickly become a unmaintainable mess. Personally I have a rule; I only use it for application lifecycle work and to coordinate between the component parts of my application, and it's rarely invoked directly from the UI layer.

---

Related Topics