Welcome back.
I'm going to fly through these changes with very little explanation
because it's all code we've written a few times now.
Create a new Kotlin file called ParametersContract,
and paste in the code from the resources in this video.
Remember to change the package name on the first line
to match the package name for your app.
If you want to practice creating a contract class again,
then you could copy the TimingsContract class and modify that.
The column names are the two columns that we used in the previous video.
_ID and Value with a capital V.
Next, we need to change the AppDatabase class.
I'll start by updating the version number on line 20.
I'll use a function to perform the update from version 4 to version 5.
I'll call it parameterize view
and add it at the end of the class before the companion object.
Once again, you can find the code in the resources for this video.
Note that we drop the existing view before creating it again.
Line 159 shows how we're using a subquery
to provide the value that the duration will be compared to.
I'm not entirely happy about using the literal value 1
at the end of line
177.
I don't like remembering what number something is.
In this case,
that's the number of the _id column for our parameter
in the parameters table.
If we add more parameters in the future,
then we'd have to remember which id each one had.
That's a good way to create work and to introduce bugs.
If you looked at the ParametersContract class from the resources,
you'll have noticed an extra constant in there.
I'll switch to that file.
I've defined a constant on line 13.
We can use that in our code
rather than having to remember the id that we've used in the table.
Back in app database, I'll use that constant
instead of the literal value 1.
We'll use that constant in our code too.
It'll make the code more readable
because we'll see straight away which parameter we're referring to.
Before I move on,
notice that we add a row to the parameters table at the end of this function.
That's lines 183 to 185.
The view will fail if there's no value in our parameters table.
So our function makes sure the row exists.
Because the only reason for this table is to provide parameters to a view,
you should generally do this if you use this technique.
You'll either be updating or creating a view when you use a parameter like this,
so it makes sense to create the parameters row
when upgrading the database.
Okay. We've written the function,
now we need to call it in OnCreate and OnUpgrade.
So there's all the old ones covered and of course we've got the new case
we're upgrading from version 4.
The final changes to support the new table
are in the AppProvider class.
All the changes are just copy and paste of the timings entries,
changing the name of the contract class and the column names.
I won't do that, I'll paste the code in to save time in the video.
Next, the URI matcher.
I'll also add them to the GetType function.
All right. We finished by providing support for querying
and updating our parameters table.
I'm not going to allow rows to be deleted.
Deleting the parameter from the table would break the database view.
I'm also not going to allow new parameters to be inserted.
As I mentioned, the parameters will be used by a view
and we should add a row for any new parameters
at the same time as we upgrade the database.
The code in on query is the same as for the other tables.
And the code for the update function
is also just a copy and paste, changing the contract name.
Note that we only allow an update by ID,
we don't allow an update of multiple rows.
That would change several parameters
and is probably an indication that our code is using the wrong table.
The only use case I can think of for updating multiple rows here
is if you wanted to 0 all the parameters.
I'm quite happy to force the code to set each parameter individually
rather than implement something that probably won't be used.
There was nothing earth-shattering in any of these changes,
they're just more of the same.
Adding new tables to a content provider
is generally just boilerplate code
with a bit of thought about what operations you're going to allow on the new table.
In our case, we only allow the table to be queried
or a single row to be updated.
We'll change our view models to use this parameter
in the next video. I'll see you there.