Transcript
>> Good afternoon everybody.
Hello to everybody who's still
here.
I'm Steve Hayman.
I'm a consulting engineer from
Toronto, Canada.
Any Canadians here?
Good. How's it going, eh?
I'd like to say hello to those
of you who are still here late
on Friday afternoon.
And to everyone who's watching
the video in the future, hello
people in the future with the
flying cars and everything.
I'm very excited to see what
that turns out to be.
But today we have the thrilling
topic of iOS Configuration and
APIs for Kiosk and Assessment
Apps.
What are we talking about?
We're talking about locking an
iPad to a single application.
We're going to talk about
different ways that you might do
that.
Some of them are manual
processes.
Some of them are programmatic.
But let me show you a couple of
examples of what we're talking
about right now.
So here's my iPad.
Here's one thing you can do.
Anybody can do this on any iPad.
Anybody can go to Settings,
General, Accessibility, way down
at bottom, Guided Access.
And if you turn this on, it is
now possible to lock an iPad,
any iPad, to any arbitrary
application.
A lot of parents and teachers do
this before they turn over their
iPad to their child.
For instance, if your child was
very interested in maps, you
could launch Maps, and then
since Guided Access is on, you
can triple tap, one, two, three
times, on the Home button, and
supply a pass code.
A very secret pass code.
No guessing.
[sound effects].
And now I can hand the iPad to
my geography-obsessed child, and
they can play with Maps all day
long, but they can't touch the
Home button.
They can't get out and start
messing with my stuff, until I
triple tap the Home button
again, one, two, three, and put
in the pass code.
So this is Guided Access.
This is an accessibility
technology from Apple that's
been around for a long time.
It's a basic way to lock an iPad
to any application that you
want.
That's one way, but I want to
show you another way.
We're all developers.
Let's talk about a programmatic
way to do this.
I have a testing application on
here that you might see in a
school for administering
standardized tests.
And in schools, we are a little
bit concerned about letting
students touch the Home button,
and fire up Safari, and go to
Wikipedia during the test.
We don't really want that
happening.
So an application like this one,
when I tap Start Test, we're not
locked right at the moment.
I can still hit the Home button.
But once I touch Start Test,
this particular app is set up to
lock iOS on demand, at the
moment I touch that button.
You get a little panel here that
says, "Do you want to confirm
app self lock?"
And if I say yes, the test
begins.
The Home button is now locked.
It was locked by some code that
I'll show you at exactly this
point.
And I can't cheat in the test.
I can't hit the Home button to
get out.
I can submit my answer here,
Ottawa.
And at the moment I hit Submit,
this particular app unlocks iOS.
So there's a function we're
going to tell you about that
turns the locking on and off.
So now I'm back to a point where
I can hit the Home button.
So those are two different
approaches.
One of them a fairly manual
approach, Guided Access, walking
around and actually triple
tapping on a device.
And then the other one is a
programmatic approach, which I
think you would agree is a
little more flexible.
Those are two ways.
I'm going to talk about four
ways that you might lock an
application.
One that we just saw was Guided
Access.
This is a great technology for
keeping a child, for instance,
focused on a certain task.
You can lock your child into
Swift Playgrounds and not let
them out until they can explain
the difference between a struct
and a class, for instance.
Whatever scenario you want, you
can lock a child to a particular
application.
There's another technology
you'll often see in Kiosks,
single app mode.
This is useful to keep the iPad
pretty much permanently locked
to a particular application.
You've probably seen this if
you've gone to an Apple store.
There's some iPads on display
that are permanently running an
information application, and you
can't get out.
But there are two techniques
available to programmers.
The first is called autonomous
single app mode.
Picture a situation where you
have a medical clinic, and the
nurse is using an application
with confidential information on
it, and then a patient arrives.
You'd like to hand them the iPad
to check in and have it locked
during that little transaction
and have it unlocked when you
get it back so that they can't
hit the Home button and mess
around during one section of
your application.
That's called autonomous single
app mode.
It's a single app mode where
locking takes place, but it's
autonomous, because it's your
application that decides when
the right time is.
And there's a fourth mode
specifically designed for the
education community for people
building standardized test
applications, automatic
assessment configuration.
This is for students taking a
high stakes test, and it locks
the iPad, but it also disables
some additional features, like
spellchecking, and auto correct,
and Siri that you would not want
a student to be using on a test.
We're going to talk about these
four scenarios.
They each have different
technical requirements.
Guided Access really just works
on any iPad at all.
Anybody can walk up, and turn it
on, and triple tap to enable it.
It's a very widely available
technology.
Single app mode that you would
see with Kiosks, this is
something that only works on a
managed and supervised device.
So it won't work on the
run-of-the-mill, bring your own
iPad from home.
It works only on a managed
device, and it requires support
from MDM and from the system
administrator.
Somebody has to designate
exactly which apps, exactly
which single app, we're going to
lock right now.
Autonomous single app mode, much
more flexible.
It still requires supervised
devices, and it requires the
administrator to white list
specific applications, but now
it means that the iPad can
decide.
Your app can decide when to turn
the locking on and when to turn
it off.
And finally, the last one,
automatic assessment
configuration, is the best for
assessment developers because it
locks the iPad and it also
disables a whole variety of
features that creative students
might use to enhance their ways
to answer questions on a test.
That automatic assessment
configuration requires a special
entitlement that you can apply
from Apple, but once you've got
that entitlement, your app can
lock any device, whether it's
managed or not.
So locking an iPad
programmatically.
Several different ways.
Guided access, we saw a moment
ago, is a great way to focus a
child on a particular task, and
it has some obvious advantages.
Anybody can set it up.
It's very easy to set up.
And a couple of concerns.
It's not a particularly scalable
way to do anything, because you
have to walk around and actually
touch every iPad.
If you have hundreds of students
who are about to take a test,
someone would have to walk
around and touch the Home button
three times on each of the 100
devices.
That doesn't scale very well,
plus you have to manage a pass
code.
So it's great for some
situations, but not others.
Single app mode that you might
do with a kiosk brings a level
of remote control to this
process.
If you have iPads where there's
only one application that you
might ever want to run, maybe
something that displays train
schedules or conference room
reservations, an admin can push
a command to a managed iPad to
lock it right now to that
application.
In fact, you can lock hundreds
or thousands of applications of
iPads simultaneously.
Here's what it might look like.
Let's suppose you have some sort
of a tourism kiosk, and you want
your iPad to run this
application only.
An administrator using an MDM
tool, which specify that your
application is the one that's
allowed to do single app mode,
and then the moment they push
this configuration out, the iPad
immediately launches that app,
and it stays in that app.
If you reboot the device, it
goes back to the kiosk
application again.
This is a good way to pretty
much permanently lock an iPad to
a particular application.
The way you get out of this is
to push a new command from the
Admin Console to remove this
single app mode setting.
Very useful to lock thousands of
devices simultaneously and more
or less permanently, but it does
require IT involvement.
We have seen situations where
people have forgotten to unlock
the iPads via this technology.
If you were a school, and you
locked all the iPads to the math
test, and you forgot to unlock
them, now nobody can do anything
until you remember to push out
that next command.
It does require a supervised
device managed by MDM, and I
would say the main downside to
this is that developers really
have no control.
When you lock with single app
mode, the device immediately
locks, we're stuck in that
application.
Not very [inaudible].
Wouldn't it be interesting if --
wouldn't it be great if, as a
developer, you could control
exactly when that locking
happened?
Like, for instance, if you had a
medical practice like this, with
a patient management application
full of confidential
information, when the patient
arrives, wouldn't it be great if
you could hand them the iPad,
touch that button, and know that
the iPad is locked, the Home
button does not work while we
are on this screen.
And then once the patient fills
in all their information, they
might touch Check In, hand the
iPad back to me, and now it
could be unlocked, and we would
regain full control.
Wouldn't it be great if clicking
that button right there, right
there, wouldn't it be great if
clicking that button right there
turned locking on?
>> Yeah!
>> Yes, yes, you're right.
It would be great.
Wouldn't that be great?
What about this side?
This side, you think that would
be great?
>> Yeah.
>> Yeah, it would be kind of
cool, wouldn't it?
Well, you know what, have we got
a function for you.
Well, as a matter of fact, that
would be great, and we do have a
function for you.
[ Applause ]
.
And here it is.
UIAccessibilityRequest
GuidedAccessSession.
Nice, easy-to-remember function.
UIAccessibilityRequest
GuidedAccessSession.
That turns locking on and off.
Here's another function.
Is Guided Access Enabled?
It's a Boolean.
Is it on or off?
You can check.
And there's a notification
you've asked for.
You can be alerted when the
status changes.
But mostly, there's this
function here,
UIAccessibilityRequest
GuidedAccessSession.
This is the key.
If your device and your
application are set up the right
way, and there is some setup
required, then your app can call
this function lock the iPad
right now, and it can call it
again to unlock.
And let me underline that.
If the iPad and your application
are set up the right way, this
is a powerful function that is
not available to all
applications.
Adding the code is important,
but there's some other steps you
actually have to do.
So speaking of code, let's see
some code.
You would call this function to
start a locking session.
You would pass it either true or
false.
Do you want to lock?
Do you want to unlock?
And you would also give it a
completion handler that would be
called when your request
completes.
It can take a second or two for
the locking to take effect, so
you pass a completion handler,
and your completion handler gets
a Boolean parameter that
indicates whether the request
succeeded or not.
It's possible that the request
could fail, and so you want to
actually check that.
But if all goes well, you can
check if the request succeed and
now do something with the
confidence that the iPad is
locked at this point, and the
Home button is disabled.
So in our hypothetical medical
example, let's suppose we have a
function like this that loads
New View Controller with a
patient check-in screen on in.
you could wrap that in code like
this, and then that transition
would only happen if the device
had been locked successfully.
Then when the patient is done,
you've got some other function
that transitions back to the
main screen, you would put
something like this in here.
You would say
UIAccessibilityRequest
GuidedAccessSession false, and
that's a request to turn off at
app lock at that point.
There's another one you can
call.
Is Guided Access enabled, true
or false?
You can do some extra checks.
You can check at any time
whether you're currently in a
locked state or not.
There's also a notification,
UIAccessibilityRequest
GuidedAccessStatusDidChange, and
you can register for this, and
your app can be notified
anywhere as the status turns on
and off.
So all this technology taken
together is called autonomous
single app mode, ASAM.
It's like single app mode, but
it's autonomous, because your
app can control exactly when the
locking and unlocking takes
place.
You can lock just part of an
application.
Now for this to work, iPads do
need to be set up in a
particular way.
Let's talk about the
requirements.
The first requirement, you have
to write the code.
You have to call that function.
Second requirement, the devices
have to be supervised, which is
a sort of extreme form of iOS
management.
And thirdly, your app needs to
be white listed by the MDM
administrator.
The administrator can grant
permission to call this function
only to certain applications.
So here's what an admin would
do.
In an MDM tool, there's a place
where you can mark which
applications are allowed to
enter and exit single app mode.
Only the applications on this
list will allow that function to
work.
So you'd list exactly which apps
are allowed to use it here.
And remember, this only works on
supervised iPads, not iPads that
people are bringing from home.
Ultimately, this converts to a
particular key and value in a
configuration profile.
The bundle IDs of all the apps
that are authorized to do this,
that's transmitted to the
device.
And once that configuration is
set up, your app can actually
call that function and turn the
locking on and off, and you have
control.
It's autonomous single app mode.
You can prevent people from
accidentally getting or
deliberately getting out of the
application.
However, there are a couple of
issues.
It does require an MDM managed
and supervised device, and the
IT department has to
specifically white list your
application, grant it
permission.
And all this is really onerous
in some situations.
It's ideal for the patient
check-in scenario or the
scenario with the bank where the
mortgage specialist is handing
you the iPad to fill in your
information.
We want to lock it right then.
It's great for that kind of
scenario, but it's not really
robust enough for assessment,
for testing.
Testing has its own set of
requirements.
If you're delivering a test to a
large group of students, it's a
kind of a high-stakes scenario.
Not only are the students going
to be judged on their knowledge,
but the teacher and the school
are going to be judged on the
results as well.
So it's important that we
deliver a test in an application
with the highest possible
integrity.
We don't want students cheating.
That's what we're talking about
here.
We want to make it hard for
students to cheat.
These three technologies are
useful in other scenarios, but
not in an assessment scenario,
because they leave certain
features running, like
spellchecking and then the
dictionary lookups and so.
Those are still running in these
other scenarios, and you
wouldn't want that in a test.
So Apple recommends automatic
assessment configuration as the
method that a test builder
should adopt.
What is it?
Well, assessment apps have
unique challenges.
That are a whole lot of very
useful features on iPad that are
not appropriate when a test is
actually running.
In order to protect the
integrity of the test, we're
going to want to disable things
like copying and pasting from
outside the test into the test.
We're going to want to disable,
obviously, other applications.
But we're also going to want to
disable spellchecking on an
English test, and we're going to
want to disable the built-in
dictionary.
So you need to be able to
disable certain hardware
features to run a secure test,
and you might not have
considered this, but you also
need to disable sharing off the
iPad.
We can't have a student copying
all the questions and using the
Share menu to ship them off to
another iPad of another student
outside.
We need to turn off that
universal clipboard as well.
In fact, we need to turn off a
whole lot of things.
You really do need to turn off
all these features like this to
run a safe and secure test.
This combination of locking iOS,
as I showed you before, plus
automatically disabling all
these features is called
automatic assessment
configuration.
Now AAC, automatic assessment
configuration, works just the
way I showed you with ASAM.
It's the exact same function.
You call a function true to
lock, false to unlock.
You check the status.
Exactly the same process right
there.
But in addition, the moment you
lock with this function, all
these features are going to be
automatically disabled for the
duration of your test, and when
you call the unlock function,
they're all enabled.
There is a requirement here.
This works on any iPad, whether
it's managed or not, but it's a
pretty powerful technique, so
you need to have a special
entitlement in your application
before that request will
succeed.
Technically, the request is
called com.apple.developer.
edu-assessment-mode.
You need to apply to Apple for
this entitlement, and once you
have it, your application will
be able to lock and unlock with
no need for a supervised device
and no need for white listing.
Your app needs to be built with
a profile that includes this
special entitlement.
And once it locks, well, how
does it unlock?
Well, the device is locked.
Normally, it would unlock,
because at the end of the test,
you would call the function that
says false, time to end our
session, the student has
submitted the answers.
But the iPad also unlocks if the
user reboots it.
This isn't like single app mode
where we permanently keep you in
a device.
It's a temporary single app
mode.
And it also unlocks after eight
hours.
This is a -- if you are
administering a particular long
test, you might want to be aware
of this.
You will get a notification that
the locked status has changed,
and you could take that
opportunity to lock it again.
Let me know if you're creating a
test that takes eight hours to
finish.
I do not want to write that
particular test.
But what people see when they're
doing this is this.
This is a sample application.
There's sample code associated
with this session that you can
download.
Two buttons that turn locking on
and off.
This app was built with the
right entitlement, and there's a
text field where you can try
typing to see if spellchecking
works, and there's a log of what
happens.
When you tap the Enable App Lock
here and call that function I've
been talking about, this panel
is automatically displayed.
The gives the user the
opportunity to say yes or no,
they are willing to enter the
lock session.
And if they tap yes, a banner
automatically appears at the top
that says your iPad is now
locked, and it's going to unlock
after eight hours or when you
finish the test, and then that
goes away after five seconds.
Now the iPad is locked until
such time as somebody runs,
calls the function to unlock.
In this demo app, tapping the
red button calls the unlock
function, then you get another
banner across the top.
"Your iPad is no longer locked."
In between the green and the
red, the Home button was
successful disabled, and this is
a pretty simple sample
application.
Just two buttons with two action
methods.
One calls the function with true
to lock.
The other one says false to
unlock.
Let's talk about some of the
considerations in here.
It's pretty good that the apps
can lock and unlock themselves,
and it's great for assessment,
that all these other features,
like spell check, are
automatically turned off in
addition to the locking.
You, the developer, have
control, and this doesn't
require a managed device.
In a school situation, this will
work on a device the student
brings from home.
However, you do need this
particular app entitlement in
your application, and this
entitlement is only for
assessment developers.
How would you implement this in
your app?
Well, the first step is to
actually apply to Apple for this
entitlement, which will be
granted to assessment developers
but not to anybody else, and
then you build a provisioning
profile that includes that
entitlement, and build your app
with that profile.
The way you ask for this
entitlement is to submit a tech
support incident, and tell us,
tell Apple that you would like
the education assessment mode
entitlement.
And then once that's been
granted to you, you can go to
the developer portal and build a
new profile that includes that
entitlement.
You will only see this selection
here if you've been granted the
entitlement, and you can now
build a provisioning profile
that has this special
entitlement in it.
Don't forget this step.
It's not enough for Apple to
grant you the entitlement.
You have to create a profile
that has it embedded, and
download it, and use it in
Xcode.
Also, don't forget that you want
to apply this to several
different profiles.
It's not enough just to put the
entitlement in your development
profile.
You should put it in the
distribution one, and if you've
done it correctly, you should
see here in Xcode, once you
select a profile with this
entitlement in it, you can touch
that little info button, and you
can see the entitlements that
are built in here.
That's the way to confirm that
you're doing this right.
If you see that magic string
there, com.apple.developer.
edu-assessment-mode, you're good
to go.
You can now build an application
that actually uses this
technology.
When would you do it?
Well, when you're ready to enter
the test, you'd call the magic
function with true, and when
you're ready to get out of the
test, you'd call it with false,
and it's very important to check
whether it worked or not,
because there were some
scenarios where it can fail.
I'm going to try actually doing
this.
I'm going to try actually
building something that they
used this year.
Take my life in my hands here.
So you remember this testing
application that I showed you
before.
I have a secure version and an
insecure version of it on this
iPad.
I'm going to show you the
insecure version, just to
highlight some of the problems
that might come up in a test,
then I'm going to change the
insecure version into the secure
version.
This is the insecure version of
the test.
If I touch Start Test, I could
do all kinds of cheating things.
I could look up Canada in the
built-in dictionary.
Oh, there's the capitol right
there.
It's Ottawa.
That's pretty good.
Let's assume that we've blocked
the Home button.
Even if we've blocked the Home
button, a lot of other stuff is
possible.
If I type my answer up here,
O-T-T, I'm getting suggestions
in the completion bar that
happen to include the correct
answer.
You'd probably like to disable
that in a test as well.
You should probably disable the
share sheet.
We do not want students sending
the questions to their friends
somewhere else.
All this stuff needs to be
disabled in addition to the Home
button.
I mean, my Home button's still
working here.
That's the first problem.
So I'm going to show you the
code for this particular
application here, and then we're
going to try turning this into a
secure version.
So this is really a "nothing
app."
I put no effort into this
application at all.
It's a couple of view
controllers, and we touch the
Start the Test button, and it
loads another view controller
right here.
That's the time that we want to
turn locking on.
There are, however, a few
prerequisites that you have to
do before you can do this
locking dance.
First of all, you have to have a
provisioning profile with the
right entitlement in it.
You have to have applied to
Apple for this entitlement, and
generated a provision profile
that includes it.
I fortunately have done that, so
I'm just going to change my code
signing right here to use this
provisioning profile, which I
have previously downloaded, and
it has the magic entitlement in
it.
I can verify that touching the
info button right here, and
you'll see that the
com.apple.developer.
edu-assessment-mode entitlement
is buried in here.
We're good.
I can compile an app now that
will use this particular
entitlement.
That's step one.
Step two is that Xcode these
days is particularly cautious,
I'll say, and Xcode wants you to
state exactly which entitlement
this app needs to use right now
by creating an entitlements
file.
It's not enough just to have the
provisioning profile with the
entitlement in it.
You also need an actual
entitlements file.
I've made one of these here.
Entitlements files are just keys
and values like that.
So I'm going to add this.
This is the awkward part of the
demo.
I'm going to add this
entitlements file to my project,
and I'm going to go to the build
settings, my favorite part of
Xcode, looking around at the
build settings for the
entitlements, and I'm going to
tell it that I want to use that
file, AAC.entitlements.
I'm specifying that that's my
entitlements file specifying
that, yes, I really do want to
use education assessment.
All right.
Now I think we're okay to go.
This is still an insecure test,
because it's not making any
effort to call the locking
function, so I'm going to put
that in.
I'm going to put a lock around
this present line right here.
Here we go.
[inaudible] Apple we have these
little shortcuts ready to go.
This is the block of code that I
just pasted in.
We're going to request a Guided
Access session with the
parameter true.
True means lock, yes, now.
And if it succeeds, we're going
to do one thing.
If it fails, we're going to do
another thing.
So I'm going to move this line
of code up into that if block up
there.
By the way, if you take nothing
else home from this session,
command option left bracket
moves lines of code up, and
command option right bracket
moves them down.
This is the greatest thing.
Hey, oh, look at that fun.
Anyway, we is now put that
inside this if statement.
So we're going to request a
lock, and if it succeeded ,
we're going to present the other
view controller.
It's important to pair the locks
with the unlocks.
You have to have some way of
unlocking the application.
And in this particularly
extremely simple app , I'm just
going to do it here.
Every time this main test picker
view shows up on the screen,
we're going to unlock.
This is an unlock call to that
function.
We're passing it false to say
please try to unlock the device.
So we lock the device when we
leave the test picker screen,
and we unlock it when we come
back to the test picker screen.
I think we're okay here.
Let's find out.
Try running this.
And here it is.
So I'm going to choose the
geography test, and I'm going to
touch Start Test.
That's when the lock code is
invoked.
I'll touch Start Test.
now it's asking me.
Now it's asking me the user to
confirm that we like to enter
single app mode for the duration
of eight hours or until the test
is over, and I'll say yes.
Now that I'm in the geography
test, you'll see the banner at
the top advising me that would
like for the next eight hours or
until the test is over.
I can't look anything up here
anymore.
That had the look up button on
it before.
I could have looked up the
answer in Wikipedia, but that's
been automatically turned off.
My spell checking has been
automatically turned off down
here.
we're really taking all the fun
things out of the iPad here for
the duration of this test here,
just to ensure that we have a
test with some integrity here.
The capital of Canada is Ottawa.
Alright. And when I touch the
Submit button, we return to this
screen, and ASAM is turned off
with the other function I put
in.
now the Home button is now
working.
So the Home button was not
working while we were in the
test.
All those cheating services were
not working either, and once we
exited the test, everything was
fine.
I'm feeling kind of confident
here.
I want to try another test.
I think I did okay in the
geography test.
Let's try another one here.
Spelling. I'm good at spelling.
So we'll lock as we go into the
spelling test.
Here are my spelling words.
What's that?
>> Schnauzer.
>> Schnauzer, okay.
Can I have the definition of
"schnauzer"?
>> A medium or small-sized dog
of a German breed with a closed
wiry coat and heavy whiskers
around the muzzle.
>> Okay, I think I can spell
that.
Can I have it in a sentence,
please?
>> Get a load of that guy's
schnauzer.
>> All right, schnauzer.
Let's see here.
[laughter].
>> S-C-H-N-A-U.
>> You notice I'm not getting
any typing situations here.
>> Zed.
>> Zed, thank you.
From Canada.
>> E-R. [ringing].
>> Hey, all right.
I got that one right.
I'm feeling kind of cocky.
I want to try another word.
I got ten minutes left.
I'll do a couple more words in
the spelling test.
What do you say?
Let's try one more word in the
spelling test.
>> Syzygy.
>> Uh-oh. What?
>> Syzygy.
>> Syzygy?
>> Syzygy.
>> Can I have the definition.
>> A conjunction or opposition.
>> That's not really helping me.
>> Syzygy.
>> Can you use it in a sentence.
>> Your spelling bee word is
"syzygy."
>> Okay. Man, I don't know.
>> S-Y-Z-Y-G-Y.
[ Ringing ]
.
>> Hey, all right.
One more, one more.
I'm feeling pretty good here.
One more, one more here.
Let's try one here.
>> Calfafa [phonetic].
>> What's that again?
>> Calfafa.
[ Applause ]
.
Calfafa.
>> Jeez, I don't know that one.
Can you use it in a sentence?
>> Despite the constant negative
press, calfafa.
>> Calfafa.
All right.
C-O-U--
[ Ringing ]
.
Oh, I was spelling it the
Canadian way, C-O-U.
I'm sorry.
Anyway, I can't hit the Home
button while this test is going
on, because we requested a
locked session.
The moment I hit Submit, I'll
transition back to that other
screen, and I'm now able to hit
the Home button as the test is
over.
So it's that straightforward.
[ Applause ]
.
Thank you.
Oh, you're too kind.
So it's pretty straightforward
to actually add this to your
application once you have that
entitlement.
I've got to remind you.
You've got to get that
entitlement from Apple before
the locking and the disabling is
going to work.
Let's talk about a couple of
other considerations.
I've mentioned that the request
to lock might fail, and that's
true in the ASAM model where
you're deploying to a supervised
device and also the AAC model
where you're deploying to any
device with the entitlement.
The request to lock can fail, so
you really do need to check that
parameter.
In ASAM, it will fail if the
device is not supervised and if
the bundle identifier hasn't
been set up properly.
In other words, if the device is
not being managed properly for
your test, an ASAM request will
fail.
In AAC, it will fail if your app
does not have this entitlement
built in.
In both cases, it will fail if
the user hit "no" on that button
where -- that panel where
they're asked if they want to
lock or not.
But, and this is kind of weird,
it will fail if the device is
already locked.
This is a little weird.
If you make the lock request
twice in a row, the first one
will succeed.
You'll be locked.
If you ask to lock again, the
second one will fail, but you'll
still be locked.
So you have to be careful about
this in the setup of an
assessment application.
All those restrictions of
disabling the dictionary and
spell checking, those are only
there if it was your app that
actually successfully called
that
UIRequestGuidedAccessSession
function.
If you were locked for some
other reason, those restrictions
are not going to be in place.
So it is a good practice to
check.
Before you try to lock the
device, check if it's already
locked.
Because if it already is locked,
and you didn't do it, something
is wrong.
We're in an odd situation.
Maybe somebody walked up and
turned on Guided Access with the
triple tap thing.
If they did that, the
restrictions are not going to be
disabled properly.
So it's important that you
actually check.
Here's one way.
You can check when the app is
launched.
We suggest you wait for two
seconds after app launch,
because it takes a moment to
lock everything, but you can
check after app launch, call
that Is GuidedAccessEnabled
function.
And if you are locked
immediately after launch,
something is wrong in your
testing environment.
You weren't supposed to be
locked at this point.
For a test, you should stop at
that point.
You should not proceed with the
test.
Similarly, you should do a test
before attempting to call the
lock function.
You should check that Guided
Access is false,
GuidedAccessEnabled is false
before you try to lock.
You want to make sure you're in
the right state before you call
the locking the function to
ensure that not only is the
device locked, but it's locked
with the restrictions.
Here's another consideration for
a standardized test.
Probably a good idea to clear
the paste board coming in and
leaving your test.
AAC automatically disables the
universal clipboard for sharing
to other devices, but you need
to clear the built-in system
paste board when the test starts
to keep a child from copying the
test in notes and then launching
the app.
You want to clear that out.
You probably want to clear it on
exit of the test as well, so
they don't copy the questions
and see it somewhere else.
Pretty straightforward to do
that.
You just set the items of the
general paste board to an empty
array.
You should probably consider
disabling third party keyboards
in an assessment app as well.
Third party keyboards are app
extensions, and they're not
blocked by AAC.
You might have an application
like this, where the student has
installed another keyboard which
actually some keyboards actually
support searching right in the
keyboard.
You could search for the capital
of Canada right there in the
keyboard and get the answer.
That's probably not a good
keyboard to use in a test.
So as a developer of an
assessment application, you can
implement this function in your
application delegate to allow or
disallow specific types of
extensions as they are being
voted.
I would suggest just disallowing
all of them, especially
keyboards.
But disallow all extensions in a
standardized test app.
Remember, the goal is to take
all the fun out of the iPad for
the duration of the test, and
then restore the fun when we're
done.
Let me just review again the
difference between these two
techniques, because in software,
they're exactly the same.
You call this same function,
UIAccessibilityRequest
GuidedAccessSession, and the
effect is different, depending
on how the devices and your app
are set up.
The code is the same.
You call that function.
In each scenario, the device is
locked.
Remember though that in ASAM we
have to be dealing with a
managed and supervised device.
In AAC, we can deal with any
device, so long as your app has
the entitlement.
But the biggest difference is
that AAC also turns off a whole
bunch of other stuff for the
duration of the locking session.
So that is the technology you
want to use if you're an
assessment developer, to lock an
application.
Other developers may find that
ASAM meets their needs, but AAC
is specifically for assessment
developers.
So we talked about four ways to
lock an app.
Guided Access, lots of fun.
Do that when you get home.
Lock your children into the
SpongeBob Squarepants
application so that they can't
look at your mail, and then
that's a nice easy end user sort
of thing to do.
Works on any device with any
app.
Single app mode is good for
kiosks, but it requires the
administrator to push out a
command to a fleet of managed
supervised devices, and then
they are pretty much permanently
locked to the application.
And then ASAM and AAC are the
same software function with two
different effects, depending on
the setup.
Two different effects depending
on whether your app has this
entitlement and whether the
devices are managed or not.
So there's a bunch of related
sessions at the conference.
I hope you enjoyed all the
related sessions.
I like that second one on
heifers and HVAC.
I think that's the air
conditioning for cows.
Oh, I'm reading that wrong.
HEIF and HEVC.
A lot of our assessment
developers deliver web content
as part of their applications,
so I think these are
particularly relevant sessions
for people to use.
But for more information and for
-- including a sample
application that demonstrates
how all this works, please take
a look at the website here for
Session 760.
Thank you very much.
Thank you for coming.
I hope you enjoy the week.
[ Applause ]
Thank you.