Menu
For most of my apps, I have placed all the logic in classes, that each ViewController would get a reference too the class, or create/release the object itself.
I just started reading a book on IOS, and the author seems to like to put the app logic in the appDelegate, and the viewcontrollers just relay the actions to the appDelegate methods who do the real work.
Is the author just doing this because they are simple examples, or is this something I should learn, and start to do in my apps?
715
AppDelegate is responsible for handling application-level events, like app launch and the SceneDelegate is responsible for scene lifecycle events like scene creation, destruction and state restoration of a UISceneSession.
The app delegate is effectively the root object of your app, and it works in conjunction with UIApplication to manage some interactions with the system. Like the UIApplication object, UIKit creates your app delegate object early in your app's launch cycle so it's always present.
Save this answer. Show activity on this post. AppDelegate is responsible for handling application-level events(like app launch), application lifecycle, and setup. SceneDelegate is responsible for handling what is shown on the screen (Windows or Scenes) and managing the way your app is shown.
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 ).
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>.
98
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
