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.