705.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:10.676 A:middle
[ Silence ]

00:00:11.176 --> 00:00:11.806 A:middle
>> Good morning.

00:00:11.936 --> 00:00:17.056 A:middle
I'm Steve and I'm going to
talk today about what's new

00:00:17.056 --> 00:00:18.166 A:middle
in Foundation Networking.

00:00:19.706 --> 00:00:24.086 A:middle
So, Foundation Networking
gives you new API this year:

00:00:24.516 --> 00:00:25.476 A:middle
NSURLSession.

00:00:25.886 --> 00:00:27.376 A:middle
You might have heard this talked

00:00:27.376 --> 00:00:31.516 A:middle
about yesterday during the
multitasking APIs talk.

00:00:32.676 --> 00:00:35.586 A:middle
NSURLSession is a replacement
for NSURLConnection.

00:00:35.816 --> 00:00:38.206 A:middle
The big benefit it's going

00:00:38.206 --> 00:00:40.716 A:middle
to give you right off
the bat is out-of-process

00:00:40.766 --> 00:00:41.766 A:middle
background transfers.

00:00:41.766 --> 00:00:46.676 A:middle
It's a way of providing your
applications with the ability

00:00:46.676 --> 00:00:48.256 A:middle
to get work done when
you're not running.

00:00:48.946 --> 00:00:52.376 A:middle
It's available on iOS 7
but also in OS X Mavericks.

00:00:53.006 --> 00:00:56.206 A:middle
I'm mostly going to talk
about some enhancements

00:00:56.206 --> 00:00:57.746 A:middle
to the Foundation frameworks

00:00:57.746 --> 00:01:01.146 A:middle
around some specific
technologies, NSNetServices,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:57.746 --> 00:01:01.146 A:middle
around some specific
technologies, NSNetServices,

00:01:01.146 --> 00:01:04.086 A:middle
single sign-on an iCloud
credential syncing.

00:01:05.275 --> 00:01:07.666 A:middle
So off the bat we
have, you know,

00:01:07.666 --> 00:01:12.756 A:middle
sort of a generic chart diagram
of where your application sits.

00:01:12.756 --> 00:01:17.146 A:middle
Your app sits on top of maybe
WebKit, MapKit, UIKit on iOS.

00:01:18.286 --> 00:01:20.166 A:middle
This also sits on top of
the Foundation Framework

00:01:20.306 --> 00:01:22.946 A:middle
which contains the
Cocoa container classes.

00:01:23.276 --> 00:01:25.906 A:middle
There are classes
for scheduling,

00:01:26.056 --> 00:01:28.756 A:middle
for file transfer
and networking.

00:01:29.866 --> 00:01:32.436 A:middle
Foundation sits on top of
CoreFoundation and CFNetwork.

00:01:32.506 --> 00:01:34.336 A:middle
Now, the reason there
is a separation there is

00:01:34.336 --> 00:01:36.376 A:middle
because a long time
ago, we have the support

00:01:36.376 --> 00:01:37.306 A:middle
in API called Carbon.

00:01:38.046 --> 00:01:41.206 A:middle
Nowadays, almost all the work
you guys do is going to be based

00:01:41.206 --> 00:01:42.196 A:middle
on the Foundation layer.

00:01:42.666 --> 00:01:45.356 A:middle
But the CoreFoundation/CFNetwork
layer is still there.

00:01:46.106 --> 00:01:50.246 A:middle
Lastly, networking on our
platform is built on top

00:01:50.246 --> 00:01:52.716 A:middle
of BSD sockets with
enhancements in the kernel

00:01:52.716 --> 00:01:55.476 A:middle
for our specific mobile needs.

00:01:58.396 --> 00:02:01.116 A:middle
In these different frameworks
at these different layers,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:58.396 --> 00:02:01.116 A:middle
In these different frameworks
at these different layers,

00:02:01.116 --> 00:02:03.816 A:middle
there are different
APIs you can use.

00:02:03.816 --> 00:02:05.746 A:middle
BSD Networking uses BSD Sockets

00:02:05.746 --> 00:02:07.376 A:middle
and this is obviously
well known.

00:02:07.726 --> 00:02:11.826 A:middle
But on top of BSD
Sockets, the CoreFoundation

00:02:11.826 --> 00:02:15.106 A:middle
and CFNetwork layer gives
you access to a stream API

00:02:15.236 --> 00:02:17.606 A:middle
in CFStream which allows you

00:02:17.606 --> 00:02:21.036 A:middle
to access files streams
or sockets streams.

00:02:22.006 --> 00:02:26.346 A:middle
CFNetServices which allows you
to publish and subscribe to

00:02:26.346 --> 00:02:29.526 A:middle
or browse for Bonjour services.

00:02:31.036 --> 00:02:34.776 A:middle
And CFHTTPReadStream
which gives you a way

00:02:34.776 --> 00:02:38.976 A:middle
of issuing an HTTP request
and receiving the body

00:02:38.976 --> 00:02:41.936 A:middle
of the response as
the stream data.

00:02:43.556 --> 00:02:47.956 A:middle
Foundation though gives you some
nice Cocoa APIs on top of this.

00:02:48.416 --> 00:02:51.516 A:middle
NSStream is a direct
replacement for CFStream.

00:02:51.646 --> 00:02:53.666 A:middle
There's no need to use CFStream
if you're using NSStream.

00:02:54.186 --> 00:02:57.716 A:middle
NSNetServices just wraps
CFNetServices but it does

00:02:57.716 --> 00:03:02.276 A:middle
so in a delegate-based
Objective-C ARC compatible way.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:57.716 --> 00:03:02.276 A:middle
so in a delegate-based
Objective-C ARC compatible way.

00:03:03.586 --> 00:03:06.906 A:middle
But NSURLConnection is more
than just a single class.

00:03:06.906 --> 00:03:10.616 A:middle
NSURLConnection is a suite of
classes, a bunch of classes,

00:03:10.616 --> 00:03:12.136 A:middle
it's also the name of a class

00:03:12.136 --> 00:03:15.416 A:middle
which is a little
confusing, but it's true.

00:03:15.906 --> 00:03:17.436 A:middle
Now, today we're
going to talk about--

00:03:17.436 --> 00:03:21.196 A:middle
we're going to talk about
NSNetServices a little later,

00:03:21.196 --> 00:03:23.676 A:middle
but mostly I'm going to
talk about NSURLSession

00:03:23.676 --> 00:03:26.326 A:middle
and then NSURLConnection, how
they relate, why you're going

00:03:26.326 --> 00:03:31.016 A:middle
to use one over the other, and
why you're not going to use one.

00:03:32.036 --> 00:03:33.456 A:middle
So going back in time

00:03:33.726 --> 00:03:37.806 A:middle
for NSURLConnection it
describes both a technology

00:03:37.916 --> 00:03:40.706 A:middle
that is the suite of
classes that are necessary

00:03:40.706 --> 00:03:44.826 A:middle
for doing HTTP loading,
and it's a specific class

00:03:45.316 --> 00:03:48.996 A:middle
in that there is an instance of
a class called NSURLConnection.

00:03:50.816 --> 00:03:53.706 A:middle
These classes were originally
written for Safari back

00:03:53.706 --> 00:03:55.526 A:middle
at the dawn of the millennium.

00:03:56.256 --> 00:03:58.946 A:middle
And they were first
made available in 2003

00:03:58.946 --> 00:04:02.276 A:middle
which I think the same year we
introduced the Power Mac G5 back

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:58.946 --> 00:04:02.276 A:middle
which I think the same year we
introduced the Power Mac G5 back

00:04:02.316 --> 00:04:05.336 A:middle
when the bits all
went the right way.

00:04:05.336 --> 00:04:06.096 A:middle
[ laughter, applause ]

00:04:06.096 --> 00:04:08.846 A:middle
It provides URL resolution--
thank you.

00:04:08.846 --> 00:04:11.976 A:middle
It provides URL resolution
and loading.

00:04:11.976 --> 00:04:14.306 A:middle
What that means is when
you have an arbitrary URL

00:04:14.306 --> 00:04:17.836 A:middle
like a file URL, NSURLConnection
is going to be used to load data

00:04:17.836 --> 00:04:22.646 A:middle
out of a file URL or out of a
data URL, or you can connect

00:04:22.646 --> 00:04:24.646 A:middle
to an FTP site, but mostly HTTP

00:04:24.646 --> 00:04:26.796 A:middle
and HTTPS is what people
end up using it for.

00:04:27.056 --> 00:04:30.036 A:middle
If you had your own protocol
that you wanted to register,

00:04:30.036 --> 00:04:32.846 A:middle
you could register that
in your process using the

00:04:32.846 --> 00:04:34.426 A:middle
NSURLProtocol class.

00:04:35.266 --> 00:04:39.856 A:middle
So NSURLConnection as an API
encompasses all the loading

00:04:39.856 --> 00:04:42.806 A:middle
machinery for the
Foundation layer.

00:04:44.036 --> 00:04:46.806 A:middle
Configuration of an
NSURLConnection occurs

00:04:46.846 --> 00:04:49.306 A:middle
by tweaking the NSURLRequest
object.

00:04:50.056 --> 00:04:52.676 A:middle
There are a couple of properties
you can set on an NSURLRequest,

00:04:52.676 --> 00:04:55.606 A:middle
some headers maybe you can set,

00:04:55.606 --> 00:04:57.646 A:middle
and some policy decisions
you can set.

00:04:58.176 --> 00:05:01.146 A:middle
But by and large,
NSURLConnection works by looking

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:58.176 --> 00:05:01.146 A:middle
But by and large,
NSURLConnection works by looking

00:05:01.146 --> 00:05:02.866 A:middle
at the global state
of your process

00:05:02.866 --> 00:05:04.236 A:middle
and global configuration
options.

00:05:04.756 --> 00:05:09.746 A:middle
NSURLConnection also gives you
access to proxies automatically,

00:05:09.746 --> 00:05:13.196 A:middle
and it challenges
you for credentials

00:05:13.296 --> 00:05:16.156 A:middle
when an HTTP request is
challenged by a server.

00:05:17.676 --> 00:05:21.456 A:middle
So what this looks like is you
create an NSURLRequest object,

00:05:21.616 --> 00:05:22.466 A:middle
you create it with the URL.

00:05:23.226 --> 00:05:24.446 A:middle
You configure it how you want

00:05:24.446 --> 00:05:27.656 A:middle
and then you create an
NSURLConnection object.

00:05:28.486 --> 00:05:32.446 A:middle
This object represents the
sort of the transient of state

00:05:32.446 --> 00:05:34.316 A:middle
of the request as
it's being made.

00:05:35.226 --> 00:05:37.276 A:middle
You create the connection
with a delegate

00:05:37.556 --> 00:05:40.446 A:middle
which receives information about
the load as it's occurring.

00:05:41.966 --> 00:05:43.906 A:middle
NSURLConnection then
looks in the global state.

00:05:44.176 --> 00:05:47.276 A:middle
It captures the cookie
store, cache, credentials

00:05:47.906 --> 00:05:51.196 A:middle
and any protocols that are
loaded in your process.

00:05:51.806 --> 00:05:56.186 A:middle
And it produces an NSURLResponse
Meta-Data object, and zero

00:05:56.186 --> 00:05:59.526 A:middle
or more NSData objects
which represent the payload

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:00.346 --> 00:06:03.816 A:middle
of what you're getting.

00:06:03.976 --> 00:06:07.286 A:middle
So in your process, you have
some networking needs, right?

00:06:07.286 --> 00:06:08.746 A:middle
And you're just going to keep
doing this over and over.

00:06:08.746 --> 00:06:09.546 A:middle
You're going to create
a request,

00:06:09.546 --> 00:06:11.726 A:middle
you create a connection,
bind it to your delegate,

00:06:12.526 --> 00:06:15.726 A:middle
and the framework is going to
bind to the global storage over

00:06:15.726 --> 00:06:18.516 A:middle
and over and over to produce
these response objects.

00:06:18.516 --> 00:06:21.156 A:middle
So a problem is if
another framework

00:06:21.156 --> 00:06:23.836 A:middle
in your application also needs
to use this global state,

00:06:24.126 --> 00:06:27.086 A:middle
it ends up using and overriding
the same global state.

00:06:27.086 --> 00:06:28.906 A:middle
You can't both have your
own protocol handler

00:06:28.906 --> 00:06:32.546 A:middle
as you can't both have your
own global cache objects.

00:06:33.186 --> 00:06:39.476 A:middle
So the first thing NSURLSession
does is it continues the process

00:06:39.476 --> 00:06:41.376 A:middle
of having confusion over
whether it's the name

