(upbeat music)
(keyboard typing)
In the previous video, we saw the lifecycle functions
that I called as a fragment is attached to it's activity.
We use the main activity fragment as the example
and showed the events that happen with an activity
that has a fragment in its layout.
Having a fragment in code is slightly different because
the activity will already have been started.
However, if you've added a fragment in code as we
do with the add edit fragment,
then the fragment is automatically reattached when the
activity gets recreated.
In that case, add edit fragment will follow exactly the
same lifecycle as the main activity fragment.
And its lifecycle will be tied to the
activity creation events.
So next we'll look at the lifecycle where the fragments
were moved from the activity.
This is the same whether the fragments in the layout
or was added in code.
Whichever method was used to attach the fragment to its
activity, its now attached.
And it will be detached if the activity gets destroyed.
Alright, so with this first slide, when our activity
leaves the resumed state, Android calls the functions shown
on the left.
We've only seen all this when we looked
at the activity lifecycle.
A number of events can cause the activity to leave
the resumed state.
We tend to focus on things like device rotation,
because Android will be recreating the activity for us.
Generally, that's the behaviour that causes us the most work.
Related to that are events such as the user switching
to another task, answering the phone for example.
Other things such as the user tapping the back button,
will also cause our activity to leave the running state.
In those cases we're less concerned because we don't have
to write code to cope with the activity being recreated.
When the activity goes through the stages of stopping,
our fragment also gets similar lifecycle events.
The first call back our fragment gets is on pause.
This doesn't mean that the fragment will be destroyed.
If the user has switched to another task, then the activity
and its fragments will remain in the paused state until
the user switches back to it.
Of course there's no guarantee that they will switch
back to the activity, and Android may well
destroy that task.
But bare in mind that on pause might be the last function
that gets called.
That fragment may be activated again and will get
on resume called.
On pause is a good place to save any data that the
user will expect to keep.
We've added a save button to the edited fragment,
but you should consider whether that's really an appropriate
thing to have in our UI.
When we've added the code to save the data,
you might wanna consider moving it to on pause.
The data will then be saved automatically when the
user leaves the fragment for any reason.
That would fit in better with expected Android behaviour.
But then we wouldn't have been able to show you the
button communicating with the activity.
On this slide, we're showing on save instance state here.
But it can be called any time before on destroy.
It won't be called before on pause but could be called
after on stop or on destroy view.
Any data you add to the bundle will be available in
all the fragment functions that receive a bundle.
Unlike the activity a fragment doesn't have an on restore
instant state function.
But there are plenty of other places that you can
retrieve the bundle.
Just remember that a fragment doesn't have a function that's
guaranteed to receive a non null bundle.
Always allow for the bundle being null in your code.
When on stop gets called,
the fragments in the stopped state.
It's no longer visible but hasn't been destroyed.
From here, the fragment may be resumed.
In which case, on resume will be the next function called.
If that happens the fragment still has all its state.
As a result it doesn't matter that on save instant state
may not have been called yet.
If the user does switch back to the fragment,
no state has been lost and everything will work fine.
We've seen that on stop may not get called,
if the user switches back to your activity.
That means you might prefer to save user data here,
in on stop rather than in on pause.
That would prevent saving the data in cases where
the user is gonna come back to the fragment.
The Google examples and comments on the internet,
all say that on pause is the best place
to persist user data.
But there's no reason why you couldn't defer doing so,
until on stop.
Whatever you choose bare in mind that you shouldn't perform
intensive operations on the foreground thread.
If the activity is being destroyed the fragment will
get its on destroy view function called.
So this is the function where the documentation for on
create view was a bit ambiguous.
On destroy view will be called even if the fragment
doesn't return a view from its on create view function.
Note that on destroy view will be called even if the
fragment isn't being destroyed.
As I mentioned if the activity is being destroyed
then the activities layout is also destroyed.
Because the fragment's view appears in the activity's
layout, the fragment's view has to be destroyed as well.
So even in cases where we've specified that the fragment
shouldn't be destroyed, its view still would be or will be.
In that case on create view will be called again
when the fragment gets reattached to the
new activity instance.
If the fragments been set to not be destroyed when its'
activity is, then the on destroy function
won't be called.
Assuming we're dealing with a normal fragment on destroy
will be called when the activity is destroyed.
And finally on detach is called when the fragment is
detached from the activity.
After this point its an error to attempt to refer to the
fragment's activity, it no longer has one.
If your storing a reference to the activity, as a call
back lister for example, then you should set your
reference to null in hand.
We saw that being done in the code that Android studio
generated for add edit fragment.
Well that was showing these functions as they fit into
the Android lifecycle.
A fragment can be detached from its activity
for other reasons.
The most obvious is when we remove the edited fragment,
when the user finishes editing.
Bare in mind that it's possible for the fragment
to be destroyed, even when the activity isn't being.
Alright so that completes the basic fragment lifecycle.
We've gone through the lifecycle from when the activity
is created to when it gets destroyed.
As we discussed, things can be a bit different if the
user switches away from our app, then switches back again.
In that case the lifecycle may not run
through all these events.
You might get on resume called after on pause when the
user switches back.
The diagram on GitHub that I showed you the last video,
that I'm gonna show again now shows these variations.
If another activity takes over the foreground,
but doesn't cause our activity to stop.
This diagram reflects that in the arrows going from
on pause, I'll just show that on the screen, to on resume,
for both the activity and the fragment.
You can also get on stop followed by on start,
if the user switches away from our app and then
switches back again.
They could tap the home button for example,
then go back to your app from the launcher.
When that happens the activity also gets on restart
called before on start.
But take a good look at this diagram because it is
really useful to get a good understanding
about how things work with Android.
But baring in mind it's now a little bit old.
Alright, so let's move onto the next video now,
we're gonna go back to doing some coding.
And we'll add some logging to our fragment and
see all this working.
See you in the next video.