1
00:00:00,069 --> 00:00:02,451
(upbeat music)

2
00:00:02,451 --> 00:00:05,230
(keyboard typing)

3
00:00:05,230 --> 00:00:08,109
In the previous video, we saw the lifecycle functions

4
00:00:08,109 --> 00:00:11,760
that I called as a fragment is attached to it's activity.

5
00:00:11,760 --> 00:00:14,330
We use the main activity fragment as the example

6
00:00:14,330 --> 00:00:16,880
and showed the events that happen with an activity

7
00:00:16,880 --> 00:00:18,900
that has a fragment in its layout.

8
00:00:18,900 --> 00:00:21,650
Having a fragment in code is slightly different because

9
00:00:21,650 --> 00:00:24,170
the activity will already have been started.

10
00:00:24,170 --> 00:00:26,940
However, if you've added a fragment in code as we

11
00:00:26,940 --> 00:00:28,870
do with the add edit fragment,

12
00:00:28,870 --> 00:00:31,760
then the fragment is automatically reattached when the

13
00:00:31,760 --> 00:00:33,750
activity gets recreated.

14
00:00:33,750 --> 00:00:36,470
In that case, add edit fragment will follow exactly the

15
00:00:36,470 --> 00:00:39,117
same lifecycle as the main activity fragment.

16
00:00:39,117 --> 00:00:41,720
And its lifecycle will be tied to the

17
00:00:41,720 --> 00:00:44,060
activity creation events.

18
00:00:44,060 --> 00:00:46,410
So next we'll look at the lifecycle where the fragments

19
00:00:46,410 --> 00:00:48,600
were moved from the activity.

20
00:00:48,600 --> 00:00:51,100
This is the same whether the fragments in the layout

21
00:00:51,100 --> 00:00:53,060
or was added in code.

22
00:00:53,060 --> 00:00:55,570
Whichever method was used to attach the fragment to its

23
00:00:55,570 --> 00:00:58,010
activity, its now attached.

24
00:00:58,010 --> 00:01:01,513
And it will be detached if the activity gets destroyed.

25
00:01:02,743 --> 00:01:05,300
Alright, so with this first slide, when our activity

26
00:01:05,300 --> 00:01:09,040
leaves the resumed state, Android calls the functions shown

27
00:01:09,040 --> 00:01:10,300
on the left.

28
00:01:10,300 --> 00:01:11,860
We've only seen all this when we looked

29
00:01:11,860 --> 00:01:13,600
at the activity lifecycle.

30
00:01:13,600 --> 00:01:16,500
A number of events can cause the activity to leave

31
00:01:16,500 --> 00:01:18,010
the resumed state.

32
00:01:18,010 --> 00:01:20,378
We tend to focus on things like device rotation,

33
00:01:20,378 --> 00:01:23,990
because Android will be recreating the activity for us.

34
00:01:23,990 --> 00:01:28,140
Generally, that's the behaviour that causes us the most work.

35
00:01:28,140 --> 00:01:30,177
Related to that are events such as the user switching

36
00:01:30,177 --> 00:01:33,280
to another task, answering the phone for example.

37
00:01:33,280 --> 00:01:35,757
Other things such as the user tapping the back button,

38
00:01:35,757 --> 00:01:40,130
will also cause our activity to leave the running state.

39
00:01:40,130 --> 00:01:43,510
In those cases we're less concerned because we don't have

40
00:01:43,510 --> 00:01:47,099
to write code to cope with the activity being recreated.

41
00:01:47,099 --> 00:01:50,280
When the activity goes through the stages of stopping,

42
00:01:50,280 --> 00:01:54,690
our fragment also gets similar lifecycle events.

43
00:01:54,690 --> 00:01:58,270
The first call back our fragment gets is on pause.

44
00:01:58,270 --> 00:02:00,760
This doesn't mean that the fragment will be destroyed.

45
00:02:00,760 --> 00:02:03,877
If the user has switched to another task, then the activity

46
00:02:03,877 --> 00:02:08,070
and its fragments will remain in the paused state until

47
00:02:08,070 --> 00:02:09,960
the user switches back to it.

48
00:02:09,960 --> 00:02:11,810
Of course there's no guarantee that they will switch

49
00:02:11,810 --> 00:02:13,866
back to the activity, and Android may well

50
00:02:13,866 --> 00:02:16,300
destroy that task.

51
00:02:16,300 --> 00:02:19,346
But bare in mind that on pause might be the last function

52
00:02:19,346 --> 00:02:20,680
that gets called.

53
00:02:20,680 --> 00:02:23,870
That fragment may be activated again and will get

54
00:02:23,870 --> 00:02:25,210
on resume called.

55
00:02:25,210 --> 00:02:28,220
On pause is a good place to save any data that the

56
00:02:28,220 --> 00:02:30,290
user will expect to keep.

57
00:02:30,290 --> 00:02:33,130
We've added a save button to the edited fragment,

58
00:02:33,130 --> 00:02:35,900
but you should consider whether that's really an appropriate