00:06:41.376 --> 00:06:42.846 A:middle
of a class or a technology.

00:06:43.416 --> 00:06:44.326 A:middle
It's consistent.

00:06:45.116 --> 00:06:48.016 A:middle
[laughter] I know
that's important.

00:06:49.126 --> 00:06:51.826 A:middle
So it replaces NSURLConnection
as a technology,

00:06:52.186 --> 00:06:53.806 A:middle
but it preserves
almost all of it.

00:06:54.066 --> 00:06:58.596 A:middle
So NSURLConnection as a class
goes away and to be replaced

00:06:58.596 --> 00:06:59.996 A:middle
by an NSURLSession class,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:01.076 --> 00:07:04.626 A:middle
and NSURLSession has some
additional classes associated

00:07:04.626 --> 00:07:06.466 A:middle
with it.

00:07:06.466 --> 00:07:08.886 A:middle
NSURLSession is the
configurable container

00:07:08.886 --> 00:07:10.586 A:middle
for putting network
requests in to.

00:07:11.236 --> 00:07:13.816 A:middle
It gives you better
HTTP options based

00:07:13.816 --> 00:07:15.136 A:middle
on feedback we've
gotten over the year.

00:07:15.196 --> 00:07:16.296 A:middle
So I want to be able to this.

00:07:16.296 --> 00:07:18.366 A:middle
Well, you couldn't
before, now you can.

00:07:19.686 --> 00:07:21.656 A:middle
It gives you access
to the storage objects

00:07:21.716 --> 00:07:23.086 A:middle
on a per session basis.

00:07:23.506 --> 00:07:25.386 A:middle
So you can have private
storage objects.

00:07:26.866 --> 00:07:28.426 A:middle
It improves authentication
handling

00:07:28.426 --> 00:07:32.056 A:middle
by having an explicit
authentication challenge

00:07:32.056 --> 00:07:34.826 A:middle
mechanism for connection-based
requests.

00:07:35.146 --> 00:07:39.796 A:middle
In NSURLConnection, when
a request was challenged

00:07:39.866 --> 00:07:43.216 A:middle
by a server to authenticate
against a pipe,

00:07:43.216 --> 00:07:47.336 A:middle
for instance an NTLM server,
the challenge would come back

00:07:47.466 --> 00:07:49.416 A:middle
for an arbitrary request.

00:07:49.416 --> 00:07:50.446 A:middle
You wouldn't know necessarily

00:07:50.446 --> 00:07:52.626 A:middle
which request would
get that challenge.

00:07:53.206 --> 00:07:55.226 A:middle
Now, challenges for
connection-based

00:07:55.226 --> 00:07:57.486 A:middle
of are sent directly to
the session delegate.

00:07:57.916 --> 00:08:02.546 A:middle
And I have this rich delegate
model which is kind of--

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:57.916 --> 00:08:02.546 A:middle
And I have this rich delegate
model which is kind of--

00:08:03.306 --> 00:08:04.586 A:middle
weird way of saying this,

00:08:05.646 --> 00:08:07.726 A:middle
but NSURLConnection had some
asynchronous convenience

00:08:07.726 --> 00:08:09.756 A:middle
routines, but the
problem with that is

00:08:09.756 --> 00:08:12.066 A:middle
that they wouldn't
use any delegates.

00:08:12.146 --> 00:08:14.796 A:middle
So either the asynchronous
routine would work

00:08:14.796 --> 00:08:17.226 A:middle
or it would fail, now you
can have a hybrid approach

00:08:17.226 --> 00:08:18.966 A:middle
where there is an asynchronous
convenience routine,

00:08:19.496 --> 00:08:23.186 A:middle
but it can also use your
delegate to do auth.

00:08:24.696 --> 00:08:27.946 A:middle
Session gives you uploads and
downloads to the filesystem,

00:08:27.946 --> 00:08:30.686 A:middle
that's sort of the preferred
way to do uploads and downloads.

00:08:32.596 --> 00:08:34.726 A:middle
There's sort of a
policy shift in Session

00:08:34.726 --> 00:08:38.986 A:middle
in that the configuration
goes in via Session instead

00:08:38.986 --> 00:08:44.155 A:middle
of NSURLRequest and we try and
separate the body of a request,

00:08:44.155 --> 00:08:46.136 A:middle
that is if you're doing
a post of an image,

00:08:46.546 --> 00:08:48.536 A:middle
from the request
envelope itself,

00:08:48.536 --> 00:08:51.186 A:middle
it's sort of like you don't
want to have a post star,

00:08:51.226 --> 00:08:52.026 A:middle
you want to have an envelope.

00:08:53.566 --> 00:08:56.526 A:middle
We've always had the separation
of that response meta data

00:08:57.386 --> 00:08:59.326 A:middle
from the actual payload itself.

00:08:59.326 --> 00:09:02.696 A:middle
So just trying to make this
API consistent between request,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:59.326 --> 00:09:02.696 A:middle
So just trying to make this
API consistent between request,

00:09:02.696 --> 00:09:04.046 A:middle
response, payload, payload.

00:09:06.046 --> 00:09:07.586 A:middle
And NSURLSession
gives you access

00:09:07.586 --> 00:09:09.316 A:middle
to out-of-process
uploads and downloads.

00:09:10.436 --> 00:09:12.216 A:middle
The nice thing about
that is it's just a

00:09:12.216 --> 00:09:13.376 A:middle
configuration option.

00:09:13.376 --> 00:09:16.526 A:middle
When you create a session, you
specify, "Well, I want request

00:09:16.526 --> 00:09:18.846 A:middle
that go into the session,
could be done on a background."

00:09:19.386 --> 00:09:22.676 A:middle
What it allows us
to do though is

00:09:22.676 --> 00:09:25.306 A:middle
when your process is no longer
running, it's been suspended,

00:09:26.546 --> 00:09:30.296 A:middle
we can continue your download in
the background taking advantage

00:09:30.296 --> 00:09:33.636 A:middle
of everything we've learned
about the user's network use

00:09:33.636 --> 00:09:35.326 A:middle
and their battery life.

00:09:36.606 --> 00:09:42.226 A:middle
Using UIKit on iOS 7, we
key in, we take advantage

00:09:42.226 --> 00:09:44.006 A:middle
of the new multitasking APIs

00:09:44.566 --> 00:09:49.656 A:middle
so that your application can
have updated its interface

00:09:49.656 --> 00:09:52.076 A:middle
and provide a better
experience for the user.

00:09:52.076 --> 00:09:53.646 A:middle
You're going to download
your content

00:09:53.646 --> 00:09:56.946 A:middle
and have it available in the UI.

00:09:56.946 --> 00:09:59.516 A:middle
So this looks like,
well, it's a big object,

00:09:59.516 --> 00:10:01.436 A:middle
a big square object
called NSURLSession.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:59.516 --> 00:10:01.436 A:middle
a big square object
called NSURLSession.

00:10:02.026 --> 00:10:04.176 A:middle
And you create a session
with a configuration object.

00:10:04.176 --> 00:10:07.956 A:middle
This is where you're going
to specify any HTTP options

00:10:08.076 --> 00:10:10.366 A:middle
and the various storage objects.

00:10:10.506 --> 00:10:12.566 A:middle
And you create a
session with a delegate.

00:10:13.316 --> 00:10:16.946 A:middle
Delegate gets called on a
sort of per request basis.

00:10:17.506 --> 00:10:19.996 A:middle
When you throw a request into a
session, you get a response out

00:10:19.996 --> 00:10:24.186 A:middle
and you keep using the
same session over and over.

00:10:24.386 --> 00:10:29.486 A:middle
So as Session is an
API, there are a bunch

00:10:29.486 --> 00:10:31.346 A:middle
of additional classes
you need to know about,

00:10:33.046 --> 00:10:35.146 A:middle
not nearly a bunch
but some more.

00:10:35.476 --> 00:10:38.396 A:middle
OK, so the first one is
the configuration object.

00:10:38.396 --> 00:10:40.486 A:middle
This is basically a
properties dictionary

00:10:41.086 --> 00:10:47.286 A:middle
of how you want the session
to behave, the task object

00:10:47.436 --> 00:10:50.046 A:middle
which really is the
replacement for connection.

00:10:50.366 --> 00:10:53.776 A:middle
So you can think about
Session is this larger ball,

00:10:53.776 --> 00:10:59.166 A:middle
and Connection goes away and
these taske objects get created

00:10:59.166 --> 00:11:00.326 A:middle
on a per request basis.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:59.166 --> 00:11:00.326 A:middle
on a per request basis.

00:11:01.746 --> 00:11:03.886 A:middle
There is a delegate
protocol, the delegate object,

00:11:04.066 --> 00:11:05.956 A:middle
that you're going to
create to bind your session,

00:11:05.956 --> 00:11:07.556 A:middle
and then the session
object itself

00:11:07.636 --> 00:11:09.856 A:middle
which is a factory
for creating tasks.

00:11:10.726 --> 00:11:13.326 A:middle
You always create
one task per request.

00:11:14.716 --> 00:11:18.846 A:middle
So this is a classic
NSURLConnection example.

00:11:18.846 --> 00:11:21.736 A:middle
You create a delegate
object and a URL.

00:11:21.736 --> 00:11:25.466 A:middle
I keep using
setAllowsCellularAccess during

00:11:25.466 --> 00:11:27.386 A:middle
this talk as an example
of a property

00:11:27.386 --> 00:11:28.996 A:middle
that you might tweak
on a request.

00:11:29.066 --> 00:11:32.196 A:middle
So in this case, you
create an NSURLRequest

00:11:32.196 --> 00:11:34.036 A:middle
and then you modify
the request to say,

00:11:34.036 --> 00:11:36.006 A:middle
"I don't want this request
to go over cellular."

00:11:37.156 --> 00:11:40.026 A:middle
You create an NSURLConnection
object using the class method

00:11:40.026 --> 00:11:42.606 A:middle
connectionWithRequest, you
bind it to your delegate.

00:11:42.606 --> 00:11:45.726 A:middle
Your delegate then gets called
with didReceiveResponse,

00:11:45.776 --> 00:11:48.556 A:middle
didReceiveData, didFinishLoading
referencing this

00:11:48.596 --> 00:11:49.326 A:middle
connection object.

00:11:51.026 --> 00:11:54.816 A:middle
Now in NSURLSession, it's
pretty much the same,

00:11:54.816 --> 00:11:57.636 A:middle
but there is more configuration
upfront but less work later on.

00:11:58.346 --> 00:12:00.356 A:middle
You create a delegate conforming

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:58.346 --> 00:12:00.356 A:middle
You create a delegate conforming

00:12:00.576 --> 00:12:02.086 A:middle
to the session delegate
protocol.

00:12:02.456 --> 00:12:05.396 A:middle
You create a configuration
object.

00:12:05.886 --> 00:12:08.226 A:middle
There is a bunch
of class methods

00:12:08.226 --> 00:12:10.016 A:middle
for creating configuration
objects based

00:12:10.526 --> 00:12:12.416 A:middle
on what you're going to
try and do with them.

00:12:12.416 --> 00:12:14.806 A:middle
In this case the
defaultSessionConfiguration

00:12:14.806 --> 00:12:18.306 A:middle
object actually gives
you the same sort

00:12:18.306 --> 00:12:21.036 A:middle
of configuration options that
NSURLConnection would see.

00:12:21.126 --> 00:12:24.576 A:middle
So if you had created this task
with an NSURLConnection instead,

00:12:24.576 --> 00:12:26.486 A:middle
you would have sort
of the same behaviors.

00:12:27.376 --> 00:12:29.736 A:middle
But instead of modifying the
request to say AllowCellular,

00:12:30.256 --> 00:12:32.586 A:middle
all the requests that
go into this session

00:12:32.586 --> 00:12:37.226 A:middle
that I create are going
to not use cellular.

00:12:38.156 --> 00:12:40.466 A:middle
So you create a session, you
bind it through a delegate

00:12:40.466 --> 00:12:43.726 A:middle
and you give it a queue
where the messages

00:12:43.726 --> 00:12:45.186 A:middle
for your delegate are
going to be received.

00:12:45.476 --> 00:12:47.046 A:middle
You don't want to
block in your queue.

00:12:47.046 --> 00:12:51.806 A:middle
All the callouts to you
are sort of asynchronous

00:12:51.806 --> 00:12:53.036 A:middle
or they're intended
to be asynchronous

00:12:53.036 --> 00:12:55.236 A:middle
or either informational or
they'll be a completion handler.

00:12:55.606 --> 00:12:58.556 A:middle
If you use the session
once you get all set up,

