Welcome back. It's slightly annoying having to leave the report screen
to change the settings, especially as one of the settings
is used to configure the report.
Adding the option to the reports menu is trivial,
so let's get that out of the way.
Edit the menu report menu file in res/menu,
drag a new menu item to the end of the menu.
The ID should be rm_settings,
and the title should be the string resource
menutitle_settings.
For the show as action, choose never.
That's the menu changed.
Next, we respond to it being tapped.
We do that in the OnOptionsItemSelected function
in the DurationsReport class.
I won't spend time in the video
testing the settings option appears on the reports menu.
I suggest you do test it
to make sure you haven't introduced a bug into the app.
What you'll find is that changing the FirstDayOfTheWeek in the settings
doesn't update the report.
To make the changes take effect straight away,
we need to observe the change to the app's shared preferences
and respond when they change.
The code to do that is very similar to how we're observing changes
in the ContentObserver
and also similar to our BroadcastReceiver.
We create an implementation of the shared preferences
on shared preference change listener interface and register it.
We'll also unregister it in the uncleared function.
We had a good demonstration of what can happen if you don't unregister things,
so I don't think we need to say very much more about that.
I'll create the listener after our BroadcastReceiver
in the DurationsViewModel.
It's important to check that we're responding to a change in the
settings FirstDayOfTheWeek preference.
We re-query the database
and don't want to do that if an unrelated setting is changed.
Our listener will be called when any of the settings are changed,
so we ignore anything that won't affect the report.
If the first day of the week setting is the one we were called about,
we'll update the _FirstDayOfTheWeek variable,
then set the calendar to the new first day.
We used very similar code in the BroadcastReceiversOnReceive function.
All right. Next, we have to register the listener in the init block.
And of course, we need to unregister it in OnCleared.
Time to test it. I'll run the app and go into the reports.
It's easy to check that everything's working if I sort the report by date.
At the moment, I've got rows from Tuesday to the following Monday.
My week currently starts on a Tuesday.
Call up the calendar to check if you've been experimenting with the settings.
I'll go into the settings and change the first day to Friday.
That's a day that is used in some places around the world.
Tap okay, and the report updates straightaway.
Listening to settings changes like this
makes your app more responsive to your user.
If they change one of the settings,
they naturally expect the app to use the new values
and this is how you can do that.
There's only one thing left to implement in our app
and that's the setting that lets the user choose to ignore short timings.
We've provided the setting but we're not using it yet.
So here's the challenge. Can you implement that feature?
All the changes will be in the TaskTimerviewModel class,
you'll need to listen to the change and update a variable
when the settings_ignore_less_than preference changes.
The variable will be used in the saveTiming function
to only save timings that have a duration greater than it.
Be careful with that part because it's not quite as straightforward as it seems.
Make sure you understand how we're saving the timings
before changing the saveTiming function.
We've covered everything you'll need for the challenge.
Have a go and see how you get on.
I'll go over my solution in the next video.
Good luck, and see you there.