59
00:02:35,900 --> 00:02:37,970
thing to have in our UI.

60
00:02:37,970 --> 00:02:40,400
When we've added the code to save the data,

61
00:02:40,400 --> 00:02:43,250
you might wanna consider moving it to on pause.

62
00:02:43,250 --> 00:02:45,930
The data will then be saved automatically when the

63
00:02:45,930 --> 00:02:48,460
user leaves the fragment for any reason.

64
00:02:48,460 --> 00:02:51,280
That would fit in better with expected Android behaviour.

65
00:02:51,280 --> 00:02:52,900
But then we wouldn't have been able to show you the

66
00:02:52,900 --> 00:02:55,313
button communicating with the activity.

67
00:02:56,180 --> 00:02:58,808
On this slide, we're showing on save instance state here.

68
00:02:58,808 --> 00:03:03,150
But it can be called any time before on destroy.

69
00:03:03,150 --> 00:03:06,216
It won't be called before on pause but could be called

70
00:03:06,216 --> 00:03:09,270
after on stop or on destroy view.

71
00:03:09,270 --> 00:03:12,660
Any data you add to the bundle will be available in

72
00:03:12,660 --> 00:03:16,370
all the fragment functions that receive a bundle.

73
00:03:16,370 --> 00:03:19,440
Unlike the activity a fragment doesn't have an on restore

74
00:03:19,440 --> 00:03:21,150
instant state function.

75
00:03:21,150 --> 00:03:23,210
But there are plenty of other places that you can

76
00:03:23,210 --> 00:03:25,270
retrieve the bundle.

77
00:03:25,270 --> 00:03:28,110
Just remember that a fragment doesn't have a function that's

78
00:03:28,110 --> 00:03:31,640
guaranteed to receive a non null bundle.

79
00:03:31,640 --> 00:03:34,363
Always allow for the bundle being null in your code.

80
00:03:35,240 --> 00:03:36,840
When on stop gets called,

81
00:03:36,840 --> 00:03:39,390
the fragments in the stopped state.

82
00:03:39,390 --> 00:03:42,890
It's no longer visible but hasn't been destroyed.

83
00:03:42,890 --> 00:03:45,890
From here, the fragment may be resumed.

84
00:03:45,890 --> 00:03:49,260
In which case, on resume will be the next function called.

85
00:03:49,260 --> 00:03:52,880
If that happens the fragment still has all its state.

86
00:03:52,880 --> 00:03:55,753
As a result it doesn't matter that on save instant state

87
00:03:55,753 --> 00:03:57,840
may not have been called yet.

88
00:03:57,840 --> 00:04:00,170
If the user does switch back to the fragment,

89
00:04:00,170 --> 00:04:02,880
no state has been lost and everything will work fine.

90
00:04:02,880 --> 00:04:04,964
We've seen that on stop may not get called,

91
00:04:04,964 --> 00:04:07,900
if the user switches back to your activity.

92
00:04:07,900 --> 00:04:11,070
That means you might prefer to save user data here,

93
00:04:11,070 --> 00:04:15,010
in on stop rather than in on pause.

94
00:04:15,010 --> 00:04:17,540
That would prevent saving the data in cases where

95
00:04:17,540 --> 00:04:20,040
the user is gonna come back to the fragment.

96
00:04:20,040 --> 00:04:22,700
The Google examples and comments on the internet,

97
00:04:22,700 --> 00:04:24,850
all say that on pause is the best place

98
00:04:24,850 --> 00:04:26,950
to persist user data.

99
00:04:26,950 --> 00:04:28,991
But there's no reason why you couldn't defer doing so,

100
00:04:28,991 --> 00:04:30,720
until on stop.

101
00:04:30,720 --> 00:04:33,380
Whatever you choose bare in mind that you shouldn't perform

102
00:04:33,380 --> 00:04:36,423
intensive operations on the foreground thread.

103
00:04:37,700 --> 00:04:40,380
If the activity is being destroyed the fragment will

104
00:04:40,380 --> 00:04:43,200
get its on destroy view function called.

105
00:04:43,200 --> 00:04:45,590
So this is the function where the documentation for on

106
00:04:45,590 --> 00:04:48,210
create view was a bit ambiguous.

107
00:04:48,210 --> 00:04:51,430
On destroy view will be called even if the fragment

108
00:04:51,430 --> 00:04:55,160
doesn't return a view from its on create view function.

109
00:04:55,160 --> 00:04:57,960
Note that on destroy view will be called even if the

110
00:04:57,960 --> 00:04:59,800
fragment isn't being destroyed.

111
00:04:59,800 --> 00:05:02,620
As I mentioned if the activity is being destroyed

112
00:05:02,620 --> 00:05:05,330
then the activities layout is also destroyed.

113
00:05:05,330 --> 00:05:07,640
Because the fragment's view appears in the activity's

114
00:05:07,640 --> 00:05:11,230
layout, the fragment's view has to be destroyed as well.

115
00:05:11,230 --> 00:05:13,750
So even in cases where we've specified that the fragment