00:12:58.556 --> 00:13:01.536 A:middle
you create a URL, and
then you can use a

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:58.556 --> 00:13:01.536 A:middle
you create a URL, and
then you can use a

00:13:01.536 --> 00:13:03.616 A:middle
dataTaskWithHTTPGetRequest
which returns

00:13:03.926 --> 00:13:08.696 A:middle
to you an NSURLSession
data task object.

00:13:08.856 --> 00:13:10.466 A:middle
Actually, I want to talk
about one more thing here.

00:13:10.686 --> 00:13:16.946 A:middle
The data task object I've
mentioned NSURLSession task,

00:13:16.946 --> 00:13:19.596 A:middle
NSURLSessionDataTask is a
subclass of NSURLSession task.

00:13:19.596 --> 00:13:22.906 A:middle
And I'm going to talk about
that a little bit more, sorry.

00:13:23.826 --> 00:13:25.726 A:middle
Right, so
NSURLSessionConfiguration.

00:13:26.986 --> 00:13:29.816 A:middle
NSURLRequest did not have a
lot of configuration options.

00:13:29.816 --> 00:13:33.246 A:middle
So now we're adding
support to subclass

00:13:33.246 --> 00:13:35.856 A:middle
and set your own private cache
both using credential storage.

00:13:36.816 --> 00:13:40.656 A:middle
We maintain the ability
to set the cell usage flag

00:13:40.656 --> 00:13:42.936 A:middle
and network service
type from NSURLRequest.

00:13:43.826 --> 00:13:46.126 A:middle
We give users the ability
to tweak the maximum number

00:13:46.126 --> 00:13:47.326 A:middle
of connections through a host.

00:13:47.326 --> 00:13:51.296 A:middle
In NSURLConnection, behind the
scenes there is this global pool

00:13:51.296 --> 00:13:55.076 A:middle
of sockets that have been opened
and we come up with some number

00:13:55.076 --> 00:13:57.696 A:middle
of connections based on
internet standard usage

00:13:58.466 --> 00:14:00.546 A:middle
for how many connections
we want to open to a host.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:58.466 --> 00:14:00.546 A:middle
for how many connections
we want to open to a host.

00:14:00.546 --> 00:14:02.286 A:middle
But what we've heard is that
people want to tweak that.

00:14:02.286 --> 00:14:05.296 A:middle
They say "I really only want
one connection to a host ever.

00:14:05.656 --> 00:14:07.366 A:middle
I'd like all request to go
up in this one connection."

00:14:07.366 --> 00:14:08.176 A:middle
So now you can do that.

00:14:09.706 --> 00:14:13.176 A:middle
We have the resource
and network timeouts.

00:14:13.176 --> 00:14:17.346 A:middle
This is nice because while
NSURLRequest has an implicit

00:14:17.346 --> 00:14:20.906 A:middle
timeout when you create one,
or you can set an explicit one.

00:14:21.516 --> 00:14:23.696 A:middle
That timeout is for
network transfers.

00:14:24.086 --> 00:14:28.406 A:middle
If you're getting a long-lived
request and maybe you want

00:14:28.646 --> 00:14:32.326 A:middle
to get a request, you want to
get the bytes out of request,

00:14:32.476 --> 00:14:34.846 A:middle
but only one byte is
coming in at a time,

00:14:35.416 --> 00:14:38.896 A:middle
if you don't get any bytes
for that network timeout,

00:14:39.046 --> 00:14:40.166 A:middle
then the request times out.

00:14:41.496 --> 00:14:44.196 A:middle
So you can imagine doing a
get where it might take a week

00:14:44.276 --> 00:14:45.706 A:middle
to come in and never timing out.

00:14:46.126 --> 00:14:48.466 A:middle
So there's a new timeout,
the resource time out.

00:14:48.466 --> 00:14:51.516 A:middle
If I can't get this entire
request within this timeout,

00:14:51.966 --> 00:14:53.116 A:middle
then I want it to cancel.

00:14:53.206 --> 00:14:54.516 A:middle
This is particularly important

00:14:54.516 --> 00:14:56.106 A:middle
if you create a background
transfer.

00:14:56.506 --> 00:14:58.686 A:middle
I want this file,
but if I can't get it

00:14:58.686 --> 00:15:00.026 A:middle
in three days, forget about it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:58.686 --> 00:15:00.026 A:middle
in three days, forget about it.

00:15:00.026 --> 00:15:02.506 A:middle
I'd rather hear that it failed.

00:15:02.506 --> 00:15:06.546 A:middle
You can now set the minimum and
maximum TLS levels to, you know,

00:15:06.576 --> 00:15:09.836 A:middle
ratchet down security or open it
up for your particular server.

00:15:11.596 --> 00:15:14.736 A:middle
You have access to the HTTP
proxy dictionary directly

00:15:14.736 --> 00:15:15.996 A:middle
on a per session basis.

00:15:15.996 --> 00:15:18.666 A:middle
This is the same dictionary you
would get from systemconfig,

00:15:19.066 --> 00:15:21.606 A:middle
but now you can modify it if
you had special proxy needs

00:15:21.606 --> 00:15:23.576 A:middle
within your application
and we're going to use

00:15:23.576 --> 00:15:26.316 A:middle
that proxy dictionary
for all requests

00:15:26.356 --> 00:15:27.496 A:middle
that travel through the session.

00:15:28.136 --> 00:15:32.406 A:middle
We have some of the same
options on request as far

00:15:32.406 --> 00:15:34.546 A:middle
as cookie handling is
concerned, whether you want

00:15:34.546 --> 00:15:35.846 A:middle
to apply cookies as they go out,

00:15:36.406 --> 00:15:39.146 A:middle
but you can also specify the
cookie acceptance policy.

00:15:40.056 --> 00:15:44.356 A:middle
HTTP pipelining is something you
can turn on and off at this--

00:15:44.356 --> 00:15:45.436 A:middle
on a per session level.

00:15:45.526 --> 00:15:47.256 A:middle
And you can set additional
headers

00:15:47.256 --> 00:15:48.676 A:middle
that will be applied
to any request.

00:15:48.676 --> 00:15:51.046 A:middle
If a header is already
present, we don't override it.

00:15:51.436 --> 00:15:52.826 A:middle
But if you wanted to
set the user agent

00:15:52.896 --> 00:15:54.636 A:middle
for any outgoing request,
you could do that here.

00:15:56.586 --> 00:16:00.256 A:middle
Lastly, protocol handlers are
kept on a per session basis.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:56.586 --> 00:16:00.256 A:middle
Lastly, protocol handlers are
kept on a per session basis.

00:16:00.416 --> 00:16:02.586 A:middle
There is still the
global protocol list.

00:16:03.516 --> 00:16:05.626 A:middle
But if you have your own
protocol, it would be better

00:16:05.626 --> 00:16:08.146 A:middle
to bind it to a particular
session and use that session

00:16:08.146 --> 00:16:09.526 A:middle
and expect to get that protocol.

00:16:10.386 --> 00:16:12.856 A:middle
So there are some
factory constructors

00:16:12.856 --> 00:16:14.316 A:middle
for creating sessions.

00:16:14.386 --> 00:16:18.076 A:middle
The default configuration sort
of captures the global state

00:16:18.076 --> 00:16:19.356 A:middle
that NSURLConnection sees.

00:16:20.206 --> 00:16:24.116 A:middle
There is a factory to create an
ephemeral session configuration.

00:16:24.496 --> 00:16:28.586 A:middle
This is basically the same as
a default configuration except

00:16:28.586 --> 00:16:33.276 A:middle
that it initializes the storage
objects to be in-memory only.

00:16:33.996 --> 00:16:36.576 A:middle
This is how you would implement
private browsing for instance.

00:16:37.096 --> 00:16:39.876 A:middle
And there's the background
session configuration

00:16:40.266 --> 00:16:41.966 A:middle
which creates a configuration
object

00:16:42.536 --> 00:16:44.106 A:middle
that references an identifier.

00:16:44.106 --> 00:16:47.286 A:middle
That identifier is what you
use to reconnect this session

00:16:47.756 --> 00:16:48.556 A:middle
to the background work.

00:16:49.786 --> 00:16:51.666 A:middle
Configuration objects
are always mutable

00:16:52.356 --> 00:16:54.556 A:middle
and they're copied
whenever they get used.

00:16:54.556 --> 00:16:55.696 A:middle
So when you create
a session with one,

00:16:55.696 --> 00:16:56.936 A:middle
it'll create a copy of that.

00:16:57.726 --> 00:16:59.636 A:middle
And while you can get to
the configuration inside

00:16:59.636 --> 00:17:01.626 A:middle
of a session, you
can't modify it.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:59.636 --> 00:17:01.626 A:middle
of a session, you
can't modify it.

00:17:02.936 --> 00:17:06.056 A:middle
So the task object,
this is the thing

00:17:06.056 --> 00:17:09.076 A:middle
that actually replaces
NSURLConnection in the class.

00:17:09.346 --> 00:17:14.146 A:middle
And it represents, you know,
the state of a loading resource.

00:17:14.736 --> 00:17:16.435 A:middle
When you look at it in the
header, the immediate thing

00:17:16.435 --> 00:17:17.986 A:middle
that comes out is that it
has a lot of properties.

00:17:18.236 --> 00:17:21.796 A:middle
The properties that previously
had been reported via delegates

00:17:21.796 --> 00:17:24.846 A:middle
are also available through
the task object itself.

00:17:25.516 --> 00:17:28.006 A:middle
So you can look at a
task object and find

00:17:28.006 --> 00:17:29.346 A:middle
out how many bytes
have been transferred,

00:17:29.346 --> 00:17:30.936 A:middle
how many bytes are
expected to be transferred.

00:17:32.016 --> 00:17:35.336 A:middle
It offers the same
cancel, suspend and resume

00:17:35.336 --> 00:17:37.246 A:middle
that NSURLConnection does.

00:17:38.356 --> 00:17:43.766 A:middle
There are two subclasses for
data task and upload task.

00:17:44.826 --> 00:17:47.726 A:middle
This is really done just
as sort of syntactic sugar

00:17:47.726 --> 00:17:51.776 A:middle
so that we understand that
there are different types

00:17:51.776 --> 00:17:52.906 A:middle
of work that's going on.

00:17:53.146 --> 00:17:58.506 A:middle
And in particular, you can't
schedule background data task.

00:17:58.506 --> 00:18:02.846 A:middle
You can schedule background
upload or download tasks.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.506 --> 00:18:02.846 A:middle
You can schedule background
upload or download tasks.

00:18:03.536 --> 00:18:05.686 A:middle
Download tasks don't
really offer anything

00:18:05.686 --> 00:18:07.476 A:middle
over the base class task except

00:18:07.476 --> 00:18:09.226 A:middle
for this
cancelByProducingResumeData.

00:18:09.226 --> 00:18:10.536 A:middle
If somebody hits
pause in the UI,

00:18:10.536 --> 00:18:13.306 A:middle
you want to stop the
background transfer

00:18:13.556 --> 00:18:16.266 A:middle
or foreground transfer
for that matter.

00:18:16.586 --> 00:18:17.936 A:middle
You're given this
resume data blob.

00:18:18.616 --> 00:18:24.416 A:middle
Later on, your app can go ahead
and create a download and bind

00:18:24.416 --> 00:18:27.486 A:middle
to this resume data and we'll
continue where we left off.

00:18:27.986 --> 00:18:33.596 A:middle
The delegate that you create the
session with has messages keyed

00:18:33.596 --> 00:18:35.426 A:middle
to the specific task type.

00:18:35.896 --> 00:18:38.446 A:middle
So all tasks can finish loading,

00:18:39.066 --> 00:18:41.446 A:middle
but only data tasks
receive incremental data,

00:18:41.966 --> 00:18:43.576 A:middle
and only download tasks receive

00:18:43.576 --> 00:18:45.846 A:middle
that final URL where
the file is.

00:18:47.596 --> 00:18:50.006 A:middle
So the class hierarchy,
you know, looks like this.

00:18:50.006 --> 00:18:52.576 A:middle
You've got a session task
with these methods on it.

00:18:52.576 --> 00:18:54.826 A:middle
I think there's a status method,
but there are also properties

00:18:54.826 --> 00:18:56.296 A:middle
in there that you can look at.

00:18:57.356 --> 00:18:59.376 A:middle
DataTask is a subclass
of SessionTask

00:18:59.536 --> 00:19:03.216 A:middle
and UploadTask is a
subclass of DataTask.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:59.536 --> 00:19:03.216 A:middle
and UploadTask is a
subclass of DataTask.

00:19:04.286 --> 00:19:06.616 A:middle
Any task can have
an upload payload,

