1 00:00:03,980 --> 00:00:09,180 G'day everyone, welcome back. There's one last thing I want to look at before we finish this 2 00:00:09,190 --> 00:00:14,110 section. To see what it is, I'll get Android Studio to generate an 3 00:00:14,110 --> 00:00:28,210 on destroy stub, at the end of the SettingsDialog. I'll add some logging to 4 00:00:28,210 --> 00:00:33,040 let us see it's being called, when our dialog's destroyed. Okay. 5 00:00:33,040 --> 00:00:38,880 I'll run the app and filter the logcat on SettingsDialog 6 00:00:53,080 --> 00:01:03,020 When I open the settings, we can see it being created in the logcat. 7 00:01:03,020 --> 00:01:08,480 I'll add the comment rotating to the logcat, to make it easier to see when things happen. 8 00:01:08,500 --> 00:01:19,040 Then I'll rotate the device. There's no surprises there, if you've studied the 9 00:01:19,040 --> 00:01:23,580 fragment life cycle. AddDialog is a DialogFragment, and it has the same life 10 00:01:23,580 --> 00:01:30,280 cycle as other fragments. We can see it being destroyed, then recreated. 11 00:01:30,280 --> 00:01:34,259 That's not a huge problem. Android recreates it and attaches it to 12 00:01:34,259 --> 00:01:39,149 the activity again, but it can be inefficient. It's possible to prevent a 13 00:01:39,149 --> 00:01:44,310 fragment being destroyed like this. It's not something you should do often, but a 14 00:01:44,310 --> 00:01:49,350 retained fragment can be useful sometimes. Generally, you'll probably use 15 00:01:49,350 --> 00:01:54,420 a view model to retain state, as we've seen. But if you're not using a view 16 00:01:54,420 --> 00:01:58,680 model for some reason, and your fragment contains data that's expensive to fetch 17 00:01:58,680 --> 00:02:03,720 again, then you can set it to retain its state, and not be destroyed when its 18 00:02:03,720 --> 00:02:12,640 activity is. To do that, we just set retain instance to true, in onCreate. 19 00:02:26,460 --> 00:02:35,320 I'll repeat the previous test. Run the app, and go into settings. There's our 20 00:02:35,330 --> 00:02:41,680 dialog being created. I'll add the comment rotating to the logcat again, 21 00:02:44,620 --> 00:02:55,010 then rotate the device. This time, onDestroy doesn't get called. The Dialog 22 00:02:55,010 --> 00:03:00,320 Fragment isn't destroyed. We also don't get the onCreate logged, because the 23 00:03:00,320 --> 00:03:06,290 DialogFragment isn't recreated. Its view still has to be created, of course, and if 24 00:03:06,290 --> 00:03:11,240 you're not sure why, then watch the videos on the fragment lifecycle again. 25 00:03:11,240 --> 00:03:16,160 Alright, we've saved a bit of processing there, and the destroyed fragment no 26 00:03:16,160 --> 00:03:20,330 longer has to be garbage collected. So this is a small improvement in 27 00:03:20,330 --> 00:03:28,120 efficiency. It has another use here. It makes it easier to fix a bug in our code. 28 00:03:28,120 --> 00:03:33,620 To see the bug, watch what happens when I start to change the day and time. 29 00:03:33,620 --> 00:03:48,300 I'll set them to Sunday and zero, to make it easier to spot, 30 00:03:48,360 --> 00:03:54,030 then I'm gonna tap OK to save the changes. Well now you're back into 31 00:03:54,030 --> 00:03:57,960 settings, we've got Sunday as the first day, with zero as the number of seconds 32 00:03:57,960 --> 00:04:02,750 to ignore. I'll change them to Monday, 33 00:04:03,220 --> 00:04:08,100 and drag the slider to the middle. When I rotate the device, 34 00:04:08,100 --> 00:04:17,480 we've lost our values. They've gone back to Sunday and zero. We could implement 35 00:04:17,488 --> 00:04:23,250 the OnSavedInstanceState and onRestore InstanceState functions to fix that, but 36 00:04:23,250 --> 00:04:27,960 because our Dialogfragment isn't being destroyed, it's much easier to just avoid 37 00:04:27,960 --> 00:04:38,480 setting the values when the device is rotated. Looking at onViewStateRestored, 38 00:04:38,480 --> 00:04:42,660 we know that savedInstanceState will be null when the dialog's 39 00:04:42,660 --> 00:04:48,160 first created. We can test that, and only change a spinner and the SeekBar 40 00:04:48,160 --> 00:04:51,800 if the savedInstance is null. 41 00:05:15,300 --> 00:05:20,300 Now, we read the values and set the widget when our dialog's first created, 42 00:05:20,300 --> 00:05:29,880 but don't do that again when the device is rotated. I'll repeat the test. 43 00:05:29,880 --> 00:05:36,600 Run the app again, go into settings and we've got Sunday and 0 as the values. Once again, 44 00:05:36,600 --> 00:05:41,250 I'll change them to Monday and somewhere in the middle. Now when I rotate the 45 00:05:41,250 --> 00:05:45,300 device, the DialogFragment's retained its state, and everything's 46 00:05:45,300 --> 00:05:49,780 where it should be. We've checked in onViewStateRestored, 47 00:05:49,780 --> 00:05:54,300 and don't reset the widgets to the saved values again. They keep the values they 48 00:05:54,300 --> 00:05:59,430 had, before the device was rotated. Alright, that's the end of our Settings 49 00:05:59,430 --> 00:06:05,130 Dialog, and of this section. We're not using the settings yet, but it makes 50 00:06:05,130 --> 00:06:09,990 sense to allow them to be changed, before we write the code that uses them. In the 51 00:06:09,990 --> 00:06:15,240 next section, we'll create the timings table and get the app to time the tasks. 52 00:06:15,240 --> 00:06:19,420 I'm looking forward to seeing you then.