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.