00:19:06.656 --> 00:19:09.106 A:middle
including a download task
which is weird when you think

00:19:09.106 --> 00:19:09.926 A:middle
about it but it's true.

00:19:09.926 --> 00:19:14.206 A:middle
You can do a GET for a resource
and have it have body data.

00:19:14.206 --> 00:19:15.646 A:middle
It's not my protocol.

00:19:15.646 --> 00:19:16.496 A:middle
[ laughter ]

00:19:16.496 --> 00:19:21.576 A:middle
So the DownloadTask subclass
also has this extra method

00:19:21.676 --> 00:19:23.076 A:middle
cancelByProducingResumeData.

00:19:25.116 --> 00:19:27.516 A:middle
The delegate objects that
you create your session with,

00:19:28.956 --> 00:19:30.586 A:middle
you create a single
delegate object, right?

00:19:30.586 --> 00:19:33.576 A:middle
So each session has one
pointer to your delegate object.

00:19:34.226 --> 00:19:37.296 A:middle
There are-- different
task types are broken

00:19:37.296 --> 00:19:39.186 A:middle
out into different protocols,

00:19:39.246 --> 00:19:41.946 A:middle
but you can just implement
them all within one class.

00:19:43.936 --> 00:19:46.916 A:middle
The delegate itself is strongly
referenced by the session.

00:19:47.266 --> 00:19:49.616 A:middle
And in order to break
that cycle,

00:19:49.696 --> 00:19:51.066 A:middle
you have to invalidate
a session.

00:19:51.966 --> 00:19:53.226 A:middle
When you invalidate a session,

00:19:54.306 --> 00:19:57.616 A:middle
all the work inside the session
gets canceled or finished,

00:19:58.076 --> 00:19:59.886 A:middle
and then the session
did finish--

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:00.056 --> 00:20:02.066 A:middle
or sorry the session
did invalidate,

00:20:02.636 --> 00:20:03.786 A:middle
delegate method gets called.

00:20:05.016 --> 00:20:06.576 A:middle
At that point we
release your delegate.

00:20:07.996 --> 00:20:10.266 A:middle
Now a Delegate message
may block loading.

00:20:10.266 --> 00:20:12.816 A:middle
Some of them are informational
like didReceiveData,

00:20:13.446 --> 00:20:15.136 A:middle
gives you a data blob and
then goes back to work.

00:20:16.366 --> 00:20:20.126 A:middle
Some of them, like
didReceiveResponse,

00:20:20.586 --> 00:20:21.996 A:middle
require you to return something.

00:20:22.956 --> 00:20:26.096 A:middle
In NSURLConnection, you had to
return something immediately,

00:20:26.866 --> 00:20:28.806 A:middle
but in the SessionDelegate
model,

00:20:29.336 --> 00:20:30.566 A:middle
you're given a completion
handler.

00:20:30.856 --> 00:20:33.086 A:middle
Then you invoke that completion
handler to continue the load.

00:20:33.336 --> 00:20:37.336 A:middle
So it's OK to schedule a session
on say the main queue as long

00:20:37.336 --> 00:20:39.476 A:middle
as you know that the
work you need to do needs

00:20:39.476 --> 00:20:41.726 A:middle
to be done via this
completion handler.

00:20:43.916 --> 00:20:47.076 A:middle
SessionDelegate then is
sort of the overarching--

00:20:47.236 --> 00:20:48.786 A:middle
a session should implement this.

00:20:50.216 --> 00:20:51.486 A:middle
I mentioned way earlier

00:20:51.556 --> 00:20:54.186 A:middle
that there's an authentication
challenge specific

00:20:54.546 --> 00:20:57.306 A:middle
to connection types
as opposed to request.

00:20:57.576 --> 00:21:00.366 A:middle
Those come in through the URL
session didReceiveAuthentication

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:57.576 --> 00:21:00.366 A:middle
Those come in through the URL
session didReceiveAuthentication

00:21:00.366 --> 00:21:03.566 A:middle
Challenge:completionHandler
delegate method.

00:21:03.756 --> 00:21:07.536 A:middle
This is going to be for
connection-based auth

00:21:07.536 --> 00:21:11.536 A:middle
like in NTLM also for SSL auth

00:21:11.706 --> 00:21:13.606 A:middle
like here's the server
certificate,

00:21:13.606 --> 00:21:16.036 A:middle
or if the server requires
a certificate from you.

00:21:17.086 --> 00:21:19.526 A:middle
We implicitly handle
Kerberos on both iOS 7

00:21:19.976 --> 00:21:21.146 A:middle
and with OS X Mavericks.

00:21:21.146 --> 00:21:23.296 A:middle
So you should be aware
that it's happening

00:21:23.626 --> 00:21:25.496 A:middle
that you might have a Kerberos
authenticated connection,

00:21:26.116 --> 00:21:29.046 A:middle
but you actually won't hear
about it through this delegate.

00:21:30.536 --> 00:21:32.306 A:middle
The other delegate
method that we care

00:21:32.306 --> 00:21:33.876 A:middle
about is
didBecomeInvalidWithError

00:21:33.876 --> 00:21:38.506 A:middle
and this is where-- when
you've invalidated the session,

00:21:38.506 --> 00:21:40.746 A:middle
this is the method that gets
called before your delegate

00:21:41.376 --> 00:21:42.676 A:middle
is released.

00:21:43.786 --> 00:21:48.326 A:middle
So data delegates are
interesting because this is

00:21:48.396 --> 00:21:50.006 A:middle
for doing incremental
loading of data.

00:21:51.896 --> 00:21:53.696 A:middle
These are basically-- some
of these are optional, right?

00:21:53.746 --> 00:21:56.876 A:middle
So if you don't care about
redirections, you don't have

00:21:56.876 --> 00:21:59.266 A:middle
to implement
willPerformHTTPRedirection.

00:21:59.556 --> 00:22:02.726 A:middle
If you care whether you want
to do something different

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.556 --> 00:22:02.726 A:middle
If you care whether you want
to do something different

00:22:02.726 --> 00:22:05.816 A:middle
for redirection, then
you implement this

00:22:05.976 --> 00:22:07.156 A:middle
and it gives you
the new request.

00:22:07.256 --> 00:22:08.836 A:middle
This is where you're
going to go to

00:22:08.836 --> 00:22:11.996 A:middle
and call the completion handler
with either that new request,

00:22:12.556 --> 00:22:15.006 A:middle
the request where you'd
rather it go to or nil.

00:22:15.006 --> 00:22:18.496 A:middle
If you pass nil, then
we treat the request--

00:22:19.396 --> 00:22:22.916 A:middle
sorry, we treat the response
that specifies the redirection

00:22:23.416 --> 00:22:24.606 A:middle
as the data you're getting.

00:22:25.616 --> 00:22:28.006 A:middle
Sometimes you want to
do an HTTP Get request,

00:22:28.156 --> 00:22:31.636 A:middle
you get a redirection response,
but you'd rather have the body

00:22:31.636 --> 00:22:33.526 A:middle
of the response rather
than the new location,

00:22:33.526 --> 00:22:35.186 A:middle
so that's how you
would implement that.

00:22:36.536 --> 00:22:38.886 A:middle
When you have a request based
authentication challenge,

00:22:38.946 --> 00:22:40.936 A:middle
they come in through the
didReceiveAuthentication

00:22:40.936 --> 00:22:42.936 A:middle
Challenge, the task
didReceiveAuthentication

00:22:42.936 --> 00:22:43.306 A:middle
Challenge.

00:22:44.216 --> 00:22:47.406 A:middle
This is where you create a
credential for basic digest auth

00:22:47.976 --> 00:22:50.636 A:middle
or any sort of proxy auth
on a per request basis.

00:22:50.996 --> 00:22:56.856 A:middle
As the request is uploading
data through a server via POST,

00:22:57.966 --> 00:23:00.986 A:middle
we periodically call this
didSendBodyData delegate method

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:57.966 --> 00:23:00.986 A:middle
we periodically call this
didSendBodyData delegate method

00:23:01.066 --> 00:23:01.856 A:middle
if you implement it.

00:23:02.416 --> 00:23:06.986 A:middle
This data is-- the parameters
here are actually mirrored

00:23:06.986 --> 00:23:08.286 A:middle
in the task object itself.

00:23:08.286 --> 00:23:09.736 A:middle
So if you look at
the task object,

00:23:09.736 --> 00:23:11.366 A:middle
you'll see these
things being modified,

00:23:11.366 --> 00:23:14.126 A:middle
and you don't necessarily
need to implement this.

00:23:14.956 --> 00:23:18.226 A:middle
needsNewBodyStream
needs some explanation.

00:23:19.036 --> 00:23:22.136 A:middle
This was added to
NSURLConnection because when--

00:23:22.136 --> 00:23:24.576 A:middle
it is a carryover from
NSURLConnection delegate,

00:23:25.176 --> 00:23:26.936 A:middle
because when we're
doing an HTTP post,

00:23:27.196 --> 00:23:29.996 A:middle
sometimes the server is going
to come back with a challenge

00:23:29.996 --> 00:23:33.226 A:middle
or some sort of server error
that we can recover from.

00:23:33.226 --> 00:23:35.496 A:middle
We could resend this request.

00:23:35.776 --> 00:23:40.036 A:middle
But because that-- because
streams are not rewindable,

00:23:40.536 --> 00:23:42.616 A:middle
we want it to have the
data to send them again.

00:23:42.746 --> 00:23:45.266 A:middle
So we will call your
needsNewBodyStream

00:23:45.266 --> 00:23:48.486 A:middle
and your needsNewBodyStream
delegate to ask for a new stream

00:23:48.676 --> 00:23:49.936 A:middle
so we could resend the request.

00:23:50.096 --> 00:23:54.056 A:middle
If you didn't implement this,
then the request would fail

00:23:54.286 --> 00:23:55.716 A:middle
and you'd have a confused user.

00:23:56.056 --> 00:23:58.296 A:middle
The problem is, you know,

00:23:58.696 --> 00:24:02.606 A:middle
when you're doing your testing
in-house, this never gets called

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.696 --> 00:24:02.606 A:middle
when you're doing your testing
in-house, this never gets called

00:24:02.606 --> 00:24:03.896 A:middle
because everything
is working correctly.

00:24:04.506 --> 00:24:05.956 A:middle
But out in the field, you know,

00:24:05.956 --> 00:24:08.086 A:middle
there's one in a million
chance this is going to happen,

00:24:08.516 --> 00:24:11.016 A:middle
but one in a million chances
happen 9 times out of 10,

00:24:11.536 --> 00:24:14.036 A:middle
and so your users
will be confused.

00:24:14.036 --> 00:24:15.286 A:middle
[ laughter ]

00:24:15.286 --> 00:24:17.186 A:middle
needsNewBodyStream
must be implemented

00:24:17.436 --> 00:24:20.246 A:middle
if the upload you're
doing is from a stream.

00:24:21.376 --> 00:24:24.546 A:middle
Sessions lets you create and
upload from a file though.

00:24:24.936 --> 00:24:29.056 A:middle
So if you are implementing
uploads via the filesystem,

00:24:29.336 --> 00:24:31.116 A:middle
you don't need to
implement needsNewBodyStream.

00:24:31.696 --> 00:24:34.506 A:middle
If you're doing an
upload via a stream,

00:24:34.686 --> 00:24:36.826 A:middle
we require that you
implement it.

00:24:38.156 --> 00:24:40.596 A:middle
Lastly, all tasks
finish with error.

00:24:40.956 --> 00:24:43.436 A:middle
NSURLConnection had
didFinishLoading

00:24:43.786 --> 00:24:44.896 A:middle
and didFailWithError.

00:24:46.566 --> 00:24:48.866 A:middle
NSURLSession just has
didCompleteWithError,

00:24:48.866 --> 00:24:51.126 A:middle
error will be nil if
there was no error.

00:24:52.466 --> 00:24:55.336 A:middle
Note that the error that you're
sent here is a transmission

00:24:55.336 --> 00:24:56.616 A:middle
error, not a server error.

00:24:56.646 --> 00:24:58.906 A:middle
If the server responded
with 404,

00:24:59.306 --> 00:25:01.706 A:middle
as far as we're concerned
we did our job,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.306 --> 00:25:01.706 A:middle
as far as we're concerned
we did our job,

00:25:01.706 --> 00:25:04.086 A:middle
we sent you request
and got a response.

00:25:04.586 --> 00:25:06.406 A:middle
The only errors you're
going to get here are errors

00:25:06.406 --> 00:25:08.946 A:middle
that are specific to, "We
couldn't find the host,"

