iOS apps have an organized flow behind the scenes. Often, you don't have to interact with that flow directly. This video shows the flow of an iOS app, including the UIApplication object and the event loop.
- [Instructor] So, let's talk about the lifecycle of an iOS application. The main object in an iOS application is this UI application object. If you look at the key at the bottom, you'll see that that is a system object because it's peach. Green represents custom objects like our application delegate and our model data and blue can be either system or custom object so those are our views and our view controllers. So, what is this actually saying? Well, the UI application's job is to manage the event loop.
In other words, it interacts with the operating system and the device. So, for example, a user touches a screen. That's what's going to come in through the event loop and the UI application can get that information. The UI application object can notify the application delegate. We'll talk more about the application delegate later on in this course, but know that that's going to be one of your classes in your code and that rather than interacting with a UI application directly, you manage its events that come from the event loop in the application delegate.
Some of those events are sent to the UI window which manages all of the views in your application. This is another object like UI application where you don't necessarily manage it directly most of the time. Usually, you're just working in your views and in your view controllers. According to this chart also, note that the application delegate in the controller section can interact with your model or your data for your application and your view objects which are the visual elements of your apps.
For more information, you can read the documentation on this page about those different elements and what they do. Let's scroll down to the main run loop section and look in detail about what this event loop did from the previous diagram. So, in this diagram at the top left, we have a user touching an iPad. That touch notifies the operating system so we have a touch on the hardware. It tells the operating system that a touch occurred and it brings that into this event queue.
The event queue organizes events like touches or rotating the app and causing the gyroscope to respond. It organizes all these events inside of an event queue so we have them processed in the order in which they were received. From the event queue, they go in order into the main run loop which is running on the main thread, making sure that all of these user interface events or touch events or things that are coming from the device are executed in order.
That notifies the application object which then notifies your core objects or your custom objects in your code. For a touch for example, you don't handle that in your application delegate class because it's a view event. It occurs on a screen and so you handle that through your UI window object which sends that information to your view controller classes so you can figure out where the touch occurred and respond to it appropriately. The application delegate object is usually for handling system events like the application opening and closing.
So, let's scroll down and look at how that process works. And again, there's more information here if you'd like to read about it yourself. Scroll down to this figure 2.3 and talk about the state changes for an iOS application. So, there are several different states we can be in. An app delegate is the way that you manage the transitions between each state. In other words, you can respond when the app opens up and becomes active or when it closes.
So, we have these different states here. Not running means your application is of course not running. And there's foreground section which is green says first inactive so your app can be showing on the screen but not receiving any event so that usually means it's about to go into the background so this is usually a transition phase. Then we have the active phase. That's the normal state of your application. It's running, the user can see it. We have this background phase and that means your application is in the background and it can execute code.
And then there's also the suspended phase which is the same as the background phase except for it's not executing any code. And following these arrows, the app can transition between these different phases. Using your app delegate class, you can handle these methods listed below in the links to respond to when the state is going to change to a different state or after it did change to a different state. We'll talk about that more throughout this course. But for now what I want you to take away is that we have this main loop for application.
The UI application manages all the events received and sends them to the appropriate locations and we can respond to them either in app delegate or in our view controller objects for certain types of events.