1 00:00:04,400 --> 00:00:08,200 Welcome back. It's time to see if our changes have fixed that bug 2 00:00:08,200 --> 00:00:09,780 when the locale has changed. 3 00:00:10,680 --> 00:00:12,680 I'll repeat the same test as before, 4 00:00:13,040 --> 00:00:16,640 which means I'll start by dragging English Australia 5 00:00:16,640 --> 00:00:18,140 to the top of the languages. 6 00:00:33,640 --> 00:00:36,640 Next, I'll run the app and go into reports. 7 00:00:41,140 --> 00:00:44,640 We'll set the date to the 10th of June, like last time. 8 00:00:53,540 --> 00:00:56,040 Notice that the week is starting on a Sunday, 9 00:00:56,400 --> 00:01:00,060 and we'll get data from the 9th to the 15th of June. 10 00:01:03,660 --> 00:01:07,320 Sorting by date will make it easier to check the results. 11 00:01:07,320 --> 00:01:09,920 Okay. That is working as expected. 12 00:01:09,920 --> 00:01:13,910 Now I'll switch the settings and change the language to English 13 00:01:13,910 --> 00:01:14,900 United Kingdom. 14 00:01:34,500 --> 00:01:36,000 When I switch back to the app, 15 00:01:36,200 --> 00:01:40,900 the date format changes and we've now got records from the 10th 16 00:01:40,900 --> 00:01:42,400 to the 16th of June, 17 00:01:42,900 --> 00:01:44,600 that's just what we'd expect 18 00:01:44,600 --> 00:01:47,700 because the week starts on a Monday in our new locale. 19 00:01:48,500 --> 00:01:49,800 In the logcat, 20 00:01:53,800 --> 00:01:56,600 we can see the database being re-queried 21 00:01:56,600 --> 00:01:59,600 as the view model responsive locale changed. 22 00:02:02,100 --> 00:02:06,500 Our broadcast receiver works and we fix the small bug. 23 00:02:08,000 --> 00:02:10,600 Listen to all the feedback we get from students. 24 00:02:11,400 --> 00:02:15,160 And in the last few sections, we've made the video shorter as a result, 25 00:02:15,820 --> 00:02:17,420 but this one's a bit too short. 26 00:02:17,780 --> 00:02:20,780 So I'm going to take a few minutes to show you something weird. 27 00:02:21,780 --> 00:02:26,380 You'll have come across an indication of this in the BroadcastReceiver documentation, 28 00:02:27,040 --> 00:02:30,540 but the documentation only talks about it when referring 29 00:02:30,540 --> 00:02:32,040 to manifest receivers, 30 00:02:32,640 --> 00:02:36,240 BroadcastReceivers that you receive in the app's manifest. 31 00:02:37,040 --> 00:02:41,500 We're using a ContentReceiver but the same thing still applies. 32 00:02:42,490 --> 00:02:46,290 If you register a BroadcastReceiver in the app's manifest, 33 00:02:46,290 --> 00:02:49,890 your app will be launched when an action you're monitoring happens. 34 00:02:50,490 --> 00:02:51,690 That can be useful. 35 00:02:52,050 --> 00:02:54,250 A security app for example 36 00:02:54,550 --> 00:02:57,150 could be launched when a user unlocks their phone. 37 00:02:58,450 --> 00:03:00,850 The short video in the documentation 38 00:03:00,850 --> 00:03:03,210 talks about the performance penalties, 39 00:03:03,210 --> 00:03:07,570 and how too many receivers can really impact the performance 40 00:03:07,570 --> 00:03:09,070 of the entire device. 41 00:03:09,870 --> 00:03:13,470 Make sure you watch that video and read the documentation 42 00:03:13,470 --> 00:03:16,770 if you're going to use BroadcastReceivers in your app. 43 00:03:18,270 --> 00:03:22,070 ManifestReceivers are registered system-wide, 44 00:03:22,430 --> 00:03:26,330 and they don't get unregistered unless you uninstall the app of course. 45 00:03:27,630 --> 00:03:29,930 Okay. What will happen 46 00:03:29,930 --> 00:03:32,930 if we fail to unregister our BroadcastReceiver? 47 00:03:33,930 --> 00:03:38,130 We can test that by commenting out the line that unregisters it 48 00:03:38,130 --> 00:03:40,030 in the uncleared function. 49 00:03:50,830 --> 00:03:54,430 This short test will show how BroadcastReceivers work 50 00:03:54,830 --> 00:03:59,730 and will also demonstrate why it's important to unregister observers and receivers. 51 00:04:00,720 --> 00:04:04,720 Let's see what happens. I run the app and go to the reports. 52 00:04:11,720 --> 00:04:15,820 We can see our DurationsViewModel being created in the logcat. 53 00:04:16,480 --> 00:04:19,839 I'll filter on durations to make it easier to see though. 54 00:04:24,640 --> 00:04:27,640 That lets us see the query being executed as well. 55 00:04:28,140 --> 00:04:31,500 Okay. I'll use the up button to go back to main activity. 56 00:04:35,300 --> 00:04:38,500 We get the ViewModels OnCleared function called 57 00:04:39,000 --> 00:04:42,900 and our DurationsViewModel instance should now be destroyed. 58 00:04:44,200 --> 00:04:47,200 What's going to happen if I switch to the settings 59 00:04:47,200 --> 00:04:49,000 and change the language again? 60 00:04:49,500 --> 00:04:53,300 Remember, we haven't unregistered our BroadcastReceiver. 61 00:04:54,290 --> 00:04:58,090 Let's see, keep an eye on the logcat as we do this. 62 00:04:58,590 --> 00:05:02,090 In the settings, I'll change back to English Australia. 63 00:05:16,390 --> 00:05:19,990 In the logcat, we can see the BroadcastReceivers 64 00:05:19,990 --> 00:05:21,990 OnReceive function being called. 65 00:05:22,790 --> 00:05:26,150 Then the database is queried to get the reports data. 66 00:05:27,150 --> 00:05:29,150 We're not showing the reports, 67 00:05:29,650 --> 00:05:32,050 as you can see if I switch back to the app. 68 00:05:36,950 --> 00:05:38,750 We're still on the main screen. 69 00:05:39,740 --> 00:05:43,540 We've wasted battery life and resources retrieving data 70 00:05:43,540 --> 00:05:47,140 that we've got no use for. It's worse than that 71 00:05:47,740 --> 00:05:51,100 because our ViewModel didn't unregister its receiver, 72 00:05:51,100 --> 00:05:53,400 it couldn't be destroyed by the system. 73 00:05:54,060 --> 00:05:56,060 Our app had no further use for it, 74 00:05:56,360 --> 00:05:59,020 but it's still registered as a receiver 75 00:05:59,020 --> 00:06:00,920 and the instance remains in memory. 76 00:06:01,470 --> 00:06:03,460 I'll go back into the reports. 77 00:06:07,060 --> 00:06:10,660 And there's another instance of the DurationsViewModel class 78 00:06:10,660 --> 00:06:14,460 being created and querying the database. 79 00:06:15,360 --> 00:06:16,660 I'll clear the logcat 80 00:06:20,660 --> 00:06:23,660 then switch to settings and change the language again. 81 00:06:36,060 --> 00:06:38,360 Watch the logcat as I do this 82 00:06:38,360 --> 00:06:41,030 because you may not expect what's about to happen. 83 00:06:45,530 --> 00:06:48,530 The BroadcastReceiver's onReceive function 84 00:06:48,530 --> 00:06:50,130 gets called twice. 85 00:06:57,930 --> 00:07:01,590 Once for each instance of the receiver that's been registered. 86 00:07:02,580 --> 00:07:04,680 Each time I go into reports 87 00:07:04,680 --> 00:07:07,880 a new DurationsViewModel instance gets created 88 00:07:07,880 --> 00:07:10,570 and registers another copy of the BroadcastReceiver. 89 00:07:12,170 --> 00:07:16,530 We're starting to eat up ram with new DurationsViewModel instances. 90 00:07:17,030 --> 00:07:20,430 We're also performing more and more queries on the database 91 00:07:20,430 --> 00:07:22,730 to get back data that we have no use for. 92 00:07:23,530 --> 00:07:25,530 That's what's meant by leaking memory. 93 00:07:26,080 --> 00:07:28,380 And this is a really good way to do it. 94 00:07:28,930 --> 00:07:31,730 If you want to give your users a really bad experience 95 00:07:31,730 --> 00:07:35,930 and make their phones perform badly, then this is one way to do that. 96 00:07:36,430 --> 00:07:37,230 Please don't. 97 00:07:38,030 --> 00:07:41,830 Always unregister your BroadcastReceivers and observers 98 00:07:41,830 --> 00:07:44,430 and clean up any other resources that you create. 99 00:07:45,330 --> 00:07:48,530 Okay. I better uncomment that line 100 00:07:48,530 --> 00:07:50,130 before finishing the video. 101 00:07:55,130 --> 00:07:58,630 In the next few videos, we'll finish off this section 102 00:07:58,630 --> 00:08:02,730 by using the settings in our reports. I'll see you then.