1 00:00:04,600 --> 00:00:08,100 Welcome back again. At the end of the previous video, 2 00:00:08,100 --> 00:00:10,900 I mentioned that there's a small bug in our app. 3 00:00:11,400 --> 00:00:14,200 It's very likely that most users won't notice it, 4 00:00:14,700 --> 00:00:18,360 but we should still fix it, especially as the fix is very easy. 5 00:00:19,160 --> 00:00:22,660 Fixing it is also a great way to demonstrate how to use a 6 00:00:22,660 --> 00:00:24,860 BroadcastReceiver in your apps. 7 00:00:25,520 --> 00:00:27,020 We get to fix the bug 8 00:00:27,270 --> 00:00:31,070 and learn about a new Android Framework class at the same time. 9 00:00:31,770 --> 00:00:35,370 I mentioned that you should test the app thoroughly in earlier videos, 10 00:00:35,670 --> 00:00:37,970 so you may have found the bug already. 11 00:00:38,570 --> 00:00:42,370 I'll spend a couple of minutes demonstrating it before we try to fix it. 12 00:00:44,370 --> 00:00:48,170 I've got my emulator set to the English Australia locale, 13 00:00:48,820 --> 00:00:51,020 and I'll also take this opportunity 14 00:00:51,020 --> 00:00:53,620 to warn you about a potential problem you can get 15 00:00:54,120 --> 00:00:56,920 if you go messing about with the time on your device 16 00:00:57,280 --> 00:00:58,380 or emulators. 17 00:00:59,180 --> 00:01:03,580 I set the time on the emulator to 8 am a few videos ago, 18 00:01:03,940 --> 00:01:05,940 and its clock is now wrong. 19 00:01:06,240 --> 00:01:10,340 Of course, if you did that at 8 am, then you won't have the problem. 20 00:01:12,540 --> 00:01:14,740 I'm not going to do this. You can try it yourself. 21 00:01:15,040 --> 00:01:18,340 But if I tried to run the FlickrBrowser app now, 22 00:01:18,590 --> 00:01:19,890 it wouldn't work. 23 00:01:20,540 --> 00:01:23,440 In fact, you'll have problems with any app 24 00:01:23,800 --> 00:01:27,600 that tries to access the internet using https 25 00:01:27,600 --> 00:01:29,600 or any secure connection type. 26 00:01:30,300 --> 00:01:34,660 The correct time plays an important role in session validation, 27 00:01:35,160 --> 00:01:38,760 and changing the time can cause havoc with security 28 00:01:38,760 --> 00:01:40,560 and certificate validation. 29 00:01:41,160 --> 00:01:42,860 That's not relevant for this app. 30 00:01:43,260 --> 00:01:46,460 But as I've suggested you change your device's time, 31 00:01:46,960 --> 00:01:48,960 I should mention this problem you'll get 32 00:01:49,360 --> 00:01:52,060 if you don't put the time right again afterwards. 33 00:01:56,860 --> 00:01:58,420 I'm going to go into settings 34 00:02:05,220 --> 00:02:06,720 and in system 35 00:02:08,720 --> 00:02:09,720 date and time, 36 00:02:10,820 --> 00:02:14,120 make sure automatic date and time is on. 37 00:02:14,920 --> 00:02:16,520 All right. On with the bug. 38 00:02:17,180 --> 00:02:19,480 I'll run the task timer app again 39 00:02:23,480 --> 00:02:24,980 and go into the reports. 40 00:02:27,540 --> 00:02:31,140 I'll filter on the 10th of June 2019 41 00:02:37,500 --> 00:02:41,100 because I deleted a lot of records before the 15th of May. 42 00:02:41,650 --> 00:02:44,640 Notice that my week is starting on Sunday the 9th of June. 43 00:02:45,190 --> 00:02:48,850 I should get rows from the 9th to the 15th of June. 44 00:02:49,730 --> 00:02:52,090 It's important to have at least one row 45 00:02:52,090 --> 00:02:54,390 for the first and last days for the week. 46 00:02:54,940 --> 00:02:59,040 If you haven't, go back to the main screen and generate more data. 47 00:03:04,140 --> 00:03:06,500 Okay. The report looks good, 48 00:03:06,500 --> 00:03:09,100 and the dates are showing in the Australian format. 49 00:03:10,090 --> 00:03:14,290 I'll switch to the settings and change the language to English United Kingdom. 50 00:03:33,750 --> 00:03:38,250 When I switch back to the app, the dates are now formatted in the UK style 51 00:03:38,550 --> 00:03:40,150 with 4 digits for the year. 52 00:03:40,750 --> 00:03:41,950 That's worked fine. 53 00:03:42,450 --> 00:03:46,450 The problem is I can still see records for the 9th of June. 54 00:03:46,700 --> 00:03:50,060 In the UK, the week should start on Monday, 55 00:03:50,420 --> 00:03:53,020 which is the 10th of June in 2019. 56 00:03:53,570 --> 00:03:55,070 The calendar knows that 57 00:03:55,430 --> 00:03:58,430 we can see that when i tap the icon to select a new date. 58 00:03:59,230 --> 00:04:03,460 I'll tap okay without changing the date from the 10th of June 59 00:04:05,760 --> 00:04:08,060 and we've still got records for the 9th. 60 00:04:09,260 --> 00:04:11,160 It's a very minor bug perhaps 61 00:04:11,520 --> 00:04:15,120 but it does demonstrate the level of testing you need to perform 62 00:04:15,420 --> 00:04:18,220 when you're dealing with dates in different time zones. 63 00:04:18,880 --> 00:04:22,480 Okay what's causing it, and how do we fix it? 64 00:04:23,280 --> 00:04:26,080 Well, the date formatting has changed, 65 00:04:26,480 --> 00:04:30,380 that's because the activity got destroyed and recreated 66 00:04:30,380 --> 00:04:32,380 after the configuration change. 67 00:04:32,630 --> 00:04:36,630 That means its context is now aware of the new formatting rules. 68 00:04:37,290 --> 00:04:40,390 But our ViewModel class, DurationsViewModel 69 00:04:40,390 --> 00:04:42,590 survives a configuration change. 70 00:04:43,250 --> 00:04:46,550 It's still using the same calendar object that it created 71 00:04:46,550 --> 00:04:48,550 when the week started on a Sunday. 72 00:04:49,550 --> 00:04:53,350 To fix that, we need to react to a change in locale 73 00:04:53,650 --> 00:04:56,450 and create a new Gregorian calendar instance, 74 00:04:56,950 --> 00:05:01,250 and we're going to see how to do that in the next video. I'll see you there.