Welcome back again. At the end of the previous video,
I mentioned that there's a small bug in our app.
It's very likely that most users won't notice it,
but we should still fix it, especially as the fix is very easy.
Fixing it is also a great way to demonstrate how to use a
BroadcastReceiver in your apps.
We get to fix the bug
and learn about a new Android Framework class at the same time.
I mentioned that you should test the app thoroughly in earlier videos,
so you may have found the bug already.
I'll spend a couple of minutes demonstrating it before we try to fix it.
I've got my emulator set to the English Australia locale,
and I'll also take this opportunity
to warn you about a potential problem you can get
if you go messing about with the time on your device
or emulators.
I set the time on the emulator to 8 am a few videos ago,
and its clock is now wrong.
Of course, if you did that at 8 am, then you won't have the problem.
I'm not going to do this. You can try it yourself.
But if I tried to run the FlickrBrowser app now,
it wouldn't work.
In fact, you'll have problems with any app
that tries to access the internet using https
or any secure connection type.
The correct time plays an important role in session validation,
and changing the time can cause havoc with security
and certificate validation.
That's not relevant for this app.
But as I've suggested you change your device's time,
I should mention this problem you'll get
if you don't put the time right again afterwards.
I'm going to go into settings
and in system
date and time,
make sure automatic date and time is on.
All right. On with the bug.
I'll run the task timer app again
and go into the reports.
I'll filter on the 10th of June 2019
because I deleted a lot of records before the 15th of May.
Notice that my week is starting on Sunday the 9th of June.
I should get rows from the 9th to the 15th of June.
It's important to have at least one row
for the first and last days for the week.
If you haven't, go back to the main screen and generate more data.
Okay. The report looks good,
and the dates are showing in the Australian format.
I'll switch to the settings and change the language to English United Kingdom.
When I switch back to the app, the dates are now formatted in the UK style
with 4 digits for the year.
That's worked fine.
The problem is I can still see records for the 9th of June.
In the UK, the week should start on Monday,
which is the 10th of June in 2019.
The calendar knows that
we can see that when i tap the icon to select a new date.
I'll tap okay without changing the date from the 10th of June
and we've still got records for the 9th.
It's a very minor bug perhaps
but it does demonstrate the level of testing you need to perform
when you're dealing with dates in different time zones.
Okay what's causing it, and how do we fix it?
Well, the date formatting has changed,
that's because the activity got destroyed and recreated
after the configuration change.
That means its context is now aware of the new formatting rules.
But our ViewModel class, DurationsViewModel
survives a configuration change.
It's still using the same calendar object that it created
when the week started on a Sunday.
To fix that, we need to react to a change in locale
and create a new Gregorian calendar instance,
and we're going to see how to do that in the next video. I'll see you there.