Today I’m going to talk a bit about the AppDelegate. In every demo project, and most of the times (I currently don’t know any examples where it does not) in every app, there is an class named AppDelegate.
The app delegate is the entry point in an iOS application, here the app we are developing will receive different notifications regarding its state, push notifications and here is also the place where the app initialisation takes place.
Every iOS application has a lifecycle composed of 5 different states.
- Non-running – the application does not run, has NOT been launched
- Inactive – the application is in foreground but does not receive events, this is a transition state, and we usually find the app in an inactive state when launching the application or when the application runs and we receive an phone call
- Active – the application is in foreground and receives events (the application is open, we can interact with it)
- Background – the application runs in background and executes code (for eq. in an navigation app, fetching the current location of the user, and alert the user that its gonna need to change direction)
- Inactive – the application is in background and does not execute code (the application can become active if we tap the icon again, or press on the home button for all the apps to be displayed and select it from there, the application is loaded in memory, to not be confused with the non-running state)
The app delegate is and singleton and is baiscally an object that comforms to the UIApplicationDelegate protocol. Besides the AppDelegate, every project has an singleton object of UIApplication type, which actually does all the hard work, and it just passes its events to the AppDelegate class of our application.
This means that the AppDelegate is an object that can be accessed during the whole time an iOS application is active, and keeps its state (is a singleton we don’t have multiple instances).
One common pattern when beginning to develop apps for iOS is to have a fat AppDelegate and multiple links with other classes from your app, as it keeps its state and is accessible from all over the app for beginner is the perfect place to keep different informations. The app delegate should be lightweight, should only handle the state changes of the app, and the initialisation of it, everything else, different properties or variables most of the times they should NOT be there.
What I do for my apps in order to have a light app delegate is create classes for various classes of notifications. For eq. I have a class that handles all the push notification flow, basically the app delegate only tells my NotificationClass, that there is a new notification, the handling (the parsing of the notification, decide how to act on it) is done by my NotificationClass object. Respecting this rule, you’ll end up with a very light weight app delegate, and classes that are focused on only one job (as they should be, by respecting the “Single responsibility” from the OOP principles), which in the long term is easier to maintain and modify.
I’ve seen app delegates which had over 2000 lines of code, and I tell you now, thats some ugly stuff. We have to look at the app delegate like a phone company, its job is to link various people (the app delegate job would be to link an event to a handler), it should not care about how it can handle an event, it should only care about sending it to the right object for handling it.