116
00:05:13,750 --> 00:05:17,520
shouldn't be destroyed, its view still would be or will be.

117
00:05:17,520 --> 00:05:20,850
In that case on create view will be called again

118
00:05:20,850 --> 00:05:22,580
when the fragment gets reattached to the

119
00:05:22,580 --> 00:05:24,423
new activity instance.

120
00:05:24,423 --> 00:05:28,470
If the fragments been set to not be destroyed when its'

121
00:05:28,470 --> 00:05:30,960
activity is, then the on destroy function

122
00:05:30,960 --> 00:05:32,410
won't be called.

123
00:05:32,410 --> 00:05:35,040
Assuming we're dealing with a normal fragment on destroy

124
00:05:35,040 --> 00:05:37,493
will be called when the activity is destroyed.

125
00:05:38,800 --> 00:05:41,290
And finally on detach is called when the fragment is

126
00:05:41,290 --> 00:05:42,940
detached from the activity.

127
00:05:42,940 --> 00:05:45,503
After this point its an error to attempt to refer to the

128
00:05:45,503 --> 00:05:48,900
fragment's activity, it no longer has one.

129
00:05:48,900 --> 00:05:51,640
If your storing a reference to the activity, as a call

130
00:05:51,640 --> 00:05:53,930
back lister for example, then you should set your

131
00:05:53,930 --> 00:05:55,820
reference to null in hand.

132
00:05:55,820 --> 00:05:58,420
We saw that being done in the code that Android studio

133
00:05:58,420 --> 00:06:01,010
generated for add edit fragment.

134
00:06:01,010 --> 00:06:02,920
Well that was showing these functions as they fit into

135
00:06:02,920 --> 00:06:04,400
the Android lifecycle.

136
00:06:04,400 --> 00:06:07,040
A fragment can be detached from its activity

137
00:06:07,040 --> 00:06:08,510
for other reasons.

138
00:06:08,510 --> 00:06:10,939
The most obvious is when we remove the edited fragment,

139
00:06:10,939 --> 00:06:13,500
when the user finishes editing.

140
00:06:13,500 --> 00:06:15,188
Bare in mind that it's possible for the fragment

141
00:06:15,188 --> 00:06:18,913
to be destroyed, even when the activity isn't being.

142
00:06:19,890 --> 00:06:23,159
Alright so that completes the basic fragment lifecycle.

143
00:06:23,159 --> 00:06:25,790
We've gone through the lifecycle from when the activity

144
00:06:25,790 --> 00:06:28,870
is created to when it gets destroyed.

145
00:06:28,870 --> 00:06:31,640
As we discussed, things can be a bit different if the

146
00:06:31,640 --> 00:06:35,140
user switches away from our app, then switches back again.

147
00:06:35,140 --> 00:06:37,170
In that case the lifecycle may not run

148
00:06:37,170 --> 00:06:38,560
through all these events.

149
00:06:38,560 --> 00:06:41,280
You might get on resume called after on pause when the

150
00:06:41,280 --> 00:06:43,100
user switches back.

151
00:06:43,100 --> 00:06:45,440
The diagram on GitHub that I showed you the last video,

152
00:06:45,440 --> 00:06:48,920
that I'm gonna show again now shows these variations.

153
00:06:48,920 --> 00:06:51,780
If another activity takes over the foreground,

154
00:06:51,780 --> 00:06:54,730
but doesn't cause our activity to stop.

155
00:06:54,730 --> 00:06:56,850
This diagram reflects that in the arrows going from

156
00:06:56,850 --> 00:07:01,550
on pause, I'll just show that on the screen, to on resume,

157
00:07:01,550 --> 00:07:04,120
for both the activity and the fragment.

158
00:07:04,120 --> 00:07:07,830
You can also get on stop followed by on start,

159
00:07:07,830 --> 00:07:09,870
if the user switches away from our app and then

160
00:07:09,870 --> 00:07:11,110
switches back again.

161
00:07:11,110 --> 00:07:12,889
They could tap the home button for example,

162
00:07:12,889 --> 00:07:15,310
then go back to your app from the launcher.

163
00:07:15,310 --> 00:07:17,780
When that happens the activity also gets on restart

164
00:07:17,780 --> 00:07:19,890
called before on start.

165
00:07:19,890 --> 00:07:21,850
But take a good look at this diagram because it is

166
00:07:21,850 --> 00:07:24,379
really useful to get a good understanding

167
00:07:24,379 --> 00:07:26,210
about how things work with Android.

168
00:07:26,210 --> 00:07:28,530
But baring in mind it's now a little bit old.

169
00:07:28,530 --> 00:07:30,660
Alright, so let's move onto the next video now,

170
00:07:30,660 --> 00:07:32,280
we're gonna go back to doing some coding.

171
00:07:32,280 --> 00:07:34,380
And we'll add some logging to our fragment and

172
00:07:34,380 --> 00:07:35,680
see all this working.

173
00:07:35,680 --> 00:07:36,980
See you in the next video.