00:25:09.286 --> 00:25:12.366 A:middle
or "the connection was lost,"
or some horrible thing happened.

00:25:13.356 --> 00:25:17.146 A:middle
Data tasks have a couple

00:25:17.266 --> 00:25:21.776 A:middle
of specific data-related
delegate messages.

00:25:22.586 --> 00:25:23.996 A:middle
First one is didReceiveResponse.

00:25:23.996 --> 00:25:27.176 A:middle
Now, this is interesting because
when the server gives you a

00:25:27.346 --> 00:25:29.346 A:middle
header back and it
starts sending body data,

00:25:30.406 --> 00:25:34.336 A:middle
you might decide that the
response you got doesn't need

00:25:34.336 --> 00:25:36.256 A:middle
to go to memory, you just
want it to go to disk.

00:25:37.386 --> 00:25:39.716 A:middle
You can use didReceiveResponse
now to specify

00:25:39.716 --> 00:25:42.606 A:middle
that this data task that
I'm about to get data for,

00:25:42.996 --> 00:25:44.736 A:middle
I'd rather have the data
go directly to disk.

00:25:45.176 --> 00:25:46.906 A:middle
So you call the completion
handler

00:25:46.906 --> 00:25:49.126 A:middle
with a disposition
saying "become download.

00:25:49.126 --> 00:25:51.526 A:middle
" And the next delegate
message gets called to say,

00:25:52.236 --> 00:25:54.096 A:middle
"Your data task is now dead.

00:25:54.096 --> 00:25:55.496 A:middle
Here's a download task instead.

00:25:55.496 --> 00:25:58.216 A:middle
" And all the flow goes
through that download task.

00:25:59.106 --> 00:26:02.886 A:middle
As your resource is being loaded
from the network, if you kept it

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:59.106 --> 00:26:02.886 A:middle
As your resource is being loaded
from the network, if you kept it

00:26:02.886 --> 00:26:05.456 A:middle
as a data task, you'll
receive zero

00:26:05.456 --> 00:26:07.686 A:middle
and more didReceiveData
messages.

00:26:08.416 --> 00:26:12.556 A:middle
The NSData objects that you
get behind the scenes may be

00:26:12.556 --> 00:26:15.186 A:middle
stitched together from
many NSData objects.

00:26:15.926 --> 00:26:18.566 A:middle
So in the past, you would
just have gone [NSData bytes]

00:26:19.226 --> 00:26:22.106 A:middle
or bytePointer or whatever.

00:26:22.106 --> 00:26:22.706 A:middle
We would encourage you

00:26:22.706 --> 00:26:25.706 A:middle
to instead use the
enumerateByteRangesUsingBlock

00:26:25.706 --> 00:26:29.976 A:middle
API because we could give
you now a 4 Meg buffer.

00:26:29.976 --> 00:26:31.416 A:middle
We just downloaded your 4 Meg.

00:26:31.796 --> 00:26:35.136 A:middle
Internally, maybe that's cut
up into 50 different segments

00:26:35.536 --> 00:26:37.646 A:middle
and if you just ask for the
byte pointer, then we have

00:26:37.646 --> 00:26:40.356 A:middle
to flatten all that, and
that's not good for anyone.

00:26:41.376 --> 00:26:45.946 A:middle
Lastly, data task caching
- only task can be cached.

00:26:45.946 --> 00:26:49.226 A:middle
If you don't implement
willCacheResponse then we go

00:26:49.226 --> 00:26:52.766 A:middle
ahead and cache for you all
things being considered,

00:26:52.766 --> 00:26:54.646 A:middle
whether caching is
enabled in your session

00:26:54.646 --> 00:26:57.016 A:middle
and whether the resource
is cacheable

00:26:57.016 --> 00:26:58.736 A:middle
and whether the server
said to cache.

00:26:59.766 --> 00:27:01.986 A:middle
Note that this won't
necessarily get called

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.766 --> 00:27:01.986 A:middle
Note that this won't
necessarily get called

00:27:01.986 --> 00:27:04.086 A:middle
because there could
be something--

00:27:04.266 --> 00:27:06.286 A:middle
maybe the resource is too
big to fit in the cache

00:27:06.286 --> 00:27:08.776 A:middle
or maybe the server didn't
want it to be cached.

00:27:08.776 --> 00:27:11.336 A:middle
So we won't always call
your willCacheResponse.

00:27:11.716 --> 00:27:14.526 A:middle
So really, the only reason to
implement it is to say, "No,

00:27:14.526 --> 00:27:18.216 A:middle
I don't want to cache this
particular response type,"

00:27:18.426 --> 00:27:21.276 A:middle
or if you want to modify the
user info dictionary associated

00:27:21.276 --> 00:27:22.646 A:middle
with the cache response.

00:27:23.796 --> 00:27:29.406 A:middle
Download tasks always
download to a file.

00:27:29.406 --> 00:27:30.706 A:middle
We create the file for you.

00:27:30.986 --> 00:27:32.156 A:middle
We put the bytes into it

00:27:32.156 --> 00:27:33.956 A:middle
and then once the
download is complete,

00:27:34.326 --> 00:27:36.146 A:middle
we call
didFinishDownloadingToURL.

00:27:36.146 --> 00:27:38.926 A:middle
We give you a reference to a
file URL which you then need

00:27:38.926 --> 00:27:40.906 A:middle
to copy or move because
we're going to delete

00:27:40.906 --> 00:27:42.406 A:middle
that file shortly thereafter.

00:27:43.536 --> 00:27:47.066 A:middle
As that file is being
downloaded, we give you access

00:27:47.066 --> 00:27:49.696 A:middle
to the number of bytes
that have been transferred

00:27:49.696 --> 00:27:51.646 A:middle
for your progress use.

00:27:52.226 --> 00:27:55.256 A:middle
And if you created your download
task using the resume API,

00:27:56.106 --> 00:27:58.286 A:middle
then we're going to
call didResumeAtOffset.

00:27:59.156 --> 00:28:02.966 A:middle
One thing to note is that the
offset you're given here is the

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:59.156 --> 00:28:02.966 A:middle
One thing to note is that the
offset you're given here is the

00:28:02.966 --> 00:28:07.196 A:middle
real offset at which we
began resuming the download.

00:28:07.726 --> 00:28:10.626 A:middle
We may previously have
said, "We've downloaded 4K,"

00:28:10.626 --> 00:28:11.986 A:middle
but when you get to Resume,

00:28:11.986 --> 00:28:14.276 A:middle
we've decided "We're can
only trust 2K of that.

00:28:14.316 --> 00:28:15.916 A:middle
" So that number
may go backwards

00:28:15.916 --> 00:28:17.146 A:middle
from what you were
previously told.

00:28:17.976 --> 00:28:19.426 A:middle
So the session object itself.

00:28:19.426 --> 00:28:21.756 A:middle
There's a default session
object that you can use

00:28:22.196 --> 00:28:24.816 A:middle
and this shares the same
world as NSURLConnection.

00:28:25.216 --> 00:28:28.746 A:middle
As a matter of fact, the
configuration object inside

00:28:28.746 --> 00:28:32.036 A:middle
of a shared session, if you
look at its Cookie storage,

00:28:32.336 --> 00:28:32.926 A:middle
it's the same

00:28:32.926 --> 00:28:34.836 A:middle
as the NSURLConnection
Shared Cookie storage.

00:28:35.896 --> 00:28:37.866 A:middle
But you're going to create
your own private sessions

00:28:37.866 --> 00:28:39.836 A:middle
with private-- either
private configurations

00:28:40.386 --> 00:28:42.936 A:middle
or using the default
configuration.

00:28:43.136 --> 00:28:44.726 A:middle
But you're going to create
your own session usually.

00:28:46.336 --> 00:28:47.626 A:middle
When you're done
with your session,

00:28:47.626 --> 00:28:48.716 A:middle
you have to invalidate it,

00:28:48.946 --> 00:28:52.526 A:middle
and then that delegate message
didBecomeInvalidWithError is

00:28:52.526 --> 00:28:55.106 A:middle
called and then your
delegate will be released.

00:28:56.126 --> 00:28:58.466 A:middle
Session is the object
that creates data upload

00:28:58.466 --> 00:29:02.836 A:middle
and download tasks, but it also
provides these asynchronous

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:58.466 --> 00:29:02.836 A:middle
and download tasks, but it also
provides these asynchronous

00:29:02.836 --> 00:29:05.146 A:middle
convenience APIs with
a various type of task.

00:29:05.576 --> 00:29:08.506 A:middle
And the nice thing about those
is that they give you access

00:29:08.506 --> 00:29:10.156 A:middle
to your delegates
authentication method.

00:29:10.526 --> 00:29:12.386 A:middle
It also lets you cancel them.

00:29:12.386 --> 00:29:15.706 A:middle
So NSURLConnection send
asynchronous request

00:29:15.706 --> 00:29:16.666 A:middle
as an existing API.

00:29:17.626 --> 00:29:20.586 A:middle
Once you fire that, you
have no control over it.

00:29:20.586 --> 00:29:22.246 A:middle
It's going to finish
or it's going to fail.

00:29:22.706 --> 00:29:25.146 A:middle
But with Session, you're
given a task object back.

00:29:25.516 --> 00:29:26.996 A:middle
You can monitor that task object

00:29:27.126 --> 00:29:29.016 A:middle
and you can cancel
it whenever you want.

00:29:29.546 --> 00:29:34.006 A:middle
So to create a session with
a custom configuration,

00:29:34.346 --> 00:29:36.546 A:middle
in this case, I'm going to
implement private browsing.

00:29:36.936 --> 00:29:42.526 A:middle
So we create a new configuration
object using the ephemeral

00:29:42.526 --> 00:29:44.866 A:middle
configuration delegate
or class method.

00:29:45.766 --> 00:29:48.886 A:middle
We create a session with
that configuration object.

00:29:49.996 --> 00:29:53.106 A:middle
Whatever the URL is, we throw it
into the session with data task,

00:29:53.686 --> 00:29:54.926 A:middle
with an HTTP get request,

00:29:54.926 --> 00:29:57.556 A:middle
in this case I'm using the
asynchronous convenience API

00:29:58.136 --> 00:29:59.596 A:middle
which will invoke my block

00:29:59.596 --> 00:30:01.536 A:middle
with the data once
the data is resolved.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:59.596 --> 00:30:01.536 A:middle
with the data once
the data is resolved.

00:30:03.076 --> 00:30:04.676 A:middle
If I wanted to further
customize this,

00:30:04.726 --> 00:30:07.816 A:middle
I would have added whatever
configuration I wanted on top

00:30:07.816 --> 00:30:10.166 A:middle
of the configuration object
that I created initially.

00:30:10.766 --> 00:30:16.386 A:middle
So to create a DataTask,
it's sort of just

00:30:16.386 --> 00:30:19.086 A:middle
like NSURLConnection, you
throw an NSURLRequest,

00:30:19.086 --> 00:30:21.406 A:middle
they are convenience
APIs for throwing just

00:30:21.406 --> 00:30:23.236 A:middle
for all URLs into it as well.

00:30:23.946 --> 00:30:25.776 A:middle
The convenience API version

00:30:25.776 --> 00:30:28.386 A:middle
of this takes an
additional completion handler

00:30:28.956 --> 00:30:31.426 A:middle
and we are just going to
invoke the completion handler.

00:30:31.426 --> 00:30:33.586 A:middle
We invoke it on the same
queue as your delegate

00:30:33.586 --> 00:30:35.616 A:middle
if you had created the
session with the delegate.

00:30:36.036 --> 00:30:41.786 A:middle
Upload tasks can be
explicitly created from a file

00:30:41.786 --> 00:30:44.546 A:middle
or they can be explicitly
created from a data object

00:30:45.376 --> 00:30:48.016 A:middle
or they can be implicitly
created with a stream.

00:30:48.566 --> 00:30:50.796 A:middle
When you do
uploadTaskWithStreamedRequest,

00:30:51.396 --> 00:30:52.726 A:middle
we take your NSURLRequest

00:30:53.096 --> 00:30:55.626 A:middle
and even though NSURLRequest
has an existing API

00:30:55.626 --> 00:30:59.956 A:middle
for setting a body, if you
throw it in to a session

00:30:59.956 --> 00:31:01.586 A:middle
through
uploadTaskWithStreamedRequest,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:59.956 --> 00:31:01.586 A:middle
through
uploadTaskWithStreamedRequest,

00:31:01.996 --> 00:31:02.786 A:middle
we ignore the body.

00:31:03.666 --> 00:31:06.606 A:middle
We will always call your
needsNewBodyStream method

00:31:06.776 --> 00:31:10.296 A:middle
to get a stream when we need
to trasnfer that request.

