Welcome back again, everyone.
The changes to our ViewModels are very simple.
In the TaskTimerViewModel,
we need to observe the changes to the settings
and update our new parameters table when the setting changes.
That's easy because we're already observing the shared preferences.
What we need to do is to update the database parameters table.
So there's nothing new there.
It's our standard approach for updating data in the database.
Use ID short timing on line 50,
rather than having to remember that the parameter we want has the id of 1.
Although we've only got one parameter, it's still a good idea to avoid having
magic numbers in our code.
We can tell without having to even think about it,
which parameter we're updating here.
The next change is in the SaveTiming function.
The comment on line 198
gives away what the change needs to be.
At the moment, we're only saving timings that are long enough,
but we want to save all timings.
The view will filter out the ones that we don't want to include in our totals.
The change here just involves deleting all the code
that deletes the short timings.
Reformat the code from the code menu
to make everything look nice again.
The change in the DurationsViewModel class is also simple.
But let's test the app first
that'll make it more obvious what the change is for.
Run the app,
type app database
into the logcat search box to save hunting through the logcat to find it.
To test this feature, I'm going to clear out all our data.
We want to be able to spot when some things aren't being included in the results,
and that's a lot easier if we don't have a whole lot of rogue data.
The easiest way to do that is to uninstall the application,
so I'll do that.
This also tests a database is created correctly
when the app is first installed.
After doing that, run the app again.
You'll see the table and the views being created in the logcat.
The instructions should also be correct on the emulator.
They no longer refer to a delete button
but instead the user is told to swipe a task left to delete it.
Next, create 5 tasks.
It's very exciting watching me type,
so that's why we sped up the video for that part.
Okay. There was a reason I stuck with that boring set of names for the tasks.
It's going to make a quick test of the app a lot easier.
Of course, you'll test the app thoroughly.
When you come to do that, generate some more test data
and use a spreadsheet to make sure that the reports are accurate.
At the moment, I'm just testing that out change works.
This is the minimum amount of testing we should do
before passing the app on to the test team.
If you haven't got a test team and as a sole developer you probably won't have,
then you need to do all the work of validating the reports yourself.
It's tedious, as we've said before, but it is essential.
I'm going to pause the video now
and create some timings for various tasks,
some will be short less than 5 seconds
others will be a lot longer, and you don't want to sit there waiting for several minutes
to elapse while we time tasks.
Before I do that, I'll filter the logcat
by typing start time into the search box.
I'll quickly start timing task 2, then stop it again
so you can see the logcat entry.
We get the task ID at the start of the log entry
and the duration at the end.
Task 2 has the ID 2,
which is why I was boring in my choice of task names.
We can easily identify the durations that should be filtered out
and which tasks they relate to.
That's a lot easier than examining the database to see what's been saved.
You can copy all the entries into a text editor,
so you've got them on hand when it comes time to verify that the report is correct.
Okay. I'll pause the video now and create a few new timings.
Okay. Welcome back.
As you can see in my logcat, I've got a load of timings,
varying from a couple of seconds to nearly a minute,
and one really long one where I went and got a cup of tea.
On the emulator, go into reports
and let's make sure that things add up.
We've got our raw data in the logcat.
Any useful technique that you can use
is to hold down the alt key
and click just before the start of the first ID
then drag,
so that we just get the data that we want and not all the information over on the left.
If we copy that we can paste it into a spreadsheet.
I'm going to use numbers on the macintosh,
and when we paste it in each thing goes into a separate column.
I'm going to sort by the first column
because that's going to make it easier for us to add things up.
Of course that was just a quick and dirty way of doing it.
When you perform thorough testing, you should probably export the timings
into a CSV file
then put that into a spreadsheet program and have it do a lot more of the work.
Back in the emulator, I'll go to the reports.
We're currently totaling the durations for all the records,
and it reflects that task 1
307 seconds is 5 minutes and 7 seconds
task 2 is 2, task 3 is 32,
4 is 39 and 5 is 58. So that's all working fine.
So let's go into settings and change the value.
I'll set it to ignore timings of less than 5 seconds.
We click okay,
and nothing changes.
That's what we still have to implement in the DurationsViewModel.
The data doesn't refresh when we change that setting.
Until we make that change to DurationsViewModel,
tap back to return to the main screen,
and then go to the reports again.
Now all timings less than 5 seconds have been ignored.
Task 2 has disappeared because the whole task was less than 5 seconds.
And so we've got different values showing on the report.
In the next video, we'll make the changes to the DurationsViewModel
class so that the reports update automatically. I'll see you there.