Alright, so in this video, I want to talk
a bit about tests. Now we've tested the
app and the various scenarios, in
previous videos in this section of the
course, but there are a few more tests we
should run. It's a good idea to create a
test script, to make sure that you cover
all the possible situations. Now the
script itself doesn't have to be very
complicated,
but it should include the starting
condition as well as the expected
outcome. Now for testing that we've got
the permissions worked correctly, our
script might look something like the
following; so as you can see, we've got
various tests here to start. I'm going to
go through just the first one - we've got
Starting Condition, App not installed, and
we've got various actions there. You can
see we can run the app, and then to the
right-hand side we've got the expected
outcome. For that first test, the expected
outcome is the Permissions dialogue
should appear when the app's not
installed, and so on, going through the
list there. So we've got, basically, quite a
few tests there. And this script, at the
moment, doesn't test Allowing access when
the app is first run, so that should
probably also be included. In addition, it
doesn't include testing on an Android
version prior to API 23. So I'm going to
give you a challenge here, and the
challenge is to add these two tests to
the script, then run them to make sure
that everything works.
Now when I say script, I'm just talking
about a set of scripts that you would
write down on a piece of paper, so
basically, just jot down what you think
the extra two tests should be here. And
in addition to that, there's also another
test that we haven't included, so have a
think about that as well, what that is,
and add that to the script - in other
words, jot that down as well. So have a
think about those tests, pause the
video now, and I'll see you when you get
back. Pause the video now. Okay, so welcome
back. So let's have a talk now, about what
we missed out in that previous set
of scripts. So firstly, the items you can
see in red - they're the additional tests.
So you want to make sure that the app
still behaves correctly, after the user
revokes permissions that are previously
being granted. And obviously there, the
other tests there that we talked about,
was where the app is not installed at the
top. We run the app; Permissions dialogue
should appear, and so on. And then also,
the final script or the final test
there, was if the app is not installed,
running a version of Android prior to
API 23, and the various steps there to
make sure that's tested as well. Al
right, so that's good - we've done that.
So let's actually swing back to Android
Studio, and have a final look at the code
before we leave permissions and get back
to data bases. So the first thing that
I'd now change, now that we've
removed the READ_CONTACTS_GRANTED field,
is in the onCreate method. So let's just
go up to that - you can see that here. Now
the condition there has an if and an
else part - I'm talking about this code
here, on screen. But the only thing we're
doing if the condition's true now, is
logging. Now obviously, previously, we're using
that code to assign the value of true to
our READ_GRANTED_FIELD, but we've
commented that out. Now it is useful to
lock the fact that we're requesting
permission, but it's not really necessary
to log that the permission was already
granted. We'd know if the requesting
permission entry doesn't appear in the
logcat. So consequently, we can simplify
this bit of code. So what I'm going to do
is comment out the existing code, and put
a simplified version above that. And
probably, the quickest way to do that is
just to take a copy of that code. I'm
going to comment that out, and I'm gonna come
down here and paste it in again. And we're
just going to change this round a little
bit. So at the moment, firstly, we've got a
test there for; if hasReadContact
Permission is equal to PERMISSION
_GRANTED,
but we've already decided that we don't
really want to execute this code. So I'm
going to delete those two lines of code,
as well as the else, and then I'm going
to pop up over here, to where it's got
equal to, and set that to not equal to. So
essentially now, we're only going to be
logging the fact that we're requesting
permission, and then actually going
through the process of using the Compat
version of requestPermissions to
actually request the permission. And that's
obviously simplified that and made that a
lot easier to maintain now. So that's
step number one.
The next thing, though, is in the on
RequestPermissionsResult method. Now if
we come down there and have a look at
that, we made those changes in a previous
video. Now that we've done that, really,
the only thing going on here
in this function, is that we're logging -
we're not doing anything else, other than
logging. Now this particular callback
function can be very useful, and we've
used it earlier to disable the Floating
Action Button, if we didn't have access
to the contacts. So you still want to use
it sometimes, but here specifically, we
don't need to use it. As you create more
complex apps that might have secondary
functionality, you may well find uses for
the onRequestPermissionsResult
function. And now you do know how to use
it, if you do actually need that. One
thing you may want to do in here, is
perhaps, provide a more descriptive
dialogue explaining why the app needed a
permission that's been denied, and
explaining what the app won't be able to
do, without access - in other words, without
that permission being enabled. Often
though, we were not really interested in
knowing if permission was granted or not.
You write the code to cope with both
conditions, so there's really no point
creating the onRequestPermissions
Result function, just for the sake of it.
So for that reason, I'm going to comment
out the entire function, like so. Al
right, so that's the end of the
discussion on the Permissions model
introduced in Android marshmallow, and
we've covered quite a bit here. Now
hopefully, when you read through the
documentation, and I'll just go back to
Chrome - so basically, this link. So
hopefully, when you go through this now,
it'll make a lot more sense now you've
seen it in action. The new system is very
flexible, at least for the users, and
doesn't really create a lot of extra
work for us, as developers. Most of the
time, you'll probably just copy the code
from this app, or from the Google
documentation, and use slightly modified
versions of that. Now if you do want to
use something, or do something, a bit more
complex, you should now have all you need
to be able to do so, at least from a
permissions point of view. I haven't
covered how to show dialogues yet, but
we'll be doing that in a later video. For
now though, on with databases. So far in
this section, we've looked at databases,
and then we saw how to perform basic
database operations using the Sequel
language and SQLite. We then
experimented with ContentProviders, and
we saw how they're used to provide shared
access to a data source.
And we also used Cursors to loop through
the data from a data source. So with that
done, in the next section, we're now going
to create a full app that uses a
SQLite database. We're going to access the
data via a ContentProvider, so we'll be
seeing how to create and register our
own ContentProvider, to allow the data
to be shared. So let's end the video here
and move on to the next section, and get
started.