00:31:12.416 --> 00:31:15.626 A:middle
There is no convenience routine
for that model of upload task,

00:31:15.626 --> 00:31:17.526 A:middle
but there are convenience
routines for upload

00:31:17.526 --> 00:31:22.066 A:middle
from file or upload from data.

00:31:22.266 --> 00:31:26.486 A:middle
Download tasks are similar, you
create them with an NSURLRequest

00:31:26.656 --> 00:31:30.056 A:middle
which identifies, you know,
whatever resource you want

00:31:30.056 --> 00:31:31.896 A:middle
to get off the network.

00:31:32.226 --> 00:31:33.586 A:middle
Or you create it
with the resume data

00:31:33.586 --> 00:31:36.906 A:middle
that you previously had captured
by cancelling with resume data.

00:31:37.216 --> 00:31:41.856 A:middle
There is a convenience routine
for both of those as well.

00:31:41.856 --> 00:31:45.686 A:middle
It calls this block
with the location

00:31:45.686 --> 00:31:46.836 A:middle
of the file that we downloaded.

00:31:47.186 --> 00:31:49.096 A:middle
Again, you have to
copy or move this file

00:31:49.096 --> 00:31:51.146 A:middle
because we're going
to delete it.

00:31:51.956 --> 00:31:54.856 A:middle
If there was a connection
error during a transfer

00:31:55.596 --> 00:31:57.346 A:middle
and we're going to be
able to resume that,

00:31:57.406 --> 00:32:00.216 A:middle
so let's say your user
walked out of Wi-Fi range

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:57.406 --> 00:32:00.216 A:middle
so let's say your user
walked out of Wi-Fi range

00:32:00.216 --> 00:32:02.506 A:middle
and we lost the connection,
we might return

00:32:02.506 --> 00:32:03.996 A:middle
to you a connection error.

00:32:04.576 --> 00:32:06.196 A:middle
In the user info of that error,

00:32:06.526 --> 00:32:09.836 A:middle
there is this key
NSURLSessionDownloadTask resume

00:32:09.836 --> 00:32:13.036 A:middle
data where we will have
squirreled away resume data

00:32:13.036 --> 00:32:15.626 A:middle
so that you can restart
that transfer later.

00:32:17.166 --> 00:32:19.676 A:middle
So background transfers, this
is where we're going to talk

00:32:19.676 --> 00:32:23.526 A:middle
about the ability to do work
while you're not running.

00:32:24.526 --> 00:32:27.616 A:middle
You have to use the delegate
model for background transfers

00:32:27.616 --> 00:32:28.756 A:middle
and we only support
HTTP and HTTPS,

00:32:28.756 --> 00:32:31.516 A:middle
obviously it doesn't
make any sense

00:32:31.516 --> 00:32:33.686 A:middle
to do a background
transfer from a file URL.

00:32:35.336 --> 00:32:37.376 A:middle
You use exactly the
same delegates as you do

00:32:37.376 --> 00:32:40.326 A:middle
for upload and download tasks.

00:32:41.456 --> 00:32:44.356 A:middle
We have to make some assumptions
though while you're running.

00:32:44.406 --> 00:32:46.896 A:middle
So we don't bother calling you
back to take a redirection.

00:32:47.126 --> 00:32:49.646 A:middle
We're going to assume that
any redirection should always

00:32:49.646 --> 00:32:50.086 A:middle
be taken.

00:32:50.526 --> 00:32:52.686 A:middle
And there's one property
I want to call

00:32:52.686 --> 00:32:54.226 A:middle
out on the configuration object

00:32:55.286 --> 00:32:57.106 A:middle
which is this discretionary
property.

00:32:57.296 --> 00:33:00.266 A:middle
What this tells us is that
when we're doing a background

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:57.296 --> 00:33:00.266 A:middle
What this tells us is that
when we're doing a background

00:33:00.266 --> 00:33:04.546 A:middle
transfer for a session
that's configured using this

00:33:04.596 --> 00:33:06.176 A:middle
discretionary property
being true,

00:33:06.176 --> 00:33:09.206 A:middle
is that we can take advantage
of the state of the machine

00:33:09.206 --> 00:33:12.966 A:middle
to prioritize this
download to only do it

00:33:12.966 --> 00:33:14.156 A:middle
when things are really good.

00:33:14.766 --> 00:33:17.636 A:middle
Typically, that's going to mean
I'm on Wi-Fi and I'm plugged in.

00:33:17.706 --> 00:33:22.536 A:middle
If you're in the foreground and
you don't specify this property,

00:33:22.916 --> 00:33:25.916 A:middle
your download actually has
a high priority, you know,

00:33:25.916 --> 00:33:28.676 A:middle
your user is sitting there,
you've created a download task

00:33:29.216 --> 00:33:32.126 A:middle
and you're going to watch
this thing make progress.

00:33:32.316 --> 00:33:34.596 A:middle
So we want the user
experience there to be--

00:33:34.906 --> 00:33:37.186 A:middle
that the work is
being done right now.

00:33:38.486 --> 00:33:40.116 A:middle
If you started your
download task when you were

00:33:40.116 --> 00:33:41.126 A:middle
in the background though,

00:33:41.766 --> 00:33:43.306 A:middle
we assume that discretionary
is true,

00:33:43.306 --> 00:33:45.966 A:middle
we're going to prioritize
it as if, you know,

00:33:46.186 --> 00:33:47.776 A:middle
this session were created

00:33:47.776 --> 00:33:50.186 A:middle
with the discretionary
flag being set to true.

00:33:50.336 --> 00:33:51.496 A:middle
So if you're a foreground app

00:33:51.496 --> 00:33:54.186 A:middle
and you don't care how
long it's going to take

00:33:54.186 --> 00:33:55.456 A:middle
for this resource to come in.

00:33:55.456 --> 00:33:57.586 A:middle
I don't want to say, you
don't care, I mean you care,

00:33:57.716 --> 00:33:59.476 A:middle
but you don't care that much.

00:33:59.476 --> 00:34:01.936 A:middle
You set discretionary to be true
and we're going to do our best

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:59.476 --> 00:34:01.936 A:middle
You set discretionary to be true
and we're going to do our best

00:34:02.206 --> 00:34:05.406 A:middle
to prioritize it given the
constraints of the network

00:34:05.936 --> 00:34:08.786 A:middle
and the power is-- the
current state of power.

00:34:09.996 --> 00:34:15.025 A:middle
So what this looks like then
is that it creates session

00:34:15.206 --> 00:34:17.386 A:middle
with an identifier, a
background session configuration

00:34:17.966 --> 00:34:18.985 A:middle
with an identifier.

00:34:19.606 --> 00:34:22.275 A:middle
This causes a daemon
to come into existence.

00:34:23.436 --> 00:34:27.186 A:middle
You create your download
object, your download task

00:34:27.476 --> 00:34:29.146 A:middle
and that starts the
work happening

00:34:29.196 --> 00:34:30.076 A:middle
in the background daemon.

00:34:30.485 --> 00:34:33.516 A:middle
While your app is running,
it receives progress updates,

00:34:33.516 --> 00:34:34.876 A:middle
I downloaded this many bytes.

00:34:35.856 --> 00:34:37.255 A:middle
But if your app stops running,

00:34:37.886 --> 00:34:40.326 A:middle
the work continues
off in the daemon.

00:34:41.406 --> 00:34:44.386 A:middle
And when the daemon is
done downloading your file

00:34:44.386 --> 00:34:47.235 A:middle
for you UIKit application,
we're going to re-launch you,

00:34:48.485 --> 00:34:51.196 A:middle
you re-create your session
which reconnects to the daemon

00:34:51.196 --> 00:34:52.786 A:middle
and then the daemon
can tell you, "Hey,

00:34:53.096 --> 00:34:56.096 A:middle
you're completed and
here is the file.

00:34:56.306 --> 00:35:00.396 A:middle
" So, while your app is running,
you create a background pass,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:56.306 --> 00:35:00.396 A:middle
" So, while your app is running,
you create a background pass,

00:35:00.536 --> 00:35:02.366 A:middle
you're going to receive
these update messages.

00:35:03.596 --> 00:35:08.696 A:middle
If you're a UIKit app on iOS
7, when you're not running,

00:35:09.096 --> 00:35:12.656 A:middle
we're going to have to launch
you if we need credentials

00:35:13.246 --> 00:35:17.076 A:middle
or if all the requests that
you have enqueued are complete

00:35:17.106 --> 00:35:19.406 A:middle
and we're going to call the
application handle events

00:35:19.406 --> 00:35:22.586 A:middle
for background URL session
completion handler delegate--

00:35:22.586 --> 00:35:23.696 A:middle
application delegate.

00:35:24.836 --> 00:35:29.056 A:middle
What you do then is
reconnect the session

00:35:29.056 --> 00:35:30.566 A:middle
to the background daemon.

00:35:31.516 --> 00:35:34.036 A:middle
You're going to receive
all the delegate messages

00:35:34.176 --> 00:35:37.186 A:middle
for the outstanding tasks
and then when you're done,

00:35:37.186 --> 00:35:39.926 A:middle
you call that completion
handler to update your snapshot.

00:35:40.456 --> 00:35:45.596 A:middle
When you do reconnect, you can
probe, you can ask the session

00:35:45.596 --> 00:35:47.026 A:middle
for any outstanding tasks.

00:35:47.026 --> 00:35:49.956 A:middle
So you create a background
session configuration,

00:35:49.956 --> 00:35:51.906 A:middle
you create a session
then you call

00:35:51.906 --> 00:35:54.716 A:middle
getTasksWithCompletionHandler
which goes off to the daemon,

00:35:55.176 --> 00:35:58.366 A:middle
gathers up all the task
objects and sends them back

00:35:58.586 --> 00:35:59.656 A:middle
so you can interrogate them.

00:35:59.906 --> 00:36:02.586 A:middle
But you will receive
delegate messages for a task.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.906 --> 00:36:02.586 A:middle
But you will receive
delegate messages for a task.

00:36:02.586 --> 00:36:04.526 A:middle
You don't have to call the
taskWithCompletionHandler.

00:36:05.386 --> 00:36:09.296 A:middle
All right, so Dan is going to
come up and do a demo of this.

00:36:10.286 --> 00:36:11.566 A:middle
>> Thank you, Steve.

00:36:12.796 --> 00:36:14.056 A:middle
All right, good morning
everyone.

00:36:14.396 --> 00:36:17.356 A:middle
So today, I'm going to
do a demo of an iOS app

00:36:17.616 --> 00:36:22.256 A:middle
that uses the NSURLSession API
to do a background transfer.

00:36:25.496 --> 00:36:28.076 A:middle
So this app does two
very simple things.

00:36:28.186 --> 00:36:29.836 A:middle
It downloads an image
in the background

00:36:30.206 --> 00:36:32.136 A:middle
and it can de-reference
an old pointer.

00:36:32.696 --> 00:36:34.976 A:middle
So you should only be doing one
of those things in your apps.

00:36:35.636 --> 00:36:38.376 A:middle
So, I'm going to hit this Start
button and now you can see

00:36:38.376 --> 00:36:39.926 A:middle
that our download
is making progress.

00:36:40.316 --> 00:36:43.146 A:middle
So now, as it gets us
[inaudible] progress,

00:36:43.146 --> 00:36:46.856 A:middle
I'm going to suspend the app so
now the app is no longer running

00:36:46.856 --> 00:36:49.766 A:middle
but our background daemon is
actually doing the download.

00:36:50.366 --> 00:36:52.246 A:middle
So if we look on this
app switcher then

00:36:52.506 --> 00:36:54.596 A:middle
when the download finishes,
we'll re-launch the app

00:36:54.596 --> 00:36:56.376 A:middle
and an image will appear.

00:36:56.876 --> 00:37:01.536 A:middle
[ Applause ]

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:56.876 --> 00:37:01.536 A:middle
[ Applause ]

00:37:02.036 --> 00:37:05.726 A:middle
So, now just to show you
again, we can start a download

00:37:05.856 --> 00:37:08.186 A:middle
and this time, instead of
suspending the app after it goes

00:37:08.186 --> 00:37:11.036 A:middle
for a little while, I'm actually
going to hit this Crash button

00:37:11.656 --> 00:37:14.776 A:middle
and now that they referenced
an old pointer and it crashed.

00:37:15.236 --> 00:37:17.066 A:middle
But even though the app
crashed and there's no--

00:37:17.066 --> 00:37:20.056 A:middle
it's no longer even a process,
we're still downloading

00:37:20.056 --> 00:37:21.096 A:middle
that file in the background.

00:37:21.386 --> 00:37:33.266 A:middle
So then the next time we go back
to our app, the file is there.

00:37:33.266 --> 00:37:33.336 A:middle
[ Applause ]

00:37:33.336 --> 00:37:35.206 A:middle
So, now I'm going to
walk you through the code

00:37:35.206 --> 00:37:36.696 A:middle
and show you how
I wrote this app.

00:37:37.606 --> 00:37:40.936 A:middle
So, first of all, this is--

00:37:41.066 --> 00:37:43.526 A:middle
here is where we
create our NSURLSession

00:37:43.936 --> 00:37:47.826 A:middle
and the magic here is where we
created the background session

00:37:47.826 --> 00:37:50.766 A:middle
configuration and pass in
an identifier and again,

00:37:50.766 --> 00:37:53.646 A:middle
this identifier is so that
when you create this session

00:37:53.646 --> 00:37:56.076 A:middle
on subsequent launches, you'll
be reconnected to the session

00:37:56.076 --> 00:37:57.446 A:middle
that already exist
in the daemons.

00:37:58.196 --> 00:38:01.206 A:middle
So, I do this inside
of a dispatch once here

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:58.196 --> 00:38:01.206 A:middle
So, I do this inside
of a dispatch once here

00:38:01.206 --> 00:38:04.386 A:middle
to emphasize the fact that
you should only be creating a

00:38:04.386 --> 00:38:06.626 A:middle
session with a given
identifier once.

00:38:06.976 --> 00:38:09.576 A:middle
And if you want to create
multiple sessions that have--

00:38:09.716 --> 00:38:11.546 A:middle
that do background work,
that's perfectly fine,

00:38:11.546 --> 00:38:13.176 A:middle
but they each need
their own identifiers.

00:38:13.886 --> 00:38:16.166 A:middle
So now that we have our session,
we can create downloads.

00:38:16.966 --> 00:38:19.406 A:middle
So here's how you would create a
download task with that session

00:38:19.406 --> 00:38:21.836 A:middle
and this is exactly like how
you would create a download task

00:38:21.836 --> 00:38:23.296 A:middle
with an in-process
session as well.

00:38:23.806 --> 00:38:27.466 A:middle
So you create an NSURL request
with the URL that you want

00:38:27.466 --> 00:38:28.726 A:middle
to download and this is--

00:38:28.726 --> 00:38:30.956 A:middle
should also be familiar
from using NSURLConnection.

00:38:31.566 --> 00:38:35.636 A:middle
And then we use the
downloadTaskWithRequest method

00:38:35.866 --> 00:38:38.686 A:middle
to create a download
task in that session.

00:38:41.036 --> 00:38:44.206 A:middle
This is a progress callback for
the download task, it tells--

00:38:44.206 --> 00:38:45.976 A:middle
it can-- and it can
give you information

00:38:45.976 --> 00:38:49.156 A:middle
about how many bytes have
been written to disks so far.

00:38:49.576 --> 00:38:53.136 A:middle
And in our Apple, we use this
to update a progress view

00:38:53.136 --> 00:38:56.266 A:middle
by diving total bytes written
by total bytes expected to write

00:38:56.266 --> 00:38:58.476 A:middle
and that gives us our
download progress.

00:38:58.476 --> 00:39:01.276 A:middle
So the fraction, we use that
to update that progress wheel.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:58.476 --> 00:39:01.276 A:middle
So the fraction, we use that
to update that progress wheel.

00:39:01.766 --> 00:39:04.746 A:middle
This is the--

00:39:04.806 --> 00:39:07.906 A:middle
didFinishDownloadingToURL
delegate message

00:39:08.326 --> 00:39:10.826 A:middle
and this happens when we
finish writing all the bytes

00:39:10.956 --> 00:39:12.396 A:middle
of the download to disk.

00:39:12.806 --> 00:39:17.966 A:middle
And as we mentioned before, you
need to link or copy this file

00:39:17.966 --> 00:39:19.656 A:middle
into a more permanent
location because as--

00:39:19.816 --> 00:39:21.086 A:middle
after these returns, we're going

00:39:21.086 --> 00:39:23.266 A:middle
to unlink the temporary
file that we downloaded.

00:39:23.946 --> 00:39:26.506 A:middle
And we all-- and since this
was an image, it made sense

00:39:26.506 --> 00:39:28.466 A:middle
to display it so
we created an image

00:39:28.716 --> 00:39:31.186 A:middle
and displayed it an image view.

00:39:31.746 --> 00:39:35.806 A:middle
And finally, this is
task didCompleteWithError

00:39:36.056 --> 00:39:38.376 A:middle
and this is the last callback
you will get pertaining

00:39:38.376 --> 00:39:42.406 A:middle
to a particular task and
as Steve mentioned before,

00:39:42.406 --> 00:39:45.136 A:middle
if the connections exceeded
and the downloads exceeded,

00:39:45.136 --> 00:39:47.916 A:middle
this error will be nil and if
there was a transmission error,

00:39:47.916 --> 00:39:49.116 A:middle
the error will be non-nil.

00:39:49.666 --> 00:39:53.406 A:middle
And we also here call this call
completion handler a finished

00:39:53.536 --> 00:39:55.496 A:middle
method and I'll get
back what that--

00:39:55.496 --> 00:39:57.986 A:middle
to what that method
does a little bit.

00:39:58.516 --> 00:40:00.216 A:middle
So this leads us though to our--

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:58.516 --> 00:40:00.216 A:middle
So this leads us though to our--

00:40:00.216 --> 00:40:02.186 A:middle
to one more additional
difference

00:40:02.186 --> 00:40:05.356 A:middle
between in-process sessions and
background sessions which is

00:40:05.356 --> 00:40:08.666 A:middle
that in a background session,
we have support in UIKit

00:40:08.966 --> 00:40:12.496 A:middle
to launch you in the
background when download--

00:40:12.496 --> 00:40:14.036 A:middle
when all the downloads
in the session finished

00:40:14.036 --> 00:40:17.566 A:middle
or when a particular task
needs authentication.

00:40:18.156 --> 00:40:20.836 A:middle
So-- and this is why the
application handle events

00:40:20.836 --> 00:40:23.546 A:middle
for background URL session
completion handler method.

00:40:24.116 --> 00:40:27.486 A:middle
So, when this is called, you'll
want to reconnect to the session

00:40:27.486 --> 00:40:28.606 A:middle
with a given identifier.

00:40:28.936 --> 00:40:32.396 A:middle
So in the case of this app, we
actually created our session

00:40:32.396 --> 00:40:35.216 A:middle
when our view controller
was initialized and which--

00:40:35.336 --> 00:40:37.646 A:middle
that happened when
application did finish launching

00:40:37.646 --> 00:40:38.576 A:middle
with options was called.

00:40:38.576 --> 00:40:40.726 A:middle
So at this point, we'll
already actually be connected

00:40:40.726 --> 00:40:42.196 A:middle
to our session.

00:40:42.836 --> 00:40:46.146 A:middle
And then we have this completion
handler and we want to--

00:40:46.146 --> 00:40:48.336 A:middle
what this completion
handler does is it allows us

00:40:48.336 --> 00:40:51.306 A:middle
to take a snapshot of
your UI and display it

00:40:51.306 --> 00:40:53.976 A:middle
in the app switcher
and it also tells us

00:40:53.976 --> 00:40:55.166 A:middle
that we can suspend your app.

00:40:55.166 --> 00:40:56.456 A:middle
So it's very important
to call this

00:40:56.456 --> 00:40:58.866 A:middle
when you're done handling
all the events pertaining

00:40:58.866 --> 00:40:59.426 A:middle
to the session.

00:40:59.816 --> 00:41:01.446 A:middle
So we only want to call this

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:59.816 --> 00:41:01.446 A:middle
So we only want to call this

00:41:01.446 --> 00:41:03.076 A:middle
when we're done handling
the events.

00:41:03.126 --> 00:41:05.806 A:middle
So for right now, we're going
to save it in a property

00:41:05.806 --> 00:41:08.506 A:middle
on the app delegate and
we'll invoke it later.

00:41:08.866 --> 00:41:11.706 A:middle
And it's important to note that
this has to be a copy property

00:41:11.706 --> 00:41:14.066 A:middle
since there's a block
and you have to--

00:41:14.066 --> 00:41:15.826 A:middle
blocks have to be
copied when saved.

00:41:16.836 --> 00:41:18.816 A:middle
So let's go back to our
download view controller

00:41:19.076 --> 00:41:21.026 A:middle
and I mentioned this
call completion handler

00:41:21.026 --> 00:41:22.196 A:middle
if finished method before.

00:41:22.196 --> 00:41:23.816 A:middle
So let's see what that does.

00:41:24.356 --> 00:41:27.896 A:middle
We called it when the task
finished and now what we want

00:41:27.896 --> 00:41:29.266 A:middle
to do is we want to
check if it's time

00:41:29.266 --> 00:41:30.386 A:middle
to call our completion handler.

00:41:30.596 --> 00:41:34.576 A:middle
And we only want to that once we
know we're done handling all the

00:41:34.576 --> 00:41:36.156 A:middle
events for all the
task that finish

00:41:36.156 --> 00:41:37.866 A:middle
when your app is
in the background.

00:41:38.346 --> 00:41:41.006 A:middle
So, in this case, we
only did one download,

00:41:41.006 --> 00:41:43.146 A:middle
but this is what you
would do if you--

00:41:43.386 --> 00:41:45.646 A:middle
if your app did multiple
tasks in the background

00:41:45.646 --> 00:41:46.736 A:middle
which is perfectly reasonable.

00:41:47.116 --> 00:41:50.616 A:middle
We used the sessions get task
with completion handler method

00:41:50.616 --> 00:41:53.216 A:middle
and this will give us back
a raise of all our data,

00:41:53.216 --> 00:41:55.026 A:middle
the upload and download tasks

00:41:55.136 --> 00:41:58.316 A:middle
and it won't give you back any
tasks that have been completed.

00:41:58.536 --> 00:42:00.026 A:middle
So if all these arrays
are empty,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.536 --> 00:42:00.026 A:middle
So if all these arrays
are empty,

00:42:00.306 --> 00:42:03.556 A:middle
that means you know you're
done handling all the events

00:42:03.556 --> 00:42:04.886 A:middle
and we can call our
completion handler.

00:42:05.336 --> 00:42:07.026 A:middle
So here we get our app delegate.

00:42:07.286 --> 00:42:09.286 A:middle
We see if we have a
completion handler

00:42:09.286 --> 00:42:10.976 A:middle
and if we do, we invoke it.

00:42:11.636 --> 00:42:14.826 A:middle
And it's-- that's how you
use background uploads

00:42:14.826 --> 00:42:15.396 A:middle
and downloads.

00:42:15.806 --> 00:42:16.786 A:middle
Back to you Steve.

00:42:16.786 --> 00:42:17.096 A:middle
[ Applause ]

00:42:17.096 --> 00:42:22.656 A:middle
Thank you.

00:42:22.656 --> 00:42:23.086 A:middle
Thanks Dan.

00:42:23.636 --> 00:42:26.166 A:middle
OK, so why do we want
to use NSURLSession

00:42:26.166 --> 00:42:27.366 A:middle
versus NSURLConnection?

00:42:28.496 --> 00:42:31.046 A:middle
NSURLSession again
provides you with access

00:42:31.106 --> 00:42:35.136 A:middle
to connection based auth which
is something NSURLConnection did

00:42:35.136 --> 00:42:37.716 A:middle
but only by targeting
specific requests.

00:42:38.016 --> 00:42:41.106 A:middle
Session gives you better
HTTP configuration options

00:42:41.106 --> 00:42:42.746 A:middle
that people had been
asking for, for years.

00:42:43.286 --> 00:42:46.006 A:middle
These are available through
the NSURL configuration object

00:42:46.166 --> 00:42:47.166 A:middle
that you create your
session with.

00:42:47.496 --> 00:42:51.416 A:middle
The ability to create private
subclassable storage objects is

00:42:51.416 --> 00:42:52.786 A:middle
something you couldn't
do before.

00:42:52.786 --> 00:42:56.586 A:middle
You couldn't create a cookie
storage subclass and have

00:42:56.586 --> 00:42:58.406 A:middle
that available to
the system views.

00:42:59.166 --> 00:43:02.136 A:middle
You could create an
NSURL cache subclass

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:59.166 --> 00:43:02.136 A:middle
You could create an
NSURL cache subclass

00:43:02.536 --> 00:43:04.796 A:middle
but then you would set it to
be the default for the system

00:43:04.796 --> 00:43:07.206 A:middle
and all other processes would
end up using it as well--

00:43:07.206 --> 00:43:09.446 A:middle
sorry, all other frameworks
within your process.

00:43:09.446 --> 00:43:12.476 A:middle
These are always per
process properties.

00:43:13.366 --> 00:43:15.616 A:middle
Very importantly,
Session is how you get

00:43:15.656 --> 00:43:17.866 A:middle
to add a process
background transfers both

00:43:17.866 --> 00:43:19.496 A:middle
for uploads and for downloads.

00:43:20.076 --> 00:43:22.426 A:middle
It's also going to be the
baseline that we're going

00:43:22.426 --> 00:43:24.286 A:middle
to build any future
APIs on top of.

00:43:24.286 --> 00:43:27.926 A:middle
Session gives us a context
that we didn't have before,

00:43:28.096 --> 00:43:29.736 A:middle
before the context
was your process.

00:43:29.886 --> 00:43:31.346 A:middle
Now within your process,
there's a lot

00:43:31.346 --> 00:43:34.456 A:middle
of different things going
on, Session is how we're able

00:43:34.456 --> 00:43:36.726 A:middle
to compartmentalize that
within your application.

00:43:37.906 --> 00:43:39.736 A:middle
So we spend a lot of time
talking about session.

00:43:39.996 --> 00:43:43.066 A:middle
There are some other
enhancements that I want

00:43:43.066 --> 00:43:49.616 A:middle
to mention that are new
in iOS 7 and Mavericks.

00:43:49.666 --> 00:43:53.796 A:middle
NSNetServices is an existing
API that allows you to browse

00:43:53.796 --> 00:43:59.356 A:middle
or discover and connect to
Bonjour Publish Services.

00:43:59.356 --> 00:44:02.646 A:middle
It also allows you to
publish Bonjour Services.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.356 --> 00:44:02.646 A:middle
It also allows you to
publish Bonjour Services.

00:44:02.646 --> 00:44:06.146 A:middle
You do this by creating an
NSNetServices describing the

00:44:06.146 --> 00:44:07.586 A:middle
type of service you
want to connect to

00:44:07.586 --> 00:44:11.956 A:middle
and you call this get input
output stream message method.

00:44:12.056 --> 00:44:15.916 A:middle
The streams you get back, you
open them and at that point,

00:44:15.916 --> 00:44:19.916 A:middle
the resolution occurs, once the
stream is successfully open,

00:44:19.916 --> 00:44:21.496 A:middle
that means you have a raw socket

00:44:21.496 --> 00:44:24.316 A:middle
that you can do your own
protocol framing on top of.

00:44:26.246 --> 00:44:28.876 A:middle
There's a new property in
iOS 7 includesPeerToPeer.

00:44:29.526 --> 00:44:32.496 A:middle
When you specify this
property in your NSNetServices

00:44:32.496 --> 00:44:35.846 A:middle
when you perform a browse,
it will also browse on peer

00:44:35.846 --> 00:44:38.476 A:middle
to peer Wi-Fi and Bluetooth
networks automatically.

00:44:39.216 --> 00:44:45.946 A:middle
The peer to peer Wi-Fi
is new support in iOS 7.

00:44:46.926 --> 00:44:50.596 A:middle
There's also a new option
for publishing a service

00:44:51.306 --> 00:44:55.116 A:middle
which automatically creates
a listening socket for you.

00:44:55.356 --> 00:44:58.946 A:middle
So when you create your
NSNetService to publish it,

00:44:58.946 --> 00:45:01.106 A:middle
you need to specify this
new option NSNetService

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.946 --> 00:45:01.106 A:middle
you need to specify this
new option NSNetService

00:45:01.316 --> 00:45:02.426 A:middle
ListenForConnections.

00:45:02.706 --> 00:45:06.646 A:middle
We'll listen on IPv4 and
IPv6 for incoming connections

00:45:06.646 --> 00:45:10.076 A:middle
and when a remote
connects to that socket,

00:45:10.076 --> 00:45:12.366 A:middle
we will call this
new delegate method,

00:45:12.676 --> 00:45:15.686 A:middle
netServiceDidAcceptConnection
with input stream output stream.

00:45:16.076 --> 00:45:20.116 A:middle
You open your streams and now
you have a raw protocol stream

00:45:20.556 --> 00:45:26.066 A:middle
to frame your own messages
onto the remote site.

00:45:26.326 --> 00:45:29.546 A:middle
Authentication in iOS
7 gets single sign-on.

00:45:29.546 --> 00:45:31.896 A:middle
Kerberos Authentication
is automatically handled

00:45:32.286 --> 00:45:34.896 A:middle
by device managers that
have installed a profile

00:45:34.896 --> 00:45:36.066 A:middle
on your device.

00:45:37.046 --> 00:45:39.996 A:middle
You can specify which
connect type--

00:45:40.506 --> 00:45:42.646 A:middle
what type of connection
should be authenticated based

00:45:42.646 --> 00:45:46.026 A:middle
on the URL or by application.

00:45:47.476 --> 00:45:50.266 A:middle
And we handle this implicitly
for outgoing connections.

00:45:50.596 --> 00:45:53.956 A:middle
You need to know that it's
happening for your connections

00:45:53.956 --> 00:45:57.726 A:middle
in your app, but you won't
necessarily need to have

00:45:57.766 --> 00:45:59.186 A:middle
to do anything special about it.

00:45:59.716 --> 00:46:02.676 A:middle
There is an-- a session,
I think it was yesterday

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:59.716 --> 00:46:02.676 A:middle
There is an-- a session,
I think it was yesterday

00:46:02.676 --> 00:46:04.786 A:middle
"Extending your Apps for
Enterprising and Education Use"

00:46:04.786 --> 00:46:07.176 A:middle
which you should check into
to find that more about how

00:46:07.226 --> 00:46:09.896 A:middle
to configure a system
and how to respond--

00:46:10.026 --> 00:46:12.336 A:middle
well, you don't have to respond,

00:46:12.626 --> 00:46:14.716 A:middle
how to deal with Kerberos
authenticated connections.

00:46:15.266 --> 00:46:17.966 A:middle
The final API enhancement

00:46:18.276 --> 00:46:21.686 A:middle
in Foundation Networking is
iCloud Credential Syncing.

00:46:22.346 --> 00:46:24.186 A:middle
When you create an
NSURL credential

00:46:24.236 --> 00:46:27.806 A:middle
which represents the
username and password

00:46:27.806 --> 00:46:30.816 A:middle
or client certificate, you're
presenting to the remote site.

00:46:31.636 --> 00:46:34.896 A:middle
You specify a persistence type
for it so that we can keep track

00:46:34.896 --> 00:46:37.336 A:middle
of it in the
NSURLCredentialStorage.

00:46:37.926 --> 00:46:40.436 A:middle
There's a new persistence
type called synchronisable.

00:46:40.926 --> 00:46:43.036 A:middle
When you create a credential
with this persistence type,

00:46:43.406 --> 00:46:45.426 A:middle
it automatically could
sync through iCloud

00:46:45.616 --> 00:46:49.626 A:middle
to all devices registered
for that iCloud account.

00:46:50.656 --> 00:46:52.506 A:middle
In order for this to work,
we have to have a new API

00:46:52.756 --> 00:46:54.846 A:middle
to actually remove the
credential as well.

00:46:54.846 --> 00:46:56.666 A:middle
So there's this new
remove credential

00:46:56.666 --> 00:47:00.036 A:middle
for protection space API
on NSURLCredentialStorage.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:56.666 --> 00:47:00.036 A:middle
for protection space API
on NSURLCredentialStorage.

00:47:00.766 --> 00:47:03.866 A:middle
You invoke this using a
dictionary of properties

00:47:03.866 --> 00:47:05.116 A:middle
and the key you want to look

00:47:05.116 --> 00:47:07.646 A:middle
for is the
NSURLCredentialStorage

00:47:07.646 --> 00:47:09.676 A:middle
RemoveSynchronizableCredentials.

00:47:12.266 --> 00:47:15.866 A:middle
So, [inaudible], most of what
we talked about is NSURLSession.

00:47:16.886 --> 00:47:19.046 A:middle
We do think this is going to
be a good way for you guys

00:47:19.086 --> 00:47:21.966 A:middle
to build your networking
applications in iOS 7

00:47:22.506 --> 00:47:24.326 A:middle
and OS X Mavericks
going forward.

00:47:25.436 --> 00:47:27.656 A:middle
It replaces NSURLConnection,
but I want to point

00:47:27.656 --> 00:47:29.576 A:middle
out that NSURLConnection
doesn't go away.

00:47:29.576 --> 00:47:32.146 A:middle
It's still there and you
can use your existing code,

00:47:32.146 --> 00:47:36.836 A:middle
doesn't break but NSURLSession
is sort of the preferred way

00:47:37.146 --> 00:47:39.286 A:middle
to do these types
of request later on.

00:47:40.136 --> 00:47:41.656 A:middle
It gives you a lot
more customization

00:47:41.656 --> 00:47:42.766 A:middle
over NSURLConnection.

00:47:44.076 --> 00:47:47.806 A:middle
And it very importantly
allows you to get work done

00:47:47.936 --> 00:47:50.316 A:middle
when you're not running.

00:47:50.316 --> 00:47:53.806 A:middle
NSNetServices adds peer to
peer support both browsing

00:47:53.806 --> 00:47:58.546 A:middle
and publishing and it
has a new listening API

00:47:59.096 --> 00:48:01.126 A:middle
so that you can create
services and publish it

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:59.096 --> 00:48:01.126 A:middle
so that you can create
services and publish it

00:48:01.126 --> 00:48:05.266 A:middle
on your local network and
NSURLAuthentication is enhanced

00:48:05.266 --> 00:48:08.756 A:middle
with Kerberos single sign-on
and iCloud credential syncing.

00:48:10.296 --> 00:48:13.336 A:middle
OK, so Paul Danbold is our Core
OS Technologies Evangelist,

00:48:13.336 --> 00:48:14.736 A:middle
he is happy to field
any questions.

00:48:14.976 --> 00:48:18.016 A:middle
The Foundation Class
Reference is being updated

00:48:18.096 --> 00:48:20.346 A:middle
with documentation
for NSURLSession

00:48:21.226 --> 00:48:24.096 A:middle
and the Developer
Forums will be available

00:48:24.096 --> 00:48:25.806 A:middle
to answer your questions,
they will hang

00:48:25.806 --> 00:48:26.896 A:middle
out there and answer questions.

00:48:28.146 --> 00:48:31.446 A:middle
There's some other sessions I
want to point you out though,

00:48:31.636 --> 00:48:35.456 A:middle
yesterday was this Managing
Apple Devices session,

00:48:36.346 --> 00:48:39.186 A:middle
that and the Extending
Your Apps for Enterprise

00:48:39.186 --> 00:48:42.136 A:middle
and Education Use
session is where you learn

00:48:42.136 --> 00:48:44.726 A:middle
about Kerberos Authentication
and how that's handled.

00:48:45.626 --> 00:48:47.286 A:middle
Yesterday's talk on What's New

00:48:47.286 --> 00:48:49.086 A:middle
with Multitasking
is very important

00:48:49.086 --> 00:48:51.656 A:middle
and relevant to this discussion.

00:48:52.616 --> 00:48:56.516 A:middle
Dave Chan showed how to use
NSURLSession in response

00:48:56.516 --> 00:49:00.156 A:middle
to background notifications
in order to get work done

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:56.516 --> 00:49:00.156 A:middle
to background notifications
in order to get work done

00:49:01.156 --> 00:49:05.016 A:middle
in response to, you know,
a server pushed token.

00:49:05.176 --> 00:49:07.736 A:middle
Nearby Networking with Multipeer
Connectivity follows this

00:49:07.736 --> 00:49:11.186 A:middle
session and we're going
to talk there about--

00:49:11.636 --> 00:49:13.866 A:middle
more about how to do--

00:49:14.506 --> 00:49:16.986 A:middle
use NSNetService to create
server use and publish service.

00:49:18.376 --> 00:49:21.916 A:middle
And then sounds like What's New
in State Restoration is relevant

00:49:21.916 --> 00:49:26.036 A:middle
because we want to know when
your application is re-launched,

00:49:26.036 --> 00:49:27.306 A:middle
how to update your snapshot

00:49:27.626 --> 00:49:30.186 A:middle
and have a nice live
experience for the user.

00:49:30.476 --> 00:49:32.186 A:middle
So thank you.

00:49:32.186 --> 00:49:32.253 A:middle
[ Applause ]

00:49:32.253 --> 00:49:32.320 A:middle
[ Silence ]

00:49:32.320 --> 00:49:34.586 A:middle
sma dv