[MUSIC] As we work towards our next peer review assignment, we need to touch base on something that's very unique to developing for mobile platforms. And that's the nature of the life cycle that's present in mobile development. In particular, we're gonna look at the life cycle in iOS app development. What's unique about iOS programming, is that your program is running in an environment that's very mobile and very embedded in people's lives. And as a result, at any given moment, the device that your app is running on may be needed for something else that's much more important than what you're working on. Probably the highest level priority that a phone has is to actually answer a phone call. And so in that case, if your app is running and a phone call comes in, your app is gonna be suspended, or it's gonna be put in the background while other things are attended to on the phone. Similarly, at any time the user can decide that they wanna switch to a different app. And unlike in a traditional laptop or desktop environment, where your program continues to run as long as your user doesn't actively stop it. In a mobile development platform, where in comparison the resources are much more limited, in terms of memory and CPU and attention of the user, a different way of managing the lifecycle has emerged. At a high level, apps, as we know, are run by the iOS operating system. And iOS defines the ways in which apps start, run, and end. And this process of an app starting, and coming to the foreground, and being temporarily paused for the user to do something else or answer a phone call. This is called the lifecycle of an app, as it goes from being launched by a user, to being taken out of the active set of applications that are running on the phone when it ends, that's the life cycle. So for example, if a phone gets a phonecall on which your app is running, you're app is going to be immediately suspended. So there are basically five different life cycle states that are present in an iOS operating system. They proceed in a very specific way from the left to the right and they correspond with different situations. That you've probably seen your device that you're working with exist in at various points. So the first state that your app can be in, is not running. Your app has never been started, or it's been terminated in the past. It was running at one point, but it's been terminated by the system. And this means that your app is completely removed from memory. There's no current state present in your phone. And this picture on the right shows an example of a home screen for an iOs device in which your app may be present on the device because it's been loaded onto the device. So it's available to be run, but it's not in any kind of a running state right now. When your app is in a not-running state, it can only proceed then into an inactive state, and then usually quickly into an active state. In an inactive state, the app is in the foreground, but it's not receiving any events, meaning a user can't interact with the app directly. It is usually executing some code, it's just not the code associated with the user interface. And this moment when it's inactive, is also usually brief. So an example of when your app might be in an inactive state, is when you have a pop-up window, a modal window of some kind that takes control of the screen real estate, and won't allow your app to be interacted with until it's cleared. So this is an example of a poorly written UI alert controller that doesn't actually have a clear button. But in this moment, the app in the background is inactive. Another time when your app is inactive is when it's just for a moment loading. And in that moment when it's doing all the housekeeping and getting set up for the user to run, it's inactive until the user can then work with it. Once a user can interact with your app, it's said to be in foreground or in the active state. This means that it's running, it's doing what it was designed to do, what it was coded. It is responding to user interface actions and whatever actions the app is setup to respond to. This is the normal situation for a running app. This is what we expect when we see an application running. If for some reason your app needs to get swapped out cuz of phone calls come in or because the user wants to do a different app, it will go briefly into the inactive state. This is just like for a moment, the user's unable to access it. Then it will shift into a background state. The background state usually is also short. In this case, the app isn't in the foreground. The app is executing code. And usually it's about to be suspended. So I have this picture over here on the right showing the most recent method for switching between apps. And I only show this because in the very moment when your app is no longer being run and the user's switching to a different app, for a brief moment your app goes in the background before becoming suspended. Now there are some apps that stay in the background running indefinitely, sometimes in a low power mode, sometimes in a limited mode. But these are things that are keeping track of some active state of your device. For example, you might have an app that's keeping track of your position so that it can reconstruct the trail that you took when you were hiking, a GPS or something like that. In that case, the app may be running in the background for a long time, consuming CPU cycles and battery. Unless you've specifically designed the map to do that, it will be moving quickly from the background state into the suspended state. Now, the suspended state, I've left the same image of the screen capture up here on the right. The suspended state is when your app is loaded into memory, so basically when it's in this multitask view that you can swap through. You can see that it's been frozen. So it's in the background. Not in the background state but it's in the background of the users attention. It's not executing code. And the system has moved your app into this state automatically and hasn't necessarily, and has hasn't period, told your app that it's doing this. And in this moment, your app is in memory but it's frozen. All its data structures, all its actions, everything has been stopped while something else takes control of the forefront of the phone. If subsequently the user loads more and more applications or more and more events happen that require the phone to deal with a low memory condition, suspended apps may be terminated entirely. If a suspended app is terminated entirely, you go back around to the not running state. And so, between these five states we see the lifecycle of the application, going from not running to inactive to active, and then from active to inactive to background into suspended. Now from a users point of view, the user isn't thinking about any of this. These concerns about the lifecycle states are really concerns that are primarily a developer's concerns. And the developer has to be aware of these different states, and aware of how the user experiences them, so that the developer can present a consistent view for this application. Although this isn't immediately a concern of ours in a peer review assignment, any time in the near future. You could imagine that if a user was editing some kind of a document, maybe an email or a word processing document, and it was in the active foreground state. Something happened like a phone call came in, the user would expect that the data that they were working on would be retained. And you as a developer, have to make sure that when you go from the active to the inactive to the background state, you've saved all work in progress on your way to the suspended state. Because at the moment at which you become suspended, if you are terminated, anything that the user was working on would be lost because your running application has been ended. If you go into the suspended state and then you move back into the background state, back into the inactive state and then back into the active state. For example, if the user selects you from the multitasking view and selects you to come to the foreground again, that text that the user has been writing will still be there and you didn't have to do anything. But, if you didn't get reselected and you got swiped out, for example, in the multitask view if the user swiped up to knock you out of active memory, then anything that they were working on, unless you did extra to put it into persistent storage, will be lost. We're not gonna talk immediately how to deal with that, but I just want you to understand. Because we're about to need to know this in the push notification example, that your app can be in all of these different states at a given time. And knowing about that is important for developers. So, in summary, there are 5 states that your app can be in, not running, inactive, active, background and suspended. And simple apps don't really need to worry about the state. Only when your app becomes more complex, when your user is investing more work into creation and some sort of generation of content. Only then does it become necessary to handle these different states carefully to produce a good user experience. Okay, so in our next lecture, we're gonna see one place where we need to take care of this. [MUSIC]
