Activity Lifecycle in Action
A free video tutorial from Tim Buchalka
Java Python Android and C# Expert Developer - 895K+ students
4.6 instructor rating • 12 courses • 897,882 students
Learn more from the full courseAndroid App Development Masterclass using Kotlin
Learn Kotlin Android App Development And Become an Android Developer. Incl. Kotlin Tutorial and Android Tutorial Videos
61:50:31 of on-demand video • Updated January 2021
- Learn the core Android app development and Kotlin skills to build real Android apps.
- Learn how to target current and older versions of Android when writing your apps.
- Understand how to create Android apps using Kotlin.
- Be able to apply for Android app development roles.
English Okay we're now ready to run the app and investigate the various stages of the activity lifecycle. Now before I do that, though, I wanted to talk briefly about the panes down here, these various windows that you can pop up, and that's because you can actually reposition them, using the cog wheel over here on the right hand side. So I'm going to come over here and choose Floating mode from the pop-up menu. Once we do that, you can see we've got just a little window that is now separate from the main Android Studio window, and we can move that around. So that can be really handy if you've got a single monitor, because you can display that and the emulator at the same time, or we can actually see a lot more screen real estate which we're going to be doing here in this video. But it's also useful if you've got two monitors, because you can put logcat on one window and the main programming code, your designer and so forth, and see the code on the other monitor, so quite handy. Alright, so let's run this app. So I'm going to leave this logcat open here, run our app. I'll just need to click that to bring that back on the screen again, and I'll also bring the emulator over. So there's our app, and you can see over here now in logcat, that the onCreate method's been called, up here, then the on Start and then the onResume. And that's what we would've expected from the activity lifecycle. Now because this was the first time the app was launched, there's no state to be restored, so consequently onRestore InstanceState wasn't called. Alright, so let's add some text now and click the button a few times and keep an eye on the logcat, because what we're going to do is try rotating it into landscape mode. But first, I'm going to enter these three items; bread - and you can see onClick has been called in the logcat there - milk, cheese. So we've got three items there, and what I'm going to do is make sure there's some text in the editText and then we're going to move it into landscape mode. So I'm going to type in cream here, then move over to landscape. Then you can see we've still got cream showing there, and we can see that over here now, the various events that were called. We had our onClick method called three times, which you would have expected for the three items because I didn't click the button the fourth time. But then what happened was, when the device was rotated, the onPause method was called, followed by onSaveInstanceState, and then on Stop and then onDestroy. And you may have seen that the app briefly vanished from the device screen, briefly, while it was rotating into landscape mode. Now because it was Android destroying the activity, and it was in the foreground, Android then recreates the activity again. So that's where the onCreate, on Start is actually called. And because we've got now some state because on SaveInstanceState was called prior to going into landscape mode, as a result, on RestoreInstanceState is called automatically by Android. And then finally, we've got on the onResume method being called as well. And after that the app's once again running in the foreground, which it's doing there now. So let's add a comment down here, just so we know where we're at. We'll type in Back Button, because what we're about to do is now select the back button to move back. Firstly, I'm going to remove the keyboard by pressing back, so we're not expecting anything to be called there. But now if I actually go back again, it's gonna close the app. And what's happened here, you can see that when I've actually done that, we've got onPause called, onStop called and then on Destroy called, and obviously at that point the app was then closed. Note that there wasn't a call this time, to onSaveInstanceState, and that's because the state won't be restored when the app's relaunched. Because Android only restores state if it was responsible for destroying the activity. Now if the user chooses to close the app, then they wouldn't expect it to start up with the data already in the editText from the last run. With that said though, they may however expect to see the bread, milk and cheese in the TextView, but if you wanted to save those results, then onStop would be the place to do that. Now because the logcat gets cleared when we run an app from Android Studio, what I'm going to do is use the emulator's app screen to launch our button click counter app again. So I'm gonna type in a comment though, into logcat first, and just put launching app, and then I'm going to come back here and we're going to launch the app. I'm going to do that sideways because I'm still in landscape mode, buttoncounterapp, I'm gonna click on that. There's our button counter app running again now, and looking at the log, you can see that we've got onCreate, onStart and on Resume called, so that's good. Then what we'll do now is, we'll just go back to portrait mode. There's portrait mode again there now, just so it's a little bit easier. We can see a bit more of the log and the application running on our emulator as well. And we can see now, that by doing that this second time, we've got onCreate called because I went back to portrait mode onStart. And onSaveInstanceState, by the way, was called just prior to, or just after we rotated the device back to portrait. So while it was still in that process of moving back to portrait, on SaveInstanceState was called. Then consequently down here, onStart, on RestoreInstanceState was called then onResume, and then we're back with the app running in portrait mode again. Alright, you can sort of see there, the lifecycle is being fairly consistent there. We'll type in Locking Screen next, so I'm gonna type Locking Screen into logcat, and what we're gonna do now is just that. We're going to briefly lock the screen, and on an emulator, we can do that by the power button. So if we just press the power button quickly, and just then release it fairly quickly, then that locks it, just like a real Android device would. If we hold it down it'll shut it down. So I'm just going to click it briefly, and there's our lock, so the application is now going to lock, bearing in mind we've got some extra bits and pieces showing here as well which we're ignoring. But the ones that we want to see here is the onPause called, onSaveInstanceState called and then onstop called. So note that the user hasn't exited the app as such. They've just switched off the screen, and that's why Android's calling onSaveInstance State after onPause. And onStop's then called and our app's now no longer running in the foreground. So I'm gonna add another comment down here now, and we'll put Unlock Screen, and we're gonna use the power button to unlock the screen. So I'm gonna click it once quickly again. So just like a normal Android app, we now need 180 to swipe to get back to where we were again. Alright, so at this point you might be wondering, the screen was locked, when the screen was locked, we had onSaveInstanceState called. So why wasn't onRestoreInstanceState called when we unlocked the screen? Well there's no reason to call it, and that's because the app, or the activity rather, wasn't destroyed, it was just stopped. So in other words, no state was lost and there's no reason to restore it. We can actually check that though. What we can do, is we can go ahead and enter our items again. So I can enter bread, milk, cheese, and we're going into cream again but this time we're not going to tap the button like we did last time. It'll lock the screen again, and you can see what's happened here. We've got, I think this is more Android Studio functionality problems here, because we've got the Unlock Screen and you saw that when I went back to it, nothing seemed to be working for a while. We weren't getting any entries into here, and then when I've locked the screen, we've suddenly got all these entries coming back through again. So the point I want to make here, though, is that after we unlocked the screen, we actually did get onRestart called and we got onStart called, and then we also got onResume called. All three of them were called very quickly, as you can see here by the time, over to the left-hand side. But the point was that onRestoreInstanceState wasn't called when we unlocked the screen. And again, the reason for that is that from Android Studio, there actually wasn't a reason to call it, and that's because the activity wasn't destroyed. It was just stopped, so no state was lost and there's no reason to restore it. You also saw, even though I've locked the screen now, we did get the onClick calls successfully being called when we clicked the buttons, as we would expect, but they weren't updated in the log. I suspect that's some sort of issue with logcat, probably because I'm running a beta version of Android Studio. You can see that they were actually called, and then when I locked the screen, we got on Pause called and then onSaveInstanceState called and then as well as onStop. So at this point, we've now locked the screen, and again onSaveInstanceState's called because Android might destroy the activity when the screen's locked. Now if updates start downloading or some other app wakes up, memory may get low. Because our app is no longer in the foreground, it's fair game for Android to destroy it if it needs extra resources. So that's the reason that onSave InstanceState is actually called here, when the screen's actually locked. Now with that said, though, unless Android does destroy the activity, then there's no need for it to restore the state. So that's way, in this case, it didn't call the onRestoreInstanceState when we unlocked the screen. So the same thing should happen now if I go to unlock the screen again. We've still got our items here so nothing's been destroyed, but our log is not working at the moment but, hopefully, that'll catch back up. But in any event, I can assure you like it happened last time, that the on RestoreInstanceState won't be called, and that's because the application was stopped and it wasn't destroyed. So it's just there as we left it, in other words. We can see that by the three entries that we've got here, and also the entry still showing in the editText. So again, if Android did destroy the activity, then we wouldn't expect to see our bread, milk and cheese here, because normally on the onRestoreInstance States is called, this isn't actually saved because we haven't written any code to do that yet. The only thing that is normally saved is this option, whatever we've typed in the editText. So again, unless Android does destroy the activity there's no need for it to restore the state, so that's why in this case, onRestoreInstanceState wasn't being called. It wasn't called last time and wasn't called this time either. But again, we can't really confirm that right now because Android Studio seems to be playing up a little bit, and it's not actually showing us all the logs. So I can see that it seems to just have been stalled there and it's not actually updating, and I can confirm that by trying to add a click on the button now. We've added that here but we're not getting any log intries in the logcat. So clearly a bug with Android Studio at the moment, but anyway, you've seen that work earlier in the video. So that's actually the activity lifecycle. So that technique, by the way, of adding logging to all the methods is great to see, or for seeing what's going on, and when various methods are called. Now it doesn't just apply to the lifecycle methods either. There's all sorts of situations where we have to provide callbacks for Android to call. Adding logging to them so that you can see exactly when Android does call them, is a very good way to develop your understanding of how Android works. Alright, so just to show you this before I finish this video, that the logcat should still be working. I believe it's a problem to do with Android Studio, probably linking to the emulator. So if I go to close this emulator down, hopefully, what we'll see is some errors pop up because I want to see one of those new log entries actually just come through. At the moment they haven't come back through, since we locked the screen for the second time. I'm gonna just try this again, start our API 26 emulator. At some point, we'll probably see these entries. So we're still not getting any logging output there. So what I might do is I'm just gonna close down Android Studio, but at some point what we do here, we should find this gets fixed up. This will be a good thing to show you if you're in a similar situation where you're getting a lock up and you're not seeing logcat working. The combination of these things should actually fix the problem. Alright, so I'm starting that again. I'm gonna go and open logcat, and as we would expect now, there's no logcat entry. We'll wait till it initializes. Alright, I can see we've got the three entries showing there, from our most recent call, and if I just go back to our emulator again and if I just run this again. So there's some sort of temporary issue there, probably again, relating to the fact this is a beta version of Android Studio where it's not doing the right thing. You can see we've now got the log entries working again. So what I want to do is just do that last bit of, that last testing and just to show that it is working. So if I type in these three entries again, so bread, milk and cheese, cheese, and if I type cream, but this time I'm not going to add that and I'm going to lock the device. So you can see the device was locked. We had on Pause called, onSaveInstanceState called and onStop called. So hopefully now, when i unlock it, we should see what I originally wanted to show you, was the onRestoreInstanceState not being called but being able to see the other entry. So let's try that, and you can see there, that's really what I wanted to show you early on, so clearly that was a bug with Android Studio. So onSaveInstanceState was called prior to us locking the screen, as well as on Stop and then, of course, previously onPause, but once we came back after unlocking the screen, we only got onRestart, on Start and onResume. We didn't get the on RestoreInstanceState being called, because unless Android does destroy the activity, there's no need to actually call that onRestoreInstance State. And again, if that was true we'd expect to still see our list, and cream in the editText when we unlocked the device, and you can see here, that clearly, it hasn't been destroyed because we can still see those items. Alright, so we got there in the end. We had a few problems with the software but we managed to get it working. So that's the activity lifecycle. Now that technique, adding logging to all the methods, is great for seeing what's going on and also when various methods are called. It doesn't just apply to the lifecycle methods either, because there's all sorts of situations where we have to provide callbacks for Android to call. And adding logging to them so you can see exactly when Android does call them, is very good way to develop your understanding of how Android works. Al right, so there's a few important implications of what we've looked at with the activity lifecycle. We're going to discuss those in the next video.