In the last lesson, we talked about the ViewController lifecycle. And we've seen methods like 1
viewDidLoad, viewDidDisappear, 2
all of these in action. The iOS operating system automatically calls these methods as a ViewController 3
is being created, it becomes visible, or recedes into the background. 4
But ViewController is just a single screen, right? 5
So what about the app as a whole? 6
Well, for that, we need to zoom out a bit and look at the bigger picture. 7
We need to look at the application lifecycle. And the app's lifecycle usually starts with the app being 8
launched, to the app being visible, and then the app receding into the background. 9
And finally, the app being destroyed and the resources reclaimed for other apps. 10
That last part is actually a key to understanding how iOS works. Resources like CPU time or memory 11
are limited, and the operating system always has to decide how to allocate these resources. 12
So how does iOS decide what to prioritize? 13
Well, it prioritizes whichever app is running in the foreground because that's what the user is looking 14
at, 15
and that's what they're using right now. 16
But why does this matter to you as the app developer. 17
Why should you care about the app lifecycle? 18
Well, imagine your users are playing your game and they just beat a boss, or your user's just filed a super 19
long registration form, 20
if your app now goes into the background and iOSdecides to reallocate your app's memory to another 21
app, then your users will lose all of their progress and all their data, unless you've already saved the 22
app's data. 23
But how would you know at which time point to save your user's data? 24
Well, you should do it at the point in the lifecycle when your app is going into the background. So that's 25
one example. 26
But thinking back to our chat application and working with Firebase, we've come across another use case 27
for the lifecycle methods as well. 28
So you need to do something before any other part of the code in your app is executed. Well, in the case 29
of our chat application, 30
the very first thing we needed to do was to configure the app. And that's why we added 31
Firebaseapp.configure into the application:didFinishLaunchingWithOptions lifecycle method. 32
That way, we can figure our app and read the GoogleService-info.plist from the disk before anything 33
else could happen. 34
So that means application:didFinishLaunchingWithOptions, 35
this helped us respond to the event of our app being launched and guarantee that this code was executed 36
before anything else. 37
So where can we find these app lifecycle methods? 38
If we take a look at our bog-standard sort of template for any iOS app, you'll see that from iOS 13 39
and any new apps created using Xcode 11, 40
you get a AppDelegate and a SceneDelegate file for free. 41
Anytime you create a new iOS app, it's in these two files, 42
the AppDelegate.swift and the SceneDelegate.swift files that the app lifecycle methods are 43
found. 44
So what's the difference between these two files and what's a scene anyways? 45
Now, previous to Xcode 11, we only had one file which was the AppDelegate and this was the file 46
where the iOS operating system would let our app know which point we were in in terms of the app 47
lifecycle. 48
So that's how it was for iOS 12 and below, all the lifecycle methods used to be in the AppDelegate 49
Swift. 50
But as of iOS 13, and especially with iPadOS, apps now can run in multiple windows. 51
What this means is that there can be multiple windows running different instances of your app. 52
In other words, there are two separate scenes. 53
That's why we now get a SceneDelegate that reports back to us on the lifecycle of each of these windows. 54
If one of the windows goes into the background, then the SceneDelegate for that window gets notified. 55
So if you're a developer who's come from iOS 11 or iOS 12 56
development, 57
don't be surprised by this SceneDelegate. 58
All it does is it treats each of these windows being open as a separate scene. So the way works in apps 59
that support scenes is that events that are common to the app are handled in the ApplicationDelegate 60
and all the other lifecycle callbacks are in the SceneDelegate. 61
So what's common to the app as a whole and handled by the application delegate? 62
Well, it's things like being launched or receiving a time change from the network carrier. And what about 63
the SceneDelegate? 64
What does the SceneDelegate handle? 65
Well, it'll be things like a window becoming visible or going into the background. 66
This is very similar to the view controller in a way. The way that it all fits together is you can have 67
multiple ViewControllers in one scene, and you can have multiple scenes in one application, and each 68
of these have lifecycle methods that you can override. 69
So let's take a look at some of these points which we can override. 70
For example, we've already seen in the FlashChat app that we can tap into this didFinishLaunchingWithOptions 71
method in order to set up Firebase or create a new database or whatever it is that we need 72
to do as soon as the app launches. And then later on at other points of lifecycle, 73
for example, if our app was interrupted by a phone call, right, 74
let's say, mom calls us, and we were in the middle of filling in a form, then it's a good idea for the 75
apps developers to put some code in here to deal with any of these temporary interruptions. 76
So let's say that we were playing some music in Spotify and a phone call comes in, 77
then it's a pretty good idea to tap into these methods, and maybe pause the music, or turn the volume 78
down, or whatever it is that you may need to do. 79
And then there's other methods like sceneDidEnterBackground and this is the moment when your app 80
goes from the foreground to the background, 81
and this is a really good time to save a user's data. So if they were filling in a form and it so happens 82
that the app enters the background, then it's a good idea to actually save what they've typed in because 83
the next time point where the app actually gets destroyed can be unpredictable. 84
Let's say that the user decided to play fortnight on their phone and it's requesting a lot of resources, 85
then your app that's resting in the background might actually just get killed silently. 86
So as soon as your app or your scene enters the background, then you can use this part to save any data 87
that's associated with the user, 88
so you don't lose it. 89
And the next time that the scene enters the foreground or when the window comes back online, 90
then you can use the data saved there to repopulate any of the fields that might be empty. So similar 91
to before, 92
I've added some print statements in each of these methods so that we'll get to see at which time points 93
they get called. 94
Now, I'm using this syntax when writing print #function and what this will do is it will print 95
the name of the function. 96
So in this case, it will be application: didFinishLaunchingWithOptions. 97
So let's go ahead and hit run and see which of these methods get called when. 98
So notice how 99
as soon as my app launches, the first thing that happens before anything else, before viwDidLoad, or 100
before anything like that, is the application: didFinishLaunchingWithOptions. 101
So that's the first entry point. 102
Next, it calls scene (_:willConnectTo: options:) which is what creates our new scene and shows this 103
new window. Next, we actually see some methods from the ViewController. 104
So the viewDidLoad being called, viewWillAppear being called, and in-between viewDidAppear and 105
viewWillAppear, our scene enters the foreground and becomes active. 106
Now, the next things that I do inside my ViewController don't affect the app lifecycle. But if I go ahead 107
and bring my app into the multitasking screen like so, then you can see that my sceneWillResignActive 108
has now been triggered. 109
Now, if at this point I navigate to a different app, then you can see that my scene actually enters the 110
background. 111
Now, don't worry if you see a warning message like what I've got here, it seems to be a bug in its Xcode 112
itself, and it's actually not related to the warning that it's giving you. 113
Hopefully, at some point, the Apple team will fix this and you won't actually have to look at this warning 114
message. But in case you are, don't worry, it's nothing related to what you've done. 115
So, now that my scene has entered the background, if I go ahead and find it on my home screen and launch 116
it again, you can see that the scene now enters the foreground and becomes active. 117
But if instead of navigating to a different app, but instead, I actually just click-drag and throw it 118
away, then that destroys my application and the application(_:didDiscardSceneSessions:) gets triggered. 119
And this is a point where my app gets killed. 120
So all of these different time points are there for you to tap into 121
depending on what needs you have. And if you want something to happen before something else happens or 122
after something else happens, then you can use a variation of the app lifecycle methods, the SceneDelegate 123
lifecycle methods, and the ViewController lifecycle methods to be able to achieve this. 124
So I hope that's been informative. 125
If you want even more details on the app lifecycle or the ViewController lifecycle, then be sure to 126
check out the course resources page where there are some links to some extra reading if you want to 127
know more. 128
But now that we've completed the FlashChat app, it's time to review the code that you've written. 129
And if there's anything in there that you don't understand, then be sure to review the lessons where we talked 130
about them so that you are ready to move on to even more advanced stages in the next modules. 131
So that's all from me for this module and I hope to see you on the next one.