207.srt

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

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

00:00:10.916 --> 00:00:12.066 A:middle
>> Nick Colet: My name is
Nick Colet [assumed spelling]

00:00:12.856 --> 00:00:14.716 A:middle
[applause] I'm a
[laughter] -- thank you.

00:00:17.296 --> 00:00:20.426 A:middle
I'm a software engineer on the
Core Data team here at Apple,

00:00:20.426 --> 00:00:24.086 A:middle
and I'm excited to take you
through what's new in Core Data

00:00:24.586 --> 00:00:26.886 A:middle
in iOS 7 and Mac OS X 10.9.

00:00:28.356 --> 00:00:29.676 A:middle
We've done a lot of great work

00:00:29.676 --> 00:00:31.676 A:middle
in the Core Data framework
over the last year.

00:00:32.686 --> 00:00:35.616 A:middle
We've made a significant number
of improvements to key areas

00:00:35.616 --> 00:00:39.316 A:middle
to improve performance,
reliability and stability,

00:00:39.996 --> 00:00:42.986 A:middle
but today, we want to take a
moment to focus on just a few

00:00:42.986 --> 00:00:45.676 A:middle
of them, beginning with iCloud.

00:00:45.846 --> 00:00:47.596 A:middle
Now, we've made a
number of improvements

00:00:47.596 --> 00:00:48.826 A:middle
to our iCloud integration.

00:00:49.036 --> 00:00:51.276 A:middle
We've been iterating on
it for almost 12 months

00:00:51.276 --> 00:00:53.436 A:middle
since our WWDC session
last year,

00:00:54.016 --> 00:00:57.346 A:middle
and we took into account a lot
of your feedback that we've seen

00:00:57.346 --> 00:01:00.786 A:middle
on developer forums, in
radars and around the web.

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

00:00:57.346 --> 00:01:00.786 A:middle
on developer forums, in
radars and around the web.

00:01:01.606 --> 00:01:04.626 A:middle
And so, the improvements
that we've made require us

00:01:04.626 --> 00:01:07.546 A:middle
to revisit a few of the topics
that we discussed last year,

00:01:08.296 --> 00:01:10.346 A:middle
beginning with improvements
we've made

00:01:10.346 --> 00:01:14.116 A:middle
to the fallback store, as
well as changes to how you set

00:01:14.116 --> 00:01:18.246 A:middle
up the store asynchronously;
and what happens

00:01:18.246 --> 00:01:21.586 A:middle
with iCloud transition events
like when the account changes.

00:01:22.626 --> 00:01:25.076 A:middle
We're also going to
talk about some new API

00:01:25.116 --> 00:01:26.386 A:middle
that we're introducing today.

00:01:26.386 --> 00:01:30.316 A:middle
And finally, I'll
introduce you to some changes

00:01:30.316 --> 00:01:33.166 A:middle
that have happened across the
organization and developer tools

00:01:33.436 --> 00:01:36.846 A:middle
and frameworks to change how
you live and work on iCloud.

00:01:37.556 --> 00:01:38.826 A:middle
They'll make it easier to use

00:01:39.016 --> 00:01:40.806 A:middle
and provide a lot
more transparency

00:01:40.806 --> 00:01:42.336 A:middle
than was previously
available to you.

00:01:44.116 --> 00:01:46.036 A:middle
Then, Melissa Turner
will come up

00:01:46.036 --> 00:01:47.326 A:middle
and take you through some demos.

00:01:48.216 --> 00:01:51.276 A:middle
And finally, Ben Trumbull will
come up and give you an overview

00:01:51.536 --> 00:01:54.216 A:middle
of several enhancements that
we've made to the SQLite store.

00:01:55.406 --> 00:01:58.246 A:middle
Now, before I dive into
the meat of the discussion,

00:01:58.736 --> 00:02:01.826 A:middle
I'd like to take a moment
to frame it by talking

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

00:01:58.736 --> 00:02:01.826 A:middle
I'd like to take a moment
to frame it by talking

00:02:01.826 --> 00:02:04.476 A:middle
about our goals and
objectives related to iCloud.

00:02:05.146 --> 00:02:09.015 A:middle
You see, last year after iOS
6 and Mac OS X 10.8 shipped,

00:02:09.576 --> 00:02:11.796 A:middle
we took a look at our
iCloud integration and tried

00:02:11.796 --> 00:02:15.116 A:middle
to identify several key
areas where we could focus

00:02:15.116 --> 00:02:17.886 A:middle
on providing valuable
improvements toward integration,

00:02:18.536 --> 00:02:20.486 A:middle
the first of which is speed.

00:02:21.246 --> 00:02:23.576 A:middle
This year, we've made a
number of improvements

00:02:23.576 --> 00:02:26.106 A:middle
that will change not only how
efficient our integration is

00:02:26.106 --> 00:02:29.316 A:middle
in terms of its memory
usage, its processing usage

00:02:29.606 --> 00:02:33.086 A:middle
and battery consumption,
but also how well it deals

00:02:33.086 --> 00:02:34.406 A:middle
with iCloud under the hood.

00:02:34.866 --> 00:02:36.106 A:middle
We've made a number
of improvements

00:02:36.106 --> 00:02:39.056 A:middle
to downloading files so
that changes appear faster

00:02:39.426 --> 00:02:42.326 A:middle
and peers can communicate
their changes faster than ever.

00:02:43.726 --> 00:02:45.966 A:middle
We also strove to
improve simplicity.

00:02:46.696 --> 00:02:48.986 A:middle
You see, after we
shipped last year,

00:02:49.226 --> 00:02:51.906 A:middle
we felt the developers
still had to write a number

00:02:51.936 --> 00:02:55.726 A:middle
of complex pieces of code
to integrate successfully

00:02:55.726 --> 00:02:58.246 A:middle
with our iCloud integration
and we found

00:02:58.246 --> 00:03:01.656 A:middle
that this hampered your ability
to build effective applications

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

00:02:58.246 --> 00:03:01.656 A:middle
that this hampered your ability
to build effective applications

00:03:01.996 --> 00:03:03.706 A:middle
that worked on top
of our integration.

00:03:04.716 --> 00:03:08.036 A:middle
And finally, we really want
to focus on consistency.

00:03:08.606 --> 00:03:11.926 A:middle
As you may have noticed, we
didn't have a clear paradigm

00:03:11.926 --> 00:03:15.156 A:middle
that you could reuse over
and over again, when working

00:03:15.156 --> 00:03:18.336 A:middle
with our integration, and this
made it exceptionally difficult,

00:03:18.536 --> 00:03:20.966 A:middle
or at least more difficult
than we had originally planned

00:03:21.346 --> 00:03:24.296 A:middle
to handle transition events
like when the account changes.

00:03:24.566 --> 00:03:28.376 A:middle
So with that in mind, let's take
a look at the fallback store.

00:03:28.956 --> 00:03:32.756 A:middle
As you may remember, the
fallback store is a concept

00:03:32.756 --> 00:03:36.176 A:middle
that we introduced last
year at WWDC as a way

00:03:36.176 --> 00:03:38.246 A:middle
of providing a local
persistent store

00:03:38.346 --> 00:03:41.146 A:middle
that your application
could use in the event

00:03:41.146 --> 00:03:43.846 A:middle
that the iCloud store was
unavailable for a certain period

00:03:43.846 --> 00:03:47.386 A:middle
of time, and your application
would simply add the store

00:03:47.386 --> 00:03:49.496 A:middle
to the coordinator
to make it available

00:03:49.496 --> 00:03:51.096 A:middle
to your managed object context

00:03:51.276 --> 00:03:54.426 A:middle
so that your user could
write changes to disk while

00:03:54.426 --> 00:03:57.166 A:middle
in the background we set up
the iCloud store for you.

00:03:58.676 --> 00:04:00.986 A:middle
And this would produce
a pairing, if you will,

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

00:03:58.676 --> 00:04:00.986 A:middle
And this would produce
a pairing, if you will,

00:04:01.056 --> 00:04:03.226 A:middle
of a local persistent store file

00:04:03.226 --> 00:04:05.196 A:middle
and an iCloud persistent
store file

00:04:05.196 --> 00:04:07.196 A:middle
that were tied to
the same account.

00:04:08.276 --> 00:04:11.766 A:middle
Now, this worked out
rather well until,

00:04:12.946 --> 00:04:14.556 A:middle
you ended up with
multiple accounts,

00:04:15.536 --> 00:04:17.766 A:middle
and this is when things
became a bit cumbersome

00:04:18.245 --> 00:04:20.136 A:middle
because developers would
end up spending a lot

00:04:20.136 --> 00:04:21.736 A:middle
of their time writing codes

00:04:21.736 --> 00:04:24.896 A:middle
and manage these different
persistent store files instead

00:04:24.896 --> 00:04:26.886 A:middle
of focusing on building
our applications.

00:04:27.596 --> 00:04:30.686 A:middle
And so for iOS 7
and Mac OS X 10.9,

00:04:31.166 --> 00:04:33.096 A:middle
we've completely
eliminated the need for you

00:04:33.096 --> 00:04:34.456 A:middle
to manage the fallback store.

00:04:35.036 --> 00:04:36.866 A:middle
We've subsumed that
responsibility

00:04:36.866 --> 00:04:39.996 A:middle
into the framework and it
will be entirely managed

00:04:39.996 --> 00:04:40.746 A:middle
by Core Data.

00:04:42.096 --> 00:04:45.766 A:middle
This also means [applause]
[laughter] -- thank you.

00:04:46.986 --> 00:04:49.906 A:middle
This also means that your
application will only ever use

00:04:49.996 --> 00:04:51.956 A:middle
one persistent store
file per account.

00:04:52.956 --> 00:04:57.056 A:middle
Now, we say "per account"
because we still have

00:04:57.056 --> 00:04:59.706 A:middle
to provide a different
actual persistent store file

00:04:59.706 --> 00:05:02.186 A:middle
for each iCloud account
that's in use on a system,

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

00:04:59.706 --> 00:05:02.186 A:middle
for each iCloud account
that's in use on a system,

00:05:03.136 --> 00:05:04.806 A:middle
and this requires
that we change a bit

00:05:04.806 --> 00:05:06.536 A:middle
of our guidance from
previous years.

00:05:07.286 --> 00:05:09.846 A:middle
You see, we had previously
advised

00:05:10.126 --> 00:05:12.456 A:middle
that you could keep
the iCloud store inside

00:05:12.456 --> 00:05:15.236 A:middle
of the iCloud container
in a .nosync folder.

00:05:15.906 --> 00:05:17.766 A:middle
This had a rather
convenient advantage

00:05:18.006 --> 00:05:20.446 A:middle
of automatically deleting
the store file for you

00:05:20.696 --> 00:05:21.866 A:middle
when the account went away.

00:05:22.796 --> 00:05:25.896 A:middle
However, because we
now take responsibility

00:05:25.896 --> 00:05:27.456 A:middle
for managing the fallback store

00:05:27.816 --> 00:05:30.556 A:middle
and the fallback store must
exist in local storage,

00:05:31.106 --> 00:05:33.916 A:middle
we now require that you store
the persistent store file

00:05:33.916 --> 00:05:37.946 A:middle
somewhere in local storage,
usually the application sandbox.

00:05:38.236 --> 00:05:40.376 A:middle
However, if your
application isn't sandboxed,

00:05:40.646 --> 00:05:42.976 A:middle
you can keep it wherever you
normally keep your persistent

00:05:42.976 --> 00:05:43.726 A:middle
store files.

00:05:47.036 --> 00:05:51.306 A:middle
Additionally, and because this
is now being taken over entirely

00:05:51.306 --> 00:05:55.086 A:middle
by Core Data, we want to
provide a bit more transparency

00:05:55.186 --> 00:05:58.836 A:middle
than we used to about events
that are happening related

00:05:58.836 --> 00:06:01.596 A:middle
to the fallback store,
and for this reason,

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

00:05:58.836 --> 00:06:01.596 A:middle
to the fallback store,
and for this reason,

00:06:01.596 --> 00:06:03.606 A:middle
we'll log some new
events to console

00:06:03.606 --> 00:06:05.906 A:middle
so that you can see them
during your development.

00:06:06.796 --> 00:06:08.776 A:middle
You may be familiar with
our Core Data logging.

00:06:09.016 --> 00:06:11.896 A:middle
All of our messages start
with CoreData: Ubiquity:

00:06:11.896 --> 00:06:14.646 A:middle
and when we're using
the fallback store,

00:06:14.906 --> 00:06:16.786 A:middle
you'll see Using
Local Storage 1.

00:06:17.606 --> 00:06:20.406 A:middle
You'll see Using Local
Storage 0 if we've been able

00:06:20.406 --> 00:06:22.356 A:middle
to transition off
the fallback store

00:06:22.356 --> 00:06:24.636 A:middle
and your application is
fully connected to iCloud.

00:06:25.576 --> 00:06:27.926 A:middle
Now, it's important that you
understand the expectations

00:06:27.926 --> 00:06:30.236 A:middle
associated with each
of these log messages.

00:06:30.866 --> 00:06:34.616 A:middle
Using Local Storage 1 means
that changes that you make

00:06:34.616 --> 00:06:37.186 A:middle
to the persistent store
are being persisted vocally

00:06:37.986 --> 00:06:40.616 A:middle
and they won't be available
to other peers over iCloud

00:06:40.996 --> 00:06:43.576 A:middle
until you see Using
Local Storage 0.

00:06:44.186 --> 00:06:45.496 A:middle
This is when you can expect

00:06:45.496 --> 00:06:47.496 A:middle
to start seeing import
notifications.

00:06:47.856 --> 00:06:50.676 A:middle
And when you should expect
seeing your changes uploaded

00:06:50.716 --> 00:06:52.516 A:middle
and made available
to other peers.

00:06:53.066 --> 00:06:57.876 A:middle
So that's the fallback store,
and now I'd like to tell you

00:06:57.876 --> 00:06:59.956 A:middle
about some of the changes
we've made to how you set

00:06:59.956 --> 00:07:01.356 A:middle
up the store asynchronously.

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

00:06:59.956 --> 00:07:01.356 A:middle
up the store asynchronously.

00:07:02.736 --> 00:07:05.046 A:middle
You may be familiar
with this line of code.

00:07:05.426 --> 00:07:07.916 A:middle
It simply adds persistent
store to an instance

00:07:07.966 --> 00:07:12.236 A:middle
of NSPersistentStoreCoordinator;
and when you call it,

00:07:12.726 --> 00:07:15.886 A:middle
you expect to get a store
file back fairly quickly.

00:07:16.596 --> 00:07:19.886 A:middle
In most situations,
especially those without iCloud,

00:07:20.716 --> 00:07:23.016 A:middle
we only have to do a
small amount of network --

00:07:23.016 --> 00:07:26.486 A:middle
of local I/O to bring the
persistent store file up,

00:07:26.756 --> 00:07:28.236 A:middle
so it returns immediately.

00:07:29.136 --> 00:07:33.416 A:middle
However, when it is connected
to iCloud, we sometimes have

00:07:33.416 --> 00:07:35.626 A:middle
to do a significant
amount of network I/O

00:07:35.966 --> 00:07:37.556 A:middle
to make sure the
persistent store is

00:07:37.556 --> 00:07:40.146 A:middle
in a state that's consistent
and ready to be used

00:07:40.146 --> 00:07:44.746 A:middle
by your application, and in iOS
6, we did this synchronously.

00:07:45.586 --> 00:07:48.386 A:middle
That meant that whenever you
called add persistent store

00:07:48.446 --> 00:07:50.996 A:middle
and you didn't have a
persistent store file on disk,

00:07:51.506 --> 00:07:53.796 A:middle
we would go out to the
network and discover the state

00:07:53.796 --> 00:07:55.606 A:middle
of the contents of
the iCloud container.

00:07:56.656 --> 00:07:59.536 A:middle
In iOS 7 and Mac OS X 10.9,

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

00:08:00.066 --> 00:08:03.366 A:middle
we no longer do this work
synchronously within the call

00:08:03.366 --> 00:08:04.546 A:middle
to addPersistentStore,

00:08:05.136 --> 00:08:08.256 A:middle
so addPersistentStore will
always return immediately.

00:08:09.156 --> 00:08:11.456 A:middle
And this is a huge
benefit to your application

00:08:11.686 --> 00:08:13.366 A:middle
because it eliminates
the need for you

00:08:13.366 --> 00:08:15.766 A:middle
to call addPersistentStore
on a background thread.

00:08:15.796 --> 00:08:17.686 A:middle
Now, have we done this?

00:08:18.336 --> 00:08:21.126 A:middle
Well, we've done it by
using the fallback store.

00:08:21.916 --> 00:08:24.966 A:middle
We will transparently pass
the fallback store back

00:08:24.966 --> 00:08:27.986 A:middle
to your application and so that
you can begin working with it

00:08:28.196 --> 00:08:30.876 A:middle
and your user can begin
making changes immediately.

00:08:32.736 --> 00:08:36.466 A:middle
But, because we manage the
fallback store now, we were able

00:08:36.466 --> 00:08:38.535 A:middle
to take the integration
one step further

00:08:38.696 --> 00:08:40.736 A:middle
than we felt developers
could on their own.

00:08:41.626 --> 00:08:44.346 A:middle
We now store individual
transaction records

00:08:44.346 --> 00:08:46.726 A:middle
for each change that's
made to the fallback store

00:08:47.376 --> 00:08:51.136 A:middle
and this has implications for
both performance and bandwidth.

00:08:51.746 --> 00:08:55.236 A:middle
You see, last year, if your
application took responsibility

00:08:55.236 --> 00:08:57.426 A:middle
for migrating contents
from the fallback store

00:08:57.426 --> 00:09:00.486 A:middle
to the iCloud store after the
iCloud store was available,

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

00:08:57.426 --> 00:09:00.486 A:middle
to the iCloud store after the
iCloud store was available,

00:09:01.186 --> 00:09:04.116 A:middle
you would have to do a
lot of extra work to scope

00:09:04.116 --> 00:09:05.756 A:middle
that migration and ensure

00:09:05.756 --> 00:09:07.606 A:middle
that it didn't consume
too much memory

00:09:07.926 --> 00:09:09.336 A:middle
or bandwidth over the wire.

00:09:10.146 --> 00:09:12.566 A:middle
However, now because
we keep our record

00:09:12.566 --> 00:09:16.106 A:middle
of each individual transaction,
all that work is done for you.

00:09:16.956 --> 00:09:19.936 A:middle
And this means that once the
iCloud store is available,

00:09:20.646 --> 00:09:23.796 A:middle
we can transport those changes
into the container immediately

00:09:23.946 --> 00:09:25.796 A:middle
and make them available
to other peers.

00:09:26.166 --> 00:09:28.696 A:middle
So there's no additional work
for you to do the migrate data

00:09:28.696 --> 00:09:30.756 A:middle
from the fallback store
to the iCloud store.

00:09:31.726 --> 00:09:35.106 A:middle
But we also wanted to give
you a better way to tie

00:09:35.106 --> 00:09:38.006 A:middle
in with this transition
and that requires

00:09:38.006 --> 00:09:39.466 A:middle
that we introduce some new API.

00:09:40.706 --> 00:09:43.276 A:middle
Today, we're introducing
NSPersistentStoreCoordinator

00:09:43.276 --> 00:09:47.236 A:middle
Storage Will Change notification
as a way that we can tell you

00:09:47.576 --> 00:09:50.606 A:middle
that an event has occurred where
we need to change the contents

00:09:50.606 --> 00:09:52.336 A:middle
of the persistent
store file on disk.

00:09:53.356 --> 00:09:55.976 A:middle
When you receive it,
you can optionally call

00:09:56.036 --> 00:09:59.196 A:middle
NSManagedObjectContext
save if there are changes

00:09:59.196 --> 00:10:01.706 A:middle
in your managed object context
that you wish to persist,

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

00:09:59.196 --> 00:10:01.706 A:middle
in your managed object context
that you wish to persist,

00:10:02.286 --> 00:10:05.126 A:middle
and then you can call
NSManagedObjectContext reset

00:10:05.126 --> 00:10:09.706 A:middle
and prepare your
UI for new data.

00:10:10.876 --> 00:10:13.526 A:middle
When we get control back from
your notification observer,

00:10:13.916 --> 00:10:16.226 A:middle
we'll remove the store from
the coordinator for you

00:10:16.716 --> 00:10:19.186 A:middle
and then post
NSPersistentStoreCoordinator

00:10:19.186 --> 00:10:21.066 A:middle
Storage Did Change notification

00:10:21.436 --> 00:10:22.846 A:middle
when the store is
ready to come up.

00:10:23.726 --> 00:10:25.086 A:middle
Now, it's important
that you realize

00:10:25.156 --> 00:10:26.916 A:middle
that this transition
is very fast.

00:10:27.526 --> 00:10:30.466 A:middle
It's almost as fast as if
you called addPersistentStore

00:10:30.466 --> 00:10:34.046 A:middle
on a store file without iCloud
options, so you shouldn't expect

00:10:34.046 --> 00:10:35.736 A:middle
to notice any interruption

00:10:35.786 --> 00:10:37.726 A:middle
in what your user sees
in the application.

00:10:39.096 --> 00:10:41.066 A:middle
You can then start working
with the storage just

00:10:41.066 --> 00:10:44.306 A:middle
as you normally would, and call
NSManagedObjectContext save

00:10:44.726 --> 00:10:45.956 A:middle
to make changes to
the iCloud store.

00:10:46.086 --> 00:10:50.196 A:middle
Now, once you've
handle this transition,

00:10:50.816 --> 00:10:53.936 A:middle
your application will be
fully up and running on iCloud

00:10:53.936 --> 00:10:54.896 A:middle
and you can expect that at

00:10:54.896 --> 00:10:57.456 A:middle
that point changes will be
available to other peers.

00:10:58.686 --> 00:11:01.866 A:middle
Now, I need to mention that
this is a special case scenario.

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

00:10:58.686 --> 00:11:01.866 A:middle
Now, I need to mention that
this is a special case scenario.

00:11:02.516 --> 00:11:04.686 A:middle
You will only see these
notifications during our

00:11:04.686 --> 00:11:06.146 A:middle
asynchronous setup process

00:11:06.656 --> 00:11:09.376 A:middle
if there is no persistent
store file on disk,

00:11:09.736 --> 00:11:11.846 A:middle
or there are has been a
change to the iCloud account

00:11:11.946 --> 00:11:14.836 A:middle
or the contents of the container
since we last launched.

00:11:15.776 --> 00:11:19.246 A:middle
Normally, you'll just start
seeing NSPersistentStore Did

00:11:19.246 --> 00:11:21.666 A:middle
Import Ubiquitous Content
Changes notification

00:11:22.056 --> 00:11:24.396 A:middle
which you can merge into
your managed object context

00:11:24.646 --> 00:11:26.986 A:middle
by using merged changes
from Context Did Save.

00:11:28.296 --> 00:11:30.956 A:middle
This is important to
realize because the goal

00:11:30.956 --> 00:11:33.906 A:middle
of our integration this year
for asynchronous setup was

00:11:33.906 --> 00:11:35.546 A:middle
to eliminate any work
that you had to do

00:11:35.546 --> 00:11:36.996 A:middle
by your application at all.

00:11:37.496 --> 00:11:41.516 A:middle
However, we're providing this
new transition paradigm as a way

00:11:41.516 --> 00:11:45.366 A:middle
of enabling you to have a
consistent implement once use

00:11:45.366 --> 00:11:47.706 A:middle
case that you only
have to pay attention

00:11:47.706 --> 00:11:49.056 A:middle
to for our integration.

00:11:49.636 --> 00:11:54.566 A:middle
And so with that, let's
take a look at changes

00:11:54.836 --> 00:11:57.456 A:middle
for how you handle changes
in the iCloud account.

00:11:58.776 --> 00:12:02.126 A:middle
Normally in iOS 6
and Mac OS X 10.8,

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

00:11:58.776 --> 00:12:02.126 A:middle
Normally in iOS 6
and Mac OS X 10.8,

00:12:02.696 --> 00:12:05.966 A:middle
when the iCloud account changes,
the only way to notice this is

00:12:05.966 --> 00:12:08.736 A:middle
by subscribing to the NS
UbiquityIdentityToken Did

00:12:08.736 --> 00:12:09.846 A:middle
Change notification.

00:12:10.976 --> 00:12:13.886 A:middle
When that happens, you have
to remove the persistent store

00:12:13.886 --> 00:12:17.846 A:middle
from the coordinator and then
replace it with a new one

00:12:18.566 --> 00:12:19.716 A:middle
to talk to the new account.

00:12:21.076 --> 00:12:24.906 A:middle
In code, this looks a
little bit like this.

00:12:25.776 --> 00:12:27.996 A:middle
You call NSManagedObjectContext
reset

00:12:27.996 --> 00:12:30.036 A:middle
and then remove persistent
store,

00:12:30.716 --> 00:12:33.726 A:middle
and then you call
NSPersistentStoreCoordinator

00:12:34.046 --> 00:12:37.246 A:middle
addPersistentStore to add the
new file to the coordinator

00:12:37.246 --> 00:12:40.826 A:middle
for use of the new account;
and this would work just fine

00:12:40.826 --> 00:12:43.296 A:middle
in iOS 7 and Mac OS X 10.9.

00:12:43.936 --> 00:12:46.946 A:middle
However, because we
control the fallback store

00:12:47.416 --> 00:12:49.076 A:middle
and because we have
a new integration

00:12:49.076 --> 00:12:51.656 A:middle
for asynchronous setup,
we thought that we might

00:12:51.656 --> 00:12:53.976 A:middle
as well extend that to
account changes, as well.

00:12:55.306 --> 00:12:58.906 A:middle
And so now, you'd no longer
have to subscribe to any

00:12:58.906 --> 00:13:00.556 A:middle
of the iCloud notifications
at all.

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

00:12:58.906 --> 00:13:00.556 A:middle
of the iCloud notifications
at all.

00:13:01.206 --> 00:13:04.096 A:middle
You simply implement your will
change handlers and respond

00:13:04.096 --> 00:13:06.886 A:middle
to NSPersistentStoreCoordinator
Stores Will Change

00:13:07.226 --> 00:13:09.616 A:middle
and will notify you
automatically when we need

00:13:09.616 --> 00:13:11.286 A:middle
to change the persistent
store file

00:13:11.556 --> 00:13:13.246 A:middle
because there's new
account on the system.

00:13:14.466 --> 00:13:17.456 A:middle
Of course, you can then call
NSManagedObjectContext save

00:13:17.886 --> 00:13:20.126 A:middle
and NSManagedObjectContext
reset.

00:13:20.956 --> 00:13:24.846 A:middle
Now once you've done that,
we'll remove the store

00:13:24.846 --> 00:13:26.426 A:middle
from the coordinator just

00:13:26.426 --> 00:13:28.396 A:middle
as with the asynchronous
setup process

00:13:29.346 --> 00:13:31.646 A:middle
and then we'll send you
NSPersistentStoreCoordinator

00:13:31.646 --> 00:13:34.226 A:middle
Storage Did Change
notification, again,

00:13:34.696 --> 00:13:38.056 A:middle
just like asynchronous setup
and you can begin working

00:13:38.056 --> 00:13:39.876 A:middle
with your application
as you normally would.

00:13:40.986 --> 00:13:44.356 A:middle
Now, let's talk about this
in a little bit more detail.

00:13:45.556 --> 00:13:48.106 A:middle
When you receive
NSPersistentStoreCoordinator

00:13:48.106 --> 00:13:49.976 A:middle
Stores Will Change notification,

00:13:50.446 --> 00:13:53.046 A:middle
the persistent store is
still available to use,

00:13:53.476 --> 00:13:57.306 A:middle
and so unlike what we advised
you of last year where you had

00:13:57.306 --> 00:13:59.966 A:middle
to immediately drop the
persistent store and wipe

00:13:59.966 --> 00:14:02.926 A:middle
out your managed object
context, you can still write

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

00:13:59.966 --> 00:14:02.926 A:middle
out your managed object
context, you can still write

00:14:02.926 --> 00:14:04.426 A:middle
to the managed object context

00:14:04.826 --> 00:14:07.036 A:middle
and those changes will
be persistent locally

00:14:07.376 --> 00:14:09.906 A:middle
to be imported to the account
if it every comes back.

00:14:10.776 --> 00:14:13.806 A:middle
This means that although your
user's changes won't make it

00:14:13.806 --> 00:14:16.466 A:middle
to iCloud immediately, if
they ever sign in again,

00:14:16.746 --> 00:14:20.736 A:middle
they'll be there and waiting.

00:14:20.866 --> 00:14:22.246 A:middle
Another thing you should know is

00:14:22.246 --> 00:14:24.746 A:middle
that once you receive
NSPersistentStoreCoordinator

00:14:24.746 --> 00:14:26.606 A:middle
Storage Did Change notification,

00:14:27.666 --> 00:14:32.146 A:middle
the store file may no longer be
available to you to use on disk.

00:14:32.886 --> 00:14:35.796 A:middle
This is because Core Data
automatically manages all

00:14:35.796 --> 00:14:37.626 A:middle
of the stores associated
with the account.

00:14:38.956 --> 00:14:42.256 A:middle
You provide us a single store
URL inside the application's

00:14:42.256 --> 00:14:46.106 A:middle
local sandbox and we then
create an opaque container

00:14:46.706 --> 00:14:49.546 A:middle
with an entry inside of it for
each account on the system,

00:14:50.526 --> 00:14:53.646 A:middle
including the local
account, which is our term

00:14:53.646 --> 00:14:56.726 A:middle
for what happens when there is
no iCloud account on the system.

00:14:58.026 --> 00:15:01.006 A:middle
This is a special store
that's managed by Core Data

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

00:14:58.026 --> 00:15:01.006 A:middle
This is a special store
that's managed by Core Data

00:15:01.006 --> 00:15:02.766 A:middle
so that you don't have
to do anything special

00:15:02.766 --> 00:15:05.406 A:middle
because your user doesn't
have an iCloud account.

00:15:06.276 --> 00:15:07.436 A:middle
How does this work?

00:15:08.656 --> 00:15:12.736 A:middle
Well, you give us a store URL
somewhere inside the application

00:15:13.346 --> 00:15:18.236 A:middle
samples, and we chop
that up and put

00:15:18.236 --> 00:15:20.686 A:middle
in a special root directory
called Core Data Ubiquity

00:15:20.686 --> 00:15:24.456 A:middle
Support, followed by a
directory tree that allows us

00:15:24.456 --> 00:15:31.336 A:middle
to uniquely identify each store
and tie it into an account.

00:15:31.516 --> 00:15:32.876 A:middle
Now for simplicity's sake,

00:15:33.356 --> 00:15:35.646 A:middle
we've kept the persistent
store file name the same

00:15:35.646 --> 00:15:36.986 A:middle
as the one you pass into us

00:15:37.676 --> 00:15:40.006 A:middle
so that you can identify
the store files inside

00:15:40.006 --> 00:15:44.246 A:middle
of this container
if you need to.

00:15:44.386 --> 00:15:47.406 A:middle
Finally, all of these
store files will be managed

00:15:47.406 --> 00:15:49.216 A:middle
by Core Data and that means

00:15:49.216 --> 00:15:51.206 A:middle
that we could remove
them at any time.

00:15:52.946 --> 00:15:57.016 A:middle
Each store will be removed
once its account has gone away

00:15:57.506 --> 00:16:00.006 A:middle
because we can rebuild
the file from the cloud.

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

00:15:57.506 --> 00:16:00.006 A:middle
because we can rebuild
the file from the cloud.

00:16:00.366 --> 00:16:02.716 A:middle
So we want to free up as
much disk space as possible

00:16:02.716 --> 00:16:05.966 A:middle
for your application to use and
not have old store files lying

00:16:05.966 --> 00:16:08.346 A:middle
around that could take
up additional resources.

00:16:08.646 --> 00:16:12.966 A:middle
And so that's our
changes to the account.

00:16:14.996 --> 00:16:17.366 A:middle
So now let's talk
about some new API

00:16:17.366 --> 00:16:18.836 A:middle
that we're introducing
this year.

00:16:20.326 --> 00:16:25.286 A:middle
I'm sure you recognized
this line of code.

00:16:26.746 --> 00:16:30.026 A:middle
This calls NSFileManager's
URLForUbiquitous

00:16:30.026 --> 00:16:33.096 A:middle
ContainerIdentifier
method, and it allows you

00:16:33.096 --> 00:16:35.746 A:middle
to get the URL inside
of the iCloud container

00:16:36.216 --> 00:16:38.676 A:middle
where your application can
store files and write data.

00:16:40.546 --> 00:16:44.416 A:middle
However as you may know, when
you change iCloud accounts,

00:16:44.476 --> 00:16:46.606 A:middle
this method can take a
little while to return,

00:16:47.476 --> 00:16:49.966 A:middle
and so we couldn't provide
you a truly seamless

00:16:49.966 --> 00:16:52.926 A:middle
and fast integration without
a eliminating the need

00:16:52.926 --> 00:16:53.746 A:middle
for you to call it.

00:16:54.816 --> 00:16:57.796 A:middle
Normally, you take the value
from this method and pass it

00:16:57.866 --> 00:17:00.686 A:middle
to us and as an option
called NSPersistentStore

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

00:16:57.866 --> 00:17:00.686 A:middle
to us and as an option
called NSPersistentStore

00:17:00.836 --> 00:17:04.896 A:middle
UbiquitousContentURLKey,
and this is how we know

00:17:04.896 --> 00:17:07.366 A:middle
where to keep all of your
data in the iCloud account.

00:17:08.425 --> 00:17:12.185 A:middle
So in iOS 7 and Mac OS X
10.9, you'll no longer need

00:17:12.185 --> 00:17:16.986 A:middle
to pass a value for that at all,

00:17:16.986 --> 00:17:19.746 A:middle
and we'll call URLForUbiquitous
ContainerIdentifier

00:17:19.996 --> 00:17:21.536 A:middle
automatically under
the hood for you.

00:17:22.646 --> 00:17:24.406 A:middle
Now as you may remember,

00:17:24.665 --> 00:17:27.336 A:middle
our advice in past
years has always been

00:17:27.336 --> 00:17:30.436 A:middle
that you should keep our
transaction log content inside

00:17:30.436 --> 00:17:32.426 A:middle
of a special subdirectory
in the container,

00:17:33.696 --> 00:17:36.266 A:middle
and you may be wondering
how it is that we'll know

00:17:36.266 --> 00:17:39.686 A:middle
where to find this if you're
not passing a URL into us.

00:17:40.546 --> 00:17:41.036 A:middle
Well,

00:17:41.806 --> 00:17:46.756 A:middle
NSPersistentStoreUbiquitous
ContentURLKey now takes a string

00:17:46.756 --> 00:17:48.266 A:middle
subpath, as well.

00:17:48.836 --> 00:17:53.006 A:middle
This is optional, but if your
application already exists

00:17:53.006 --> 00:17:55.516 A:middle
in iCloud and you have
a special subdirectory

00:17:55.516 --> 00:17:57.286 A:middle
where you've been keeping
all of our content,

00:17:57.836 --> 00:18:00.326 A:middle
you need to pass this
value in so we can find it.

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

00:17:57.836 --> 00:18:00.326 A:middle
you need to pass this
value in so we can find it.

00:18:00.936 --> 00:18:03.186 A:middle
Otherwise, we'll
create our own value

00:18:03.186 --> 00:18:05.316 A:middle
by default called
Core Data Support.

00:18:05.906 --> 00:18:08.796 A:middle
This is a special directory we
create in your iCloud account

00:18:09.216 --> 00:18:11.586 A:middle
and store all of our
transaction log content in.

00:18:12.126 --> 00:18:13.966 A:middle
One of our main goals
this year is

00:18:13.966 --> 00:18:18.216 A:middle
to provide a very simple
integration; and that means

00:18:18.216 --> 00:18:21.336 A:middle
that we really need to consider
all of the cases of applications

00:18:21.426 --> 00:18:22.626 A:middle
that are going to
be in use with it.

00:18:23.416 --> 00:18:26.186 A:middle
So this year, we're
introducing NSPersistentStore

00:18:26.186 --> 00:18:30.216 A:middle
UbiquitousContainerIdentifier
key as a way for applications

00:18:30.216 --> 00:18:32.706 A:middle
that have multiple iCloud
container identifiers

00:18:32.706 --> 00:18:36.216 A:middle
in their entitlements.plist to
tell us which one they want us

00:18:36.216 --> 00:18:38.806 A:middle
to use when we call
URLForUbiquitous

00:18:38.806 --> 00:18:39.936 A:middle
ContainerIdentifier.

00:18:40.666 --> 00:18:42.666 A:middle
So how does this work?

00:18:43.526 --> 00:18:47.236 A:middle
Well, if you're application has
multiple container identifiers

00:18:47.236 --> 00:18:50.436 A:middle
in its entitlements.plist,
by default,

00:18:50.816 --> 00:18:53.636 A:middle
NSFileManagerURLFor
UbiquitousContainerIdentifier

00:18:53.636 --> 00:18:56.116 A:middle
will select the first
one if pass No.

00:18:56.996 --> 00:18:58.756 A:middle
However, if you want
to use something

00:18:58.756 --> 00:19:02.116 A:middle
that isn't the first one, you
need to pass us this option

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

00:18:58.756 --> 00:19:02.116 A:middle
that isn't the first one, you
need to pass us this option

00:19:02.116 --> 00:19:03.836 A:middle
so that we know which
one to use,

00:19:04.236 --> 00:19:06.326 A:middle
and this value will
be passed directly

00:19:06.496 --> 00:19:08.706 A:middle
to URLForUbiquitous
ContainerIdentifier

00:19:08.706 --> 00:19:11.146 A:middle
under the hood.

00:19:11.306 --> 00:19:16.016 A:middle
We're also trying to help you
manage iCloud content and for

00:19:16.016 --> 00:19:19.156 A:middle
that reason we're introducing
NSPersistentStore Rebuild

00:19:19.156 --> 00:19:20.706 A:middle
From Ubiquitous Content option.

00:19:21.546 --> 00:19:23.236 A:middle
This is an option
that allows you

00:19:23.596 --> 00:19:25.866 A:middle
to remove the persistent
store file on disk

00:19:26.146 --> 00:19:28.466 A:middle
and examine what happens
when we rebuild it

00:19:28.466 --> 00:19:29.706 A:middle
from the iCloud content.

00:19:30.446 --> 00:19:33.766 A:middle
It's important that you know
addPersistentStore will always

00:19:33.766 --> 00:19:36.176 A:middle
return an empty store
when you pass this option,

00:19:36.716 --> 00:19:38.346 A:middle
that's because we need to switch

00:19:38.346 --> 00:19:41.976 A:middle
over to the fallback store
while we -- excuse me --

00:19:42.636 --> 00:19:45.186 A:middle
while we rebuild
the iCloud store

00:19:45.186 --> 00:19:47.626 A:middle
from the transaction log
content in the cloud.

00:19:47.626 --> 00:19:50.766 A:middle
So how does this work?

00:19:51.096 --> 00:19:52.686 A:middle
Well, you just pass it --

00:19:52.906 --> 00:19:53.396 A:middle
pass us a [inaudible]

00:19:53.396 --> 00:19:57.016 A:middle
that evaluates TS inside
the options dictionary,

00:19:57.166 --> 00:19:59.256 A:middle
and we go off and
replace the store file

00:19:59.256 --> 00:20:00.976 A:middle
with one that's freshly
built from the cloud.

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

00:19:59.256 --> 00:20:00.976 A:middle
with one that's freshly
built from the cloud.

00:20:03.116 --> 00:20:05.056 A:middle
We're also introducing
a new option

00:20:05.056 --> 00:20:08.426 A:middle
to help you create
backups or local copies

00:20:08.426 --> 00:20:12.556 A:middle
of the iCloud persistent store
called NSPersistentStore Remove

00:20:12.556 --> 00:20:14.116 A:middle
Ubiquitous Metadata Option.

00:20:14.806 --> 00:20:18.246 A:middle
This removes all associated
metadata from the iCloud store;

00:20:18.436 --> 00:20:19.836 A:middle
that means, anything
that we write

00:20:19.836 --> 00:20:23.046 A:middle
into the metadata dictionary as
well as the store file itself,

00:20:23.576 --> 00:20:26.526 A:middle
and it's critical if you
want to use the migration API

00:20:27.036 --> 00:20:28.996 A:middle
to create backups
or local copies

00:20:28.996 --> 00:20:30.916 A:middle
at a persistent store
you wish to open

00:20:30.916 --> 00:20:32.386 A:middle
without the iCloud options.

00:20:34.296 --> 00:20:37.586 A:middle
Finally, we're adding
a class method

00:20:37.666 --> 00:20:41.126 A:middle
to NSPersistentStoreCoordinator
which removes all

00:20:41.126 --> 00:20:44.546 A:middle
of the iCloud content and the
persistent store files on disk.

00:20:45.286 --> 00:20:47.956 A:middle
This is our way of providing
you with a clean slate.

00:20:48.686 --> 00:20:51.736 A:middle
If you call this method, we
will go into the iCloud account

00:20:51.736 --> 00:20:53.926 A:middle
and delete all of the
content associated

00:20:53.926 --> 00:20:55.376 A:middle
with a given persistent store.

00:20:56.266 --> 00:20:59.786 A:middle
You pass us the store URL
and the options dictionary

00:20:59.786 --> 00:21:03.276 A:middle
that you normally pass so that
we can correctly identify the

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

00:20:59.786 --> 00:21:03.276 A:middle
that you normally pass so that
we can correctly identify the

00:21:03.276 --> 00:21:05.586 A:middle
store and its content
in the iCloud account.

00:21:06.656 --> 00:21:08.486 A:middle
Now, I can't over
state this enough.

00:21:08.866 --> 00:21:10.306 A:middle
This is our clean slate.

00:21:10.836 --> 00:21:14.076 A:middle
If you call this method, none
of the data will remain on disk

00:21:14.336 --> 00:21:17.096 A:middle
or in the iCloud account that's
associated with a given store,

00:21:17.826 --> 00:21:20.726 A:middle
but it is the easiest way
for you to start over.

00:21:21.666 --> 00:21:24.846 A:middle
And because of that, we've
made this method synchronous.

00:21:25.566 --> 00:21:28.386 A:middle
There is a significant amount
of network I/O that it has to do

00:21:28.386 --> 00:21:32.316 A:middle
under the hood when it talks
to iCloud, and because of this,

00:21:32.466 --> 00:21:34.496 A:middle
it may take a little
while to run.

00:21:34.886 --> 00:21:36.746 A:middle
However, you can't work

00:21:36.746 --> 00:21:39.226 A:middle
with a persistent store
until it's finished.

00:21:40.086 --> 00:21:41.986 A:middle
And so, it will be synchronous

00:21:42.146 --> 00:21:43.766 A:middle
and once it returns
successfully,

00:21:44.376 --> 00:21:45.676 A:middle
you can work with a store again.

00:21:46.956 --> 00:21:47.856 A:middle
How does this work?

00:21:48.906 --> 00:21:52.556 A:middle
Well, you'll have some content
and a persistent store file

00:21:52.556 --> 00:21:56.566 A:middle
on disk and we'll erase the
persistent store file first

00:21:57.266 --> 00:22:00.566 A:middle
and then nuke the
iCloud content, as well.

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

00:21:57.266 --> 00:22:00.566 A:middle
and then nuke the
iCloud content, as well.

00:22:01.276 --> 00:22:03.846 A:middle
And we have some special
integration under the hood

00:22:03.846 --> 00:22:06.726 A:middle
to make sure that this is
robust and reliable as possible.

00:22:08.206 --> 00:22:12.226 A:middle
It actually only requires
one I/O operation with iCloud

00:22:12.226 --> 00:22:14.546 A:middle
to propagate the delete
to all of your devices

00:22:15.006 --> 00:22:18.746 A:middle
and that makes it very
fast and very robust,

00:22:18.746 --> 00:22:21.076 A:middle
but we still recommend
that you only do it

00:22:21.076 --> 00:22:22.716 A:middle
when you have a good
network connection

00:22:23.106 --> 00:22:25.596 A:middle
such as an Ethernet
connection from a Mac.

00:22:25.596 --> 00:22:28.466 A:middle
It works just fine on
iOS devices, however,

00:22:28.466 --> 00:22:32.016 A:middle
if the connection isn't great
or iCloud isn't available

00:22:32.016 --> 00:22:34.566 A:middle
on that device, you won't
see the change propagate

00:22:34.566 --> 00:22:38.786 A:middle
for quite some time.

00:22:38.996 --> 00:22:40.256 A:middle
Now as you've already seen,

00:22:40.616 --> 00:22:43.386 A:middle
we're introducing a new
notification this year called

00:22:43.416 --> 00:22:45.916 A:middle
NSPersistentStoreCoordinator
Storage Will Change

00:22:45.916 --> 00:22:48.666 A:middle
notification, and
this only applies

00:22:48.666 --> 00:22:50.406 A:middle
to iCloud persistent stores.

00:22:50.896 --> 00:22:53.386 A:middle
You won't see it with any
other type of persistent store

00:22:53.386 --> 00:22:56.786 A:middle
on the system as it's our
way of creating a consistent

00:22:56.996 --> 00:22:58.446 A:middle
and reusable paradigm

00:22:58.826 --> 00:23:01.166 A:middle
for handling transition
events related to iCloud.

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

00:22:58.826 --> 00:23:01.166 A:middle
for handling transition
events related to iCloud.

00:23:02.736 --> 00:23:05.346 A:middle
The user info dictionary
will contain instances

00:23:05.346 --> 00:23:08.906 A:middle
of NSPersistentStore that
identify the iCloud store that's

00:23:08.906 --> 00:23:13.876 A:middle
about to change, and you
can subscribe to it just

00:23:13.876 --> 00:23:15.256 A:middle
like any other notification.

00:23:15.786 --> 00:23:18.676 A:middle
We recommend that you scope
this using the persistent store

00:23:18.676 --> 00:23:21.056 A:middle
coordinator that your
application uses to talk

00:23:21.056 --> 00:23:24.716 A:middle
to iCloud as the object when you
subscribe to the notification.

00:23:25.576 --> 00:23:27.306 A:middle
As well, you should subscribe

00:23:27.306 --> 00:23:30.676 A:middle
to NSPersistentStoreCoordinator
Storage Did Change method --

00:23:31.016 --> 00:23:34.526 A:middle
or, sorry -- Storage Did
Change notification and scope

00:23:34.526 --> 00:23:36.846 A:middle
that by the persistent
store coordinator, as well.

00:23:38.106 --> 00:23:39.976 A:middle
And this is because
the implementation

00:23:39.976 --> 00:23:43.116 A:middle
of your Did Change handler will
probably be slightly different

00:23:43.116 --> 00:23:45.116 A:middle
for the iCloud store
than it will

00:23:45.116 --> 00:23:47.466 A:middle
for the other persistent
stores on your system.

00:23:48.966 --> 00:23:51.206 A:middle
So let's take a look at
those notification handlers.

00:23:52.366 --> 00:23:54.846 A:middle
Now, I mentioned earlier that
our goal for this year was

00:23:54.846 --> 00:23:56.766 A:middle
to provide a very
simple integration

00:23:57.116 --> 00:23:59.686 A:middle
that significantly reduced
the amount of complex code

00:23:59.686 --> 00:24:00.906 A:middle
that developers have to write.

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

00:23:59.686 --> 00:24:00.906 A:middle
that developers have to write.

00:24:01.726 --> 00:24:04.836 A:middle
And so, with the Will
Change notification,

00:24:05.326 --> 00:24:08.146 A:middle
we've tried to make it as easy
possible to get up and running

00:24:08.626 --> 00:24:11.156 A:middle
and all you have to
do is optionally call

00:24:11.156 --> 00:24:12.916 A:middle
NSManagedObjectContext Save

00:24:12.916 --> 00:24:15.596 A:middle
and then NSManagedObjectContext
reset.

00:24:16.046 --> 00:24:18.716 A:middle
This will completely prepare
your application for use

00:24:18.956 --> 00:24:20.156 A:middle
with the new iCloud store.

00:24:20.236 --> 00:24:24.426 A:middle
Of course, you may have some
custom code you need to run

00:24:24.606 --> 00:24:26.536 A:middle
to prepare your user
interface for this.

00:24:27.136 --> 00:24:28.016 A:middle
Now as I mentioned,

00:24:28.016 --> 00:24:30.146 A:middle
this transition will
happen fairly quickly

00:24:30.596 --> 00:24:33.706 A:middle
and so you should not need to
block your UI while you wait

00:24:33.706 --> 00:24:35.586 A:middle
for the store file
to be swapped out.

00:24:35.856 --> 00:24:38.466 A:middle
However, you may wish to
prevent the user from trying

00:24:38.466 --> 00:24:41.586 A:middle
to write new data to disk
such as blocking a Save button

00:24:42.606 --> 00:24:45.716 A:middle
which you can then enable inside
of the Did Change handler.

00:24:46.516 --> 00:24:49.996 A:middle
And as you can see, this
is only a handful of code.

00:24:50.256 --> 00:24:52.156 A:middle
In fact, most of the
sample applications

00:24:52.156 --> 00:24:55.616 A:middle
that we use internally
have completely changed

00:24:55.926 --> 00:24:59.656 A:middle
by reducing a ton of code to
just a few lines to integrate

00:24:59.656 --> 00:25:00.986 A:middle
with our iCloud integration.

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

00:24:59.656 --> 00:25:00.986 A:middle
with our iCloud integration.

00:25:00.986 --> 00:25:03.376 A:middle
And so that's all
for the new API.

00:25:03.376 --> 00:25:07.556 A:middle
Let's talk a little bit
about how things have changed

00:25:07.556 --> 00:25:11.366 A:middle
for living on iCloud and
iOS 7 and Mac OS X 10.9.

00:25:12.016 --> 00:25:14.136 A:middle
There have been a number
of substantial improvements

00:25:14.136 --> 00:25:16.956 A:middle
to the developer tools and
frameworks that are available

00:25:16.956 --> 00:25:20.266 A:middle
to you as well as the underlying
infrastructure related

00:25:20.266 --> 00:25:20.706 A:middle
to iCloud.

00:25:21.436 --> 00:25:24.446 A:middle
Perhaps one of the most
significant is Xcode's new

00:25:24.586 --> 00:25:25.756 A:middle
iCloud Debugging pane.

00:25:26.066 --> 00:25:29.066 A:middle
This is a pane that
automatically runs inside

00:25:29.066 --> 00:25:31.626 A:middle
of the debugger when your
application uses iCloud,

00:25:32.116 --> 00:25:34.936 A:middle
and you can see the amount
of storage space you consumed

00:25:35.266 --> 00:25:38.406 A:middle
as well as the status of a given
iCloud account whether it's

00:25:38.406 --> 00:25:41.826 A:middle
idle, uploading,
downloading, or actively working

00:25:41.826 --> 00:25:42.826 A:middle
to set up the account.

00:25:43.896 --> 00:25:47.526 A:middle
But I think the real gem here
is the file transfer graph.

00:25:48.086 --> 00:25:50.726 A:middle
This shows all of the
activity on the iCloud account,

00:25:50.896 --> 00:25:52.656 A:middle
both uploads and downloads,

00:25:53.036 --> 00:25:56.286 A:middle
and so you can see any activity
that's generated on your behalf

00:25:56.596 --> 00:25:58.796 A:middle
by the Core Data
integration under the hood.

00:25:59.136 --> 00:26:02.016 A:middle
You can also see a list of
every single file inside the

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

00:25:59.136 --> 00:26:02.016 A:middle
You can also see a list of
every single file inside the

00:26:02.016 --> 00:26:04.526 A:middle
container, including
our hidden directories

00:26:04.526 --> 00:26:07.666 A:middle
and special files that's in use
by the Core Data integration;

00:26:08.156 --> 00:26:12.336 A:middle
and as you can see, the
status of each file is printed

00:26:12.766 --> 00:26:13.886 A:middle
in the column to the right.

00:26:14.566 --> 00:26:15.796 A:middle
This will let you know whether

00:26:15.796 --> 00:26:19.016 A:middle
or not a file is what
we call current on disk,

00:26:19.396 --> 00:26:21.806 A:middle
meaning that it has been
downloaded and is available

00:26:21.806 --> 00:26:23.526 A:middle
to the Core Data
integration to use.

00:26:23.986 --> 00:26:26.776 A:middle
And so if you're looking through
our transaction log directories,

00:26:27.076 --> 00:26:30.076 A:middle
you can actually see whether
or not files from other peers

00:26:30.336 --> 00:26:32.746 A:middle
that were changed recently
have been downloaded

00:26:32.746 --> 00:26:34.426 A:middle
and are available
to us to import.

00:26:35.156 --> 00:26:36.316 A:middle
So this can be a big help

00:26:36.316 --> 00:26:38.946 A:middle
when you're wondering why you're
not seeing NSPersistentStore

00:26:38.946 --> 00:26:42.116 A:middle
Ubiquitous Content Changes
notification without having

00:26:42.116 --> 00:26:43.316 A:middle
to enable a ton of logging.

00:26:45.496 --> 00:26:48.956 A:middle
The iOS simulator also
now fully supports iCloud.

00:26:49.626 --> 00:26:52.206 A:middle
You can use the same
account with your application

00:26:52.206 --> 00:26:55.116 A:middle
that you're using on your Mac
or a completely different one,

00:26:55.646 --> 00:26:58.036 A:middle
and this allows you to
test iCloud integration

00:26:58.036 --> 00:27:00.016 A:middle
without having to change
settings on your Mac.

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

00:26:58.036 --> 00:27:00.016 A:middle
without having to change
settings on your Mac.

00:27:00.586 --> 00:27:05.806 A:middle
As well, you can also test sync
between a Mac and an iOS device

00:27:06.006 --> 00:27:09.546 A:middle
without actually connecting
to any devices, and to me,

00:27:09.546 --> 00:27:11.756 A:middle
this is a huge advantage
because it allows you

00:27:11.756 --> 00:27:15.006 A:middle
to evaluate your cross-platform
integration without having

00:27:15.006 --> 00:27:16.776 A:middle
to worry about carrying
devices with you.

00:27:17.336 --> 00:27:20.686 A:middle
It fully supports
iCloud document storage

00:27:21.136 --> 00:27:23.946 A:middle
and the iCloud key
value store, as well,

00:27:23.946 --> 00:27:26.836 A:middle
you'll also receive support
for pushing notifications now

00:27:26.836 --> 00:27:27.646 A:middle
in the simulator [applause].

00:27:28.016 --> 00:27:30.296 A:middle
[Laughter] Thank you.

00:27:33.086 --> 00:27:34.566 A:middle
But it wouldn't be
a Core Data session

00:27:34.566 --> 00:27:36.336 A:middle
if I didn't tell
you about logging.

00:27:37.256 --> 00:27:40.446 A:middle
Now, all of this has existed
in our iCode integration

00:27:40.446 --> 00:27:41.706 A:middle
for the last couple of years.

00:27:42.266 --> 00:27:46.866 A:middle
But, in iOS 7 and Mac OS X 10.9,
we've made it possible for you

00:27:46.866 --> 00:27:49.676 A:middle
to enable the logging by
setting a user default inside

00:27:49.676 --> 00:27:50.506 A:middle
your application.

00:27:51.146 --> 00:27:52.716 A:middle
Of course, you can still pass it

00:27:52.716 --> 00:27:56.686 A:middle
as a launch argument
using com.apple.coredata.

00:27:56.686 --> 00:27:58.056 A:middle
ubiquity.logLevel.

00:27:58.476 --> 00:28:01.026 A:middle
Number 3 is the highest,
so if you turn that up,

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

00:27:58.476 --> 00:28:01.026 A:middle
Number 3 is the highest,
so if you turn that up,

00:28:01.086 --> 00:28:02.716 A:middle
expect to get a lot of logs.

00:28:03.016 --> 00:28:07.176 A:middle
Of course, we also have
com.apple.CoreData.SQLDebug

00:28:07.506 --> 00:28:09.466 A:middle
which allows us to
see what activity

00:28:09.466 --> 00:28:13.406 A:middle
and what SQL we're generating
when you use the iCloud store.

00:28:13.986 --> 00:28:16.106 A:middle
And I have to mention that
if you're having problems

00:28:16.106 --> 00:28:19.806 A:middle
with iCloud related to your
local managed object context

00:28:19.806 --> 00:28:22.476 A:middle
that is the one that's in
use by your persistent store,

00:28:22.846 --> 00:28:25.246 A:middle
this is a critical tool
for us to help you debug

00:28:25.246 --> 00:28:29.266 A:middle
that because we need to see what
activity your store is at --

00:28:29.266 --> 00:28:32.476 A:middle
or, sorry, your managed object
context is actually attempting

00:28:32.476 --> 00:28:34.866 A:middle
to do in relation
to the iCloud store.

00:28:34.866 --> 00:28:38.846 A:middle
Of course, you can pass
both of these arguments

00:28:38.846 --> 00:28:41.916 A:middle
as a launch argument
through application inside

00:28:41.916 --> 00:28:43.126 A:middle
of Xcode scheme editor.

00:28:43.706 --> 00:28:46.826 A:middle
There have also been
improvements

00:28:46.826 --> 00:28:50.196 A:middle
to the underlying logging
system related to iCloud itself.

00:28:50.196 --> 00:28:55.016 A:middle
On OS X, we're introducing a new
tool this year called ubcontrol,

00:28:55.016 --> 00:28:57.776 A:middle
and ubcontrol interface
is directly

00:28:57.776 --> 00:28:59.966 A:middle
with the underlying
daemons that talk to iCloud.

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

00:29:00.946 --> 00:29:03.426 A:middle
It allows you to do things
like enable debug logging

00:29:04.396 --> 00:29:08.096 A:middle
and you do this by
calling ubcontrol-k7.

00:29:08.836 --> 00:29:12.316 A:middle
Now, 7 is the highest
logging level that they allow

00:29:12.676 --> 00:29:15.936 A:middle
and it's what we need to debug
any iCloud issues related

00:29:15.936 --> 00:29:18.116 A:middle
to the actual file
transfer on the system.

00:29:18.686 --> 00:29:22.296 A:middle
So if you see a bug, enable
this, reproduce the issue

00:29:22.486 --> 00:29:23.506 A:middle
and then follow radar.

00:29:23.506 --> 00:29:28.276 A:middle
Of course, on iOS, we still have
the iCloud Debug Provisioning

00:29:28.276 --> 00:29:30.286 A:middle
profile and this is available

00:29:30.286 --> 00:29:32.826 A:middle
from developer.apple.com
as a download.

00:29:34.136 --> 00:29:37.146 A:middle
You can download and unzip
this file on your Mac

00:29:37.476 --> 00:29:38.966 A:middle
and then email it yourself.

00:29:39.376 --> 00:29:41.836 A:middle
Finally, on iOS, open the email.

00:29:43.016 --> 00:29:44.536 A:middle
Follow the onscreen instructions

00:29:44.686 --> 00:29:47.906 A:middle
and then reboot the device
once the profile is installed.

00:29:48.776 --> 00:29:50.596 A:middle
It's critical that
you reboot your device

00:29:50.726 --> 00:29:52.766 A:middle
because this is what
restarts all of the daemons

00:29:52.766 --> 00:29:54.766 A:middle
on your iOS device
that talk to iCloud.

00:29:55.296 --> 00:29:57.846 A:middle
Without it, they won't pick
up the new logging level.

00:29:58.486 --> 00:29:59.966 A:middle
Once you've reproduced
the issue,

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

00:30:00.676 --> 00:30:02.946 A:middle
you should sync your
device directly with iTunes

00:30:03.626 --> 00:30:04.766 A:middle
and then gather the logs

00:30:04.766 --> 00:30:08.746 A:middle
from Library/Logs/CrashReporter
/MobileDevice

00:30:08.956 --> 00:30:12.366 A:middle
and then the device name
and diagnostic logs,

00:30:12.696 --> 00:30:14.266 A:middle
and you can file a
bug with those in it

00:30:14.266 --> 00:30:14.976 A:middle
and we'll take a look.

00:30:16.156 --> 00:30:19.106 A:middle
Now, I want to talk for a
minute just about filing bugs.

00:30:19.776 --> 00:30:22.686 A:middle
We received a lot of bug reports
from you over the last year

00:30:22.936 --> 00:30:24.126 A:middle
and this has been critical

00:30:24.126 --> 00:30:26.186 A:middle
in not only helping us
scope our integration

00:30:26.696 --> 00:30:29.506 A:middle
but also decide what areas
of improvement we can provide

00:30:29.506 --> 00:30:31.536 A:middle
to you that will
have the most value.

00:30:32.306 --> 00:30:36.596 A:middle
So when you file bugs, please,
please, please include all

00:30:36.596 --> 00:30:39.446 A:middle
of the logs that you
can, and if possible,

00:30:39.446 --> 00:30:41.226 A:middle
your local persistent
store files

00:30:41.526 --> 00:30:44.536 A:middle
because this helps us get all
the information that we need

00:30:44.856 --> 00:30:46.766 A:middle
to identify the issue
that you're running into.

00:30:47.896 --> 00:30:51.386 A:middle
So with that, I'd like to
bring Melissa Turner up

00:30:51.656 --> 00:30:54.276 A:middle
and she'll take you through some
demos of a few other changes

00:30:54.276 --> 00:30:55.166 A:middle
that we've made this year.

00:30:57.516 --> 00:31:02.186 A:middle
[ Applause ]

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

00:30:57.516 --> 00:31:02.186 A:middle
[ Applause ]

00:31:02.686 --> 00:31:03.836 A:middle
>> Melissa Turner:
I'm Melissa Turner.

00:31:03.836 --> 00:31:05.416 A:middle
I'm one of the Core
Data engineers,

00:31:06.086 --> 00:31:09.746 A:middle
and I totally thought I was
going to go out talking on stage

00:31:09.746 --> 00:31:12.306 A:middle
at WWDC this year until
a couple of weeks ago

00:31:12.306 --> 00:31:14.766 A:middle
when my manager came to me
and said, "Hey, Melissa,

00:31:15.386 --> 00:31:17.086 A:middle
you totally are the
one who's going

00:31:17.086 --> 00:31:18.856 A:middle
to see all the weird
esoteric bugs

00:31:18.856 --> 00:31:20.066 A:middle
that nobody else
is going to hit.

00:31:20.306 --> 00:31:23.966 A:middle
I want you to do a demo,
take one for the team."

00:31:24.316 --> 00:31:24.976 A:middle
So here we are.

00:31:26.236 --> 00:31:26.956 A:middle
We'll do it this way.

00:31:27.046 --> 00:31:30.596 A:middle
If my demo fails gloriously
on stage, I'll have found bugs

00:31:30.596 --> 00:31:34.246 A:middle
that we will then not be
shipping to you, guys.

00:31:34.246 --> 00:31:37.246 A:middle
OK. So here we have
a little application;

00:31:37.376 --> 00:31:39.156 A:middle
it's a note-taking application.

00:31:39.156 --> 00:31:40.046 A:middle
I'm going to add a note.

00:31:40.046 --> 00:31:44.186 A:middle
I need to add another note.

00:31:46.496 --> 00:31:47.376 A:middle
It's pretty simple.

00:31:48.306 --> 00:31:52.006 A:middle
Not much to see here,
but as important

00:31:52.006 --> 00:31:54.776 A:middle
as what you're seeing is,

00:31:55.206 --> 00:31:57.256 A:middle
what's more important is
what you're not seeing.

00:31:57.256 --> 00:32:02.926 A:middle
And what you're not seeing
here is, well, a hang as I wait

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

00:31:57.256 --> 00:32:02.926 A:middle
And what you're not seeing
here is, well, a hang as I wait

00:32:02.926 --> 00:32:07.796 A:middle
for addPersistentStore to return
with my ubiquitized store.

00:32:09.366 --> 00:32:12.666 A:middle
You can see that as I
was sitting there waiting

00:32:12.666 --> 00:32:14.816 A:middle
and as I was talking to
you, as I was working

00:32:14.816 --> 00:32:18.026 A:middle
with that responsive UI,
our iCloud integration off

00:32:18.026 --> 00:32:20.306 A:middle
in the background was going
off and fetching information

00:32:20.306 --> 00:32:22.566 A:middle
about our lab times today
-- for the next week.

00:32:22.996 --> 00:32:25.326 A:middle
So, you can see as Nick said,

00:32:25.326 --> 00:32:27.756 A:middle
this is the asynchronous
store setup.

00:32:27.926 --> 00:32:30.936 A:middle
We've made things a lot better,
a lot smoother, a lot easier

00:32:30.936 --> 00:32:36.086 A:middle
for you, guys --
one line of code.

00:32:36.286 --> 00:32:38.796 A:middle
So, because I'm me and
this is a demo on stage,

00:32:38.796 --> 00:32:41.196 A:middle
there was a good potential
something was going to go wrong

00:32:41.196 --> 00:32:43.196 A:middle
and I was going to
have to come in here

00:32:43.196 --> 00:32:45.716 A:middle
and try debugging whatever
had gone wrong on stage.

00:32:46.216 --> 00:32:51.176 A:middle
So this is, as Nick said,
the iCloud Debugging pane

00:32:51.226 --> 00:32:52.776 A:middle
and it comes up whenever
you are trying

00:32:52.776 --> 00:32:54.756 A:middle
to debug an application
that uses iCloud.

00:32:55.366 --> 00:32:58.396 A:middle
The top left-hand side, you
can see some information

00:32:58.396 --> 00:33:01.546 A:middle
about your application and
about your iCloud status.

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

00:32:58.396 --> 00:33:01.546 A:middle
about your application and
about your iCloud status.

00:33:02.096 --> 00:33:04.466 A:middle
If you bring up this pane when
you're running an application

00:33:04.466 --> 00:33:06.426 A:middle
and all you see is the
little cloud on the left

00:33:06.646 --> 00:33:09.266 A:middle
and a thing saying,
"iCloud not enabled," well,

00:33:10.006 --> 00:33:11.686 A:middle
that would be why you're
not seeing any of the data

00:33:11.686 --> 00:33:13.246 A:middle
that you're expecting
to see from the cloud

00:33:13.396 --> 00:33:15.206 A:middle
because you haven't enabled
iCloud on your computer.

00:33:17.296 --> 00:33:20.086 A:middle
There's a storage meter,
it tells you how much

00:33:20.086 --> 00:33:21.086 A:middle
of your quota is there.

00:33:21.366 --> 00:33:24.156 A:middle
If you're not seeing data and
that meter is pegged red, well,

00:33:24.156 --> 00:33:25.546 A:middle
probably you're not seeing it

00:33:25.546 --> 00:33:27.856 A:middle
because the client
couldn't write it.

00:33:28.216 --> 00:33:30.366 A:middle
Below that, we have the
transfer activity gauge.

00:33:30.366 --> 00:33:32.166 A:middle
You can see some
green stripes there.

00:33:32.696 --> 00:33:34.616 A:middle
This coincides with
those notes I created

00:33:34.616 --> 00:33:36.266 A:middle
that were then pushed
up into the cloud.

00:33:36.386 --> 00:33:38.616 A:middle
Green stripes are
data being pushed;

00:33:38.716 --> 00:33:40.136 A:middle
blue stripes are
data being pulled.

00:33:40.136 --> 00:33:42.846 A:middle
Because this is a Mac and
it's [inaudible] up here

00:33:42.846 --> 00:33:44.816 A:middle
and it's been sitting on
stage connected for a while,

00:33:44.816 --> 00:33:46.096 A:middle
we don't see any blue stripes.

00:33:46.096 --> 00:33:47.946 A:middle
All of the data that
would've been downloaded

00:33:47.946 --> 00:33:49.986 A:middle
for this application was
downloaded well before

00:33:49.986 --> 00:33:50.646 A:middle
we launched.

00:33:51.546 --> 00:33:55.826 A:middle
And below that, we have
the documents in data view.

00:33:56.856 --> 00:33:59.656 A:middle
This is showing you a listing
of all the files that are

00:33:59.656 --> 00:34:03.286 A:middle
in your ubiquity container,
and you really don't need

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

00:33:59.656 --> 00:34:03.286 A:middle
in your ubiquity container,
and you really don't need

00:34:03.286 --> 00:34:05.376 A:middle
to pay attention to the
stuff that starts with a dot,

00:34:05.376 --> 00:34:07.976 A:middle
that's our private stuff; you're
not going to be able to figure

00:34:07.976 --> 00:34:09.545 A:middle
out very much from there.

00:34:10.985 --> 00:34:17.356 A:middle
But under that, you'll
see some directories

00:34:17.356 --> 00:34:18.626 A:middle
that have an accountname.uuid

00:34:18.626 --> 00:34:21.926 A:middle
and these are your
peer containers.

00:34:21.926 --> 00:34:24.436 A:middle
And digging notes inside
those can be interesting

00:34:24.436 --> 00:34:26.755 A:middle
because that's where you'll
see the Core Data receipts.

00:34:26.886 --> 00:34:30.466 A:middle
And if you've got data coming,
you're debugging an application

00:34:30.466 --> 00:34:34.356 A:middle
on two pairs and you're
expecting data from one to show

00:34:34.356 --> 00:34:36.716 A:middle
up in the other, this is where
you'll find out whether or not

00:34:36.716 --> 00:34:38.576 A:middle
that data has actually
made it through the cloud.

00:34:38.996 --> 00:34:41.936 A:middle
If you've got five receipts
on one file and only three --

00:34:41.936 --> 00:34:44.646 A:middle
on one machine and only
three on the other, well,

00:34:44.646 --> 00:34:46.076 A:middle
that's some transactions
that have not

00:34:46.076 --> 00:34:47.386 A:middle
yet made it across the network.

00:34:49.116 --> 00:34:52.326 A:middle
Transaction logs appear in
these lines and you can see

00:34:52.326 --> 00:34:58.226 A:middle
over on the right-hand side the
status whether data is current,

00:34:58.646 --> 00:35:01.056 A:middle
whether we know it exists
but it's still in the cloud

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

00:34:58.646 --> 00:35:01.056 A:middle
whether we know it exists
but it's still in the cloud

00:35:01.056 --> 00:35:02.746 A:middle
because it's a large file
and we haven't managed

00:35:02.746 --> 00:35:06.366 A:middle
to download it yet, whether
it's current but waiting

00:35:06.366 --> 00:35:09.966 A:middle
to be pushed to the cloud.

00:35:09.966 --> 00:35:15.636 A:middle
So, and here's that using local
storage that Nick was talking

00:35:15.636 --> 00:35:17.226 A:middle
about -- logs that
Nick was talking about.

00:35:18.546 --> 00:35:23.116 A:middle
We're not using it in this
case; we're using the cloud.

00:35:23.196 --> 00:35:27.126 A:middle
So, on top of that,
Nick also talked

00:35:27.126 --> 00:35:30.566 A:middle
about account transitions,
about how Core Data has taken

00:35:30.896 --> 00:35:34.276 A:middle
over managing the iCloud
state transitions for you.

00:35:35.436 --> 00:35:37.426 A:middle
And, well, how to demo that?

00:35:37.936 --> 00:35:39.926 A:middle
Well, that's pretty easy.

00:35:39.926 --> 00:35:45.436 A:middle
You need to go off.

00:35:45.676 --> 00:35:47.276 A:middle
I'm going to go into
system preferences.

00:35:48.076 --> 00:35:50.656 A:middle
I'm going to hit
the Sign Out button.

00:35:53.556 --> 00:35:55.166 A:middle
And voila!

00:35:55.806 --> 00:35:59.606 A:middle
Automatically, we have noticed
that the account was signed out,

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

00:36:00.536 --> 00:36:02.386 A:middle
sent you a notification
saying --

00:36:02.576 --> 00:36:04.536 A:middle
oh, by the way, that
file is going away,

00:36:05.186 --> 00:36:07.746 A:middle
and my application
received that,

00:36:08.546 --> 00:36:11.606 A:middle
and basically refreshed its UI
and you can see all of the data

00:36:11.606 --> 00:36:13.136 A:middle
that was in the cloud
is now gone.

00:36:13.606 --> 00:36:16.296 A:middle
That's because once you
remove an account, well,

00:36:17.716 --> 00:36:19.876 A:middle
you no longer have
that iCloud data.

00:36:19.876 --> 00:36:21.946 A:middle
It's off in the cloud,
not on your local system.

00:36:22.106 --> 00:36:25.726 A:middle
So our local store, because we
had not created any data before

00:36:25.726 --> 00:36:28.346 A:middle
we logged into cloud is empty.

00:36:28.916 --> 00:36:31.396 A:middle
So, well let's signing out

00:36:31.396 --> 00:36:33.226 A:middle
and you're probably
saying, "Well, sign out?

00:36:33.326 --> 00:36:34.006 A:middle
Yeah, that's easy.

00:36:34.006 --> 00:36:34.966 A:middle
How about sign in?

00:36:35.236 --> 00:36:36.026 A:middle
Can you do that?"

00:36:36.336 --> 00:36:37.636 A:middle
Well, we can do that, too.

00:36:38.336 --> 00:36:41.006 A:middle
And to show you that, I'm
going to actually switch

00:36:41.006 --> 00:36:48.146 A:middle
over to my other computer
here, and actually [inaudible]

00:36:48.586 --> 00:36:51.976 A:middle
that demo with the First
Launch Experience demo.

00:36:52.576 --> 00:36:55.656 A:middle
So, for those of you who
are extremely perceptive,

00:36:56.136 --> 00:36:59.586 A:middle
you might notice that up here
in the corner I'm not connected

00:36:59.586 --> 00:37:02.356 A:middle
to Wi-Fi, and those
of you who are

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

00:36:59.586 --> 00:37:02.356 A:middle
to Wi-Fi, and those
of you who are

00:37:02.356 --> 00:37:04.646 A:middle
in the front rows
can probably see

00:37:04.646 --> 00:37:07.126 A:middle
that I'm waving Ethernet
cable at you.

00:37:07.426 --> 00:37:09.816 A:middle
This laptop is not
connected to the network

00:37:09.816 --> 00:37:11.546 A:middle
and has not been
connected to the network

00:37:11.956 --> 00:37:14.876 A:middle
since I airdropped
my project on to it.

00:37:14.926 --> 00:37:18.976 A:middle
So this is your canonical
first launch situation.

00:37:19.636 --> 00:37:23.766 A:middle
The application has never seen
the network, but there is data

00:37:23.766 --> 00:37:25.096 A:middle
in the cloud out there.

00:37:25.356 --> 00:37:26.196 A:middle
So how does this work?

00:37:26.976 --> 00:37:32.306 A:middle
Well, we need to run my
application and it comes up

00:37:32.306 --> 00:37:34.236 A:middle
and as we expect, it's empty.

00:37:34.896 --> 00:37:36.336 A:middle
We're not attached to the cloud,

00:37:36.336 --> 00:37:43.626 A:middle
no reason there should
be data there.

00:37:43.816 --> 00:37:45.726 A:middle
Create an offline note.

00:37:46.746 --> 00:37:48.356 A:middle
OK? It's a note.

00:37:49.106 --> 00:37:53.646 A:middle
And then I'm going to come
into system preferences,

00:37:58.856 --> 00:38:04.506 A:middle
but first I'm going to find
my Ethernet cable and plug

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

00:37:58.856 --> 00:38:04.506 A:middle
but first I'm going to find
my Ethernet cable and plug

00:38:04.506 --> 00:38:10.236 A:middle
in my Ethernet cable and log in.

00:38:11.516 --> 00:38:25.256 A:middle
[ Pause ]

00:38:25.756 --> 00:38:28.786 A:middle
I don't care.

00:38:28.786 --> 00:38:29.516 A:middle
I don't care.

00:38:30.096 --> 00:38:31.806 A:middle
I don't care [laughter].

00:38:32.396 --> 00:38:36.526 A:middle
Do show me documents and data.

00:38:37.066 --> 00:38:41.966 A:middle
Let's see.

00:38:42.196 --> 00:38:47.676 A:middle
And it looks like something
has gone wrong, of course,

00:38:49.036 --> 00:38:52.426 A:middle
because something
would have to go wrong.

00:38:52.636 --> 00:38:54.266 A:middle
Oh well. You could see
that we actually --

00:38:54.266 --> 00:38:55.596 A:middle
oh, I see what's happened.

00:38:55.596 --> 00:38:57.716 A:middle
We're blocking waiting for
the initial sync to happen.

00:38:59.356 --> 00:39:03.016 A:middle
This is the log you'll see
when Core Data tries to go out

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

00:38:59.356 --> 00:39:03.016 A:middle
This is the log you'll see
when Core Data tries to go out

00:39:03.016 --> 00:39:09.836 A:middle
and connect to the iCloud
account, will basically have

00:39:09.836 --> 00:39:11.536 A:middle
to block as we sync data in.

00:39:12.116 --> 00:39:16.516 A:middle
And eventually because,
you know,

00:39:16.516 --> 00:39:18.026 A:middle
you guys are probably
hammering the network

00:39:18.026 --> 00:39:22.346 A:middle
and that took a little while,
we come back and we say, "OK.

00:39:22.346 --> 00:39:24.016 A:middle
Now we're not using the
local storage anymore.

00:39:24.016 --> 00:39:28.766 A:middle
But you can see that offline
note I created is still there.

00:39:28.966 --> 00:39:32.146 A:middle
So, yes, this is what
we've been working on.

00:39:32.146 --> 00:39:35.296 A:middle
This is how we've been trying to
make your developer experience

00:39:35.296 --> 00:39:39.066 A:middle
with iCloud and your customer's
experience while using iCloud a

00:39:39.066 --> 00:39:39.796 A:middle
lot easier.

00:39:40.296 --> 00:39:44.376 A:middle
You've seen asynchronous
setup, it worked.

00:39:44.376 --> 00:39:47.586 A:middle
You've seen account transitions
to and fro and you've seen,

00:39:47.586 --> 00:39:49.986 A:middle
you know, how you might
go about debugging issues

00:39:49.986 --> 00:39:52.726 A:middle
that you're seeing with
a Core Data application.

00:39:53.386 --> 00:39:55.396 A:middle
And at this point I'm going
to bring my manager, Ben,

00:39:55.396 --> 00:39:59.166 A:middle
on stage to talk to
you about the changes

00:39:59.166 --> 00:40:01.936 A:middle
that we've been making to
the Core Data SQLite store.

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

00:39:59.166 --> 00:40:01.936 A:middle
that we've been making to
the Core Data SQLite store.

00:40:03.516 --> 00:40:09.526 A:middle
[ Applause ]

00:40:10.026 --> 00:40:10.236 A:middle
>> Ben Trumbull: Great.

00:40:10.606 --> 00:40:11.416 A:middle
Thank you very much, Melissa.

00:40:11.416 --> 00:40:13.176 A:middle
Good morning, everyone.

00:40:14.366 --> 00:40:16.286 A:middle
So I'd like to talk to
you a little bit today

00:40:16.286 --> 00:40:17.676 A:middle
about the changes we've made

00:40:17.676 --> 00:40:20.696 A:middle
to some interest structure
items underneath it covers here

00:40:20.696 --> 00:40:23.236 A:middle
with the Core Data and the
SQLite store, and there's one

00:40:23.236 --> 00:40:26.586 A:middle
in particularly, which is we've
changed the default journaling

00:40:26.586 --> 00:40:28.916 A:middle
mode that Core Data is
using with the SQLite store.

00:40:29.446 --> 00:40:32.596 A:middle
And this change is going
to be active for every app

00:40:32.646 --> 00:40:36.186 A:middle
that rebuilds against
iOS 7 and Mac OS X 10.9.

00:40:36.546 --> 00:40:37.876 A:middle
Now just to sort of recap,

00:40:38.276 --> 00:40:41.046 A:middle
we've been using the original
SQLite journaling mode,

00:40:41.046 --> 00:40:44.686 A:middle
the rollback journaling for
years now -- since about 2004,

00:40:45.006 --> 00:40:47.806 A:middle
and we're switching over
to the write-ahead logging

00:40:47.806 --> 00:40:48.256 A:middle
journal mode.

00:40:48.886 --> 00:40:51.386 A:middle
So this is going to be something
that apps need to accommodate.

00:40:51.726 --> 00:40:55.956 A:middle
So the difference is that
in rollback journaling,

00:40:57.336 --> 00:41:00.836 A:middle
SQLite copies the original pages
out of the main database file

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

00:40:57.336 --> 00:41:00.836 A:middle
SQLite copies the original pages
out of the main database file

00:41:00.836 --> 00:41:04.136 A:middle
into a file on the side just
in case something goes wrong

00:41:04.136 --> 00:41:07.006 A:middle
with the transaction, and then
it updates the main database

00:41:07.006 --> 00:41:08.236 A:middle
file directly in place.

00:41:08.886 --> 00:41:11.666 A:middle
And when it's done, in
order to do the commit,

00:41:11.666 --> 00:41:14.726 A:middle
it just deletes the
journal file.

00:41:15.526 --> 00:41:16.526 A:middle
For write-ahead logging,

00:41:16.526 --> 00:41:18.836 A:middle
it actually leaves the
main database file alone

00:41:18.836 --> 00:41:22.406 A:middle
and it just keeps appending
transactions to this WAL file,

00:41:23.026 --> 00:41:25.486 A:middle
and it uses the shared
memory file to keep track

00:41:25.486 --> 00:41:27.626 A:middle
of which page it --
the most recent copies

00:41:27.626 --> 00:41:28.856 A:middle
of each individual pages.

00:41:29.246 --> 00:41:32.486 A:middle
And then once you've aggregated
enough [inaudible] together,

00:41:32.706 --> 00:41:35.786 A:middle
a series of transactions,
several megabytes of data,

00:41:35.966 --> 00:41:38.146 A:middle
it'll perform a checkpoint
operation automatically

00:41:38.296 --> 00:41:41.216 A:middle
to merge the WAL file back
into the main database file.

00:41:42.286 --> 00:41:46.066 A:middle
So, to give you a little
diagram of what exactly is going

00:41:46.066 --> 00:41:48.776 A:middle
on here, generally, as you're
going along with the SQLite

00:41:49.156 --> 00:41:52.576 A:middle
in the rollback mode, you'll
only see the main database file.

00:41:53.616 --> 00:41:55.326 A:middle
But, when you start
a transaction,

00:41:56.226 --> 00:41:59.306 A:middle
you'll end up with this
intermediary-journal file

00:41:59.466 --> 00:42:00.966 A:middle
floating alongside of it.

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

00:41:59.466 --> 00:42:00.966 A:middle
floating alongside of it.

00:42:01.346 --> 00:42:05.306 A:middle
And then when you commit the
transaction, it'll go through

00:42:05.306 --> 00:42:12.396 A:middle
and basically delete
the journal file.

00:42:12.756 --> 00:42:15.136 A:middle
In WAL mode, you're going
to end up having all three

00:42:15.136 --> 00:42:17.976 A:middle
of these files around almost
all of the time, and this is one

00:42:17.976 --> 00:42:20.536 A:middle
of the behavioral changes
that you'll need to sort

00:42:20.536 --> 00:42:21.846 A:middle
of accommodate yourself.

00:42:23.036 --> 00:42:26.296 A:middle
So what ends up happening is
when you begin the transaction,

00:42:27.526 --> 00:42:30.396 A:middle
it'll start appending these
transactions to the WAL file.

00:42:30.776 --> 00:42:33.496 A:middle
And unlike delete mode,
when you come through

00:42:33.496 --> 00:42:34.866 A:middle
and you commit the transaction,

00:42:35.256 --> 00:42:37.206 A:middle
it actually does almost
no additional work,

00:42:37.616 --> 00:42:40.856 A:middle
so the transaction stays
appended to the WAL file.

00:42:41.666 --> 00:42:44.466 A:middle
And then, once you've aggregated
several megabytes of data

00:42:44.466 --> 00:42:46.446 A:middle
in the WAL file,
it'll come through

00:42:46.446 --> 00:42:48.036 A:middle
and then perform a
checkpoint operation.

00:42:48.576 --> 00:42:51.696 A:middle
And the checkpoint operation
will merge the WAL file back

00:42:51.696 --> 00:42:52.866 A:middle
into the main database file.

00:42:53.386 --> 00:42:57.626 A:middle
And then you may end up
sporadically in a place

00:42:57.626 --> 00:42:59.836 A:middle
where there is no WAL file, the
WAL file is being truncated,

00:42:59.836 --> 00:43:02.306 A:middle
but that's going to be a fairly
transient state of affairs,

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

00:42:59.836 --> 00:43:02.306 A:middle
but that's going to be a fairly
transient state of affairs,

00:43:02.506 --> 00:43:04.366 A:middle
and generally you're
going to see in WAL mode

00:43:04.366 --> 00:43:09.056 A:middle
that you have all
three of these files.

00:43:09.446 --> 00:43:12.696 A:middle
So, the reasons why
we're doing this is

00:43:12.696 --> 00:43:14.996 A:middle
that on the consumer grade
hardware we've experienced,

00:43:15.326 --> 00:43:16.656 A:middle
there have been some
difficulties

00:43:16.656 --> 00:43:18.866 A:middle
in getting the level of
reliability that we really want

00:43:18.946 --> 00:43:21.326 A:middle
to have across kernel
panics, and power loss,

00:43:21.326 --> 00:43:24.196 A:middle
and some very severe
failure modes,

00:43:24.646 --> 00:43:26.366 A:middle
and updating the
main database file

00:43:26.366 --> 00:43:29.446 A:middle
in place has been somewhat
difficult to manage.

00:43:29.926 --> 00:43:32.836 A:middle
So under WAL mode --
because that's not happening,

00:43:33.076 --> 00:43:37.496 A:middle
we're able to do a more
expensive sync operation that's

00:43:37.596 --> 00:43:40.196 A:middle
basically being managed
by the WAL

00:43:40.196 --> 00:43:43.316 A:middle
and the checkpoint
aggregating several megabytes

00:43:43.316 --> 00:43:45.026 A:middle
of work together.

00:43:45.216 --> 00:43:47.666 A:middle
We also see some very
substantial performance

00:43:47.666 --> 00:43:50.076 A:middle
improvements because
we're doing fewer syncs.

00:43:50.396 --> 00:43:54.086 A:middle
There isn't any actual
syncing going on in WAL mode

00:43:54.086 --> 00:43:56.116 A:middle
with the individual
commits, right?

00:43:56.116 --> 00:43:58.966 A:middle
So it's just appending these
things to the WAL file.

00:43:59.346 --> 00:44:01.666 A:middle
And this has actually been
a pretty big difference

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

00:43:59.346 --> 00:44:01.666 A:middle
And this has actually been
a pretty big difference

00:44:01.716 --> 00:44:03.786 A:middle
on [inaudible] devices and iOS.

00:44:04.976 --> 00:44:08.186 A:middle
And finally, then we see
some improved concurrency.

00:44:08.186 --> 00:44:10.096 A:middle
Under WAL mode, it's possible

00:44:10.096 --> 00:44:13.306 A:middle
to have multiple readers going
concurrently with the writer.

00:44:13.796 --> 00:44:16.496 A:middle
So, I'm going to talk
about this in a second,

00:44:16.746 --> 00:44:18.626 A:middle
but it's actually much better

00:44:18.626 --> 00:44:21.876 A:middle
than the standard
reader/writer lock model

00:44:21.876 --> 00:44:23.196 A:middle
that rollback journaling uses.

00:44:24.016 --> 00:44:25.916 A:middle
And we've adopted this
internally at Apple

00:44:25.916 --> 00:44:28.426 A:middle
across the system and it's
seen some great benefits,

00:44:28.426 --> 00:44:30.846 A:middle
so that's part of the
motivation of rolling this out.

00:44:31.936 --> 00:44:34.466 A:middle
So WAL databases support --

00:44:34.466 --> 00:44:37.246 A:middle
or write going concurrently
with the readers as opposed

00:44:37.246 --> 00:44:39.176 A:middle
to blocking out readers
the way it does

00:44:39.176 --> 00:44:40.216 A:middle
in the traditional journaling.

00:44:41.176 --> 00:44:43.456 A:middle
Now for Core Data itself,

00:44:43.636 --> 00:44:46.786 A:middle
NSPersistentStoreCoordinator
still serializes each individual

00:44:46.786 --> 00:44:47.686 A:middle
fetch and save.

00:44:47.686 --> 00:44:51.776 A:middle
So to maximize concurrency using
WAL journaling within Core Data,

00:44:51.776 --> 00:44:53.896 A:middle
you're going to need to
have two Core Data stacks.

00:44:55.596 --> 00:45:00.556 A:middle
So for leveraging concurrency,
you have this SQLite file

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

00:44:55.596 --> 00:45:00.556 A:middle
So for leveraging concurrency,
you have this SQLite file

00:45:00.556 --> 00:45:02.496 A:middle
that you're sharing between
multiple coordinators;

00:45:03.256 --> 00:45:05.716 A:middle
and you'll set up an
additional coordinator

00:45:05.716 --> 00:45:08.356 A:middle
and managed object context
for each of these types

00:45:08.356 --> 00:45:11.116 A:middle
of operations and they
can both be pointed

00:45:11.116 --> 00:45:12.446 A:middle
at the same SQLite store.

00:45:12.856 --> 00:45:16.086 A:middle
And with this kind of setup you
have, you can basically have one

00:45:16.086 --> 00:45:19.656 A:middle
of these coordinators doing
reads while another one is

00:45:20.386 --> 00:45:20.976 A:middle
doing writes.

00:45:22.546 --> 00:45:24.256 A:middle
Now when you're using
multiple coordinators,

00:45:24.256 --> 00:45:26.816 A:middle
you can't really pass
any objects between them,

00:45:26.886 --> 00:45:29.816 A:middle
so there is some friction there,
and this includes object IDs.

00:45:29.906 --> 00:45:31.146 A:middle
So if you want to
pass references

00:45:31.146 --> 00:45:32.446 A:middle
between these two stacks,

00:45:32.846 --> 00:45:34.606 A:middle
you'll need to use the
URI representation.

00:45:36.216 --> 00:45:37.856 A:middle
Nevertheless, this
is actually excellent

00:45:37.856 --> 00:45:39.186 A:middle
for doing background imports

00:45:39.576 --> 00:45:42.396 A:middle
where you have a very segregated
stack that's sort of siloed away

00:45:42.396 --> 00:45:44.206 A:middle
from the main UI and
everything else you're doing.

00:45:45.446 --> 00:45:48.716 A:middle
You can do importing, all kinds
of background batch changes,

00:45:48.786 --> 00:45:51.556 A:middle
and stuff like that, and
it allows the UI thread

00:45:51.556 --> 00:45:54.006 A:middle
to remain unblocked and to do
a lot of aggressive reading

00:45:54.006 --> 00:45:56.276 A:middle
or faulting and fulfill the UI

00:45:56.276 --> 00:45:59.426 A:middle
and the main thread while you're
doing a fairly substantial write

00:45:59.426 --> 00:46:00.486 A:middle
operation in the background.

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

00:45:59.426 --> 00:46:00.486 A:middle
operation in the background.

00:46:00.486 --> 00:46:03.196 A:middle
So this is particularly
useful for responsiveness

00:46:03.196 --> 00:46:05.046 A:middle
around launch time
where you might want

00:46:05.046 --> 00:46:07.316 A:middle
to be importing changes
from some other data source

00:46:07.596 --> 00:46:13.426 A:middle
around the time the user
starts up the app again.

00:46:13.596 --> 00:46:16.256 A:middle
Now, there are some sharp edges
using the WAL database file,

00:46:16.256 --> 00:46:18.686 A:middle
but we don't recommend
this for any kind of file

00:46:18.686 --> 00:46:20.236 A:middle
that you're going to be
moving around yourself.

00:46:20.236 --> 00:46:22.496 A:middle
So if you're using file
system operations now

00:46:23.036 --> 00:46:27.046 A:middle
on the database file, then
WAL mode is probably not going

00:46:27.046 --> 00:46:28.916 A:middle
to be very compatible
with the code you have

00:46:28.916 --> 00:46:31.066 A:middle
because there are going
to be two additional files

00:46:31.226 --> 00:46:33.336 A:middle
that your code probably
isn't prepared for.

00:46:34.196 --> 00:46:36.146 A:middle
And we don't recommend
this for read-only files,

00:46:36.146 --> 00:46:38.766 A:middle
so there's been some
issues there

00:46:38.766 --> 00:46:41.446 A:middle
and this is primarily
useful for library files

00:46:41.616 --> 00:46:43.386 A:middle
that you're going to be writing.

00:46:43.826 --> 00:46:45.916 A:middle
And finally, we don't
recommend this obviously

00:46:45.916 --> 00:46:47.966 A:middle
for a document format
that you already have

00:46:48.146 --> 00:46:50.876 A:middle
if you have a standalone SQLite
file as part of your document.

00:46:51.446 --> 00:46:52.716 A:middle
Now, you can put a wall

00:46:52.716 --> 00:46:55.696 A:middle
of database inside a document
package, and that's fine,

00:46:56.016 --> 00:46:58.246 A:middle
but a lot of people
we've seen have sort

00:46:58.246 --> 00:47:01.586 A:middle
of free standing SQLite files
as their documents and some

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

00:46:58.246 --> 00:47:01.586 A:middle
of free standing SQLite files
as their documents and some

00:47:01.586 --> 00:47:03.056 A:middle
of them is running
to some challenges

00:47:03.336 --> 00:47:06.696 A:middle
where the journal file itself
is also outside of any kind

00:47:06.696 --> 00:47:10.056 A:middle
of wrapper package, so that can
be a little bit of a friction.

00:47:10.056 --> 00:47:12.516 A:middle
We definitely recommend that
if you're going to use SQLite

00:47:12.516 --> 00:47:15.276 A:middle
for a document file, you put
it inside a package wrapper.

00:47:16.306 --> 00:47:18.276 A:middle
And something else to keep

00:47:18.276 --> 00:47:20.776 A:middle
in mind is the WAL journaling
really only goes back

00:47:20.776 --> 00:47:22.326 A:middle
as far as MAC OS X 10.7.

00:47:23.356 --> 00:47:26.176 A:middle
So, if you need to communicate
these files persistently

00:47:26.176 --> 00:47:30.056 A:middle
with older systems, you'll need
to use the rollback journaling.

00:47:30.456 --> 00:47:33.716 A:middle
So to get back to
rollback journaling,

00:47:34.316 --> 00:47:37.586 A:middle
the SQL command is
fragmentjournalmode=delete,

00:47:37.996 --> 00:47:40.326 A:middle
and to set this in Core Data,

00:47:40.326 --> 00:47:42.336 A:middle
you just set the
options dictionary

00:47:42.416 --> 00:47:44.286 A:middle
that you passed
addPersistentStore with type,

00:47:44.616 --> 00:47:47.746 A:middle
and you just pass in this
pragma on the journal mode

00:47:47.846 --> 00:47:48.966 A:middle
to set it to the delete mode.

00:47:49.386 --> 00:47:50.256 A:middle
And this will get you back

00:47:50.256 --> 00:47:52.746 A:middle
to the same behavior you
had in previous releases.

00:47:57.336 --> 00:48:01.046 A:middle
Now, some general caveats is you
really shouldn't be using any

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

00:47:57.336 --> 00:48:01.046 A:middle
Now, some general caveats is you
really shouldn't be using any

00:48:01.046 --> 00:48:03.046 A:middle
file system routines directly

00:48:03.046 --> 00:48:05.936 A:middle
against any open SQLite database
file and we've seen a lot

00:48:05.936 --> 00:48:08.386 A:middle
of people try to try
to like delete files

00:48:08.386 --> 00:48:09.976 A:middle
or maybe they're trying
to make backup copies

00:48:09.976 --> 00:48:10.626 A:middle
or something like that.

00:48:10.976 --> 00:48:14.186 A:middle
And this really messes
up file locks and a bunch

00:48:14.186 --> 00:48:15.756 A:middle
of other things that
are going under the hood

00:48:15.956 --> 00:48:19.106 A:middle
and at its core using
NSFileManager

00:48:19.106 --> 00:48:20.736 A:middle
or at the POSIX file routines,

00:48:21.036 --> 00:48:22.916 A:middle
it's going to be
bypassing the SQLite API.

00:48:23.486 --> 00:48:26.966 A:middle
So if the files open, we
really strongly discourage this

00:48:26.966 --> 00:48:28.466 A:middle
and you have gotten
away with this

00:48:28.466 --> 00:48:31.596 A:middle
in the old classic
delete mode for journaling

00:48:31.886 --> 00:48:34.046 A:middle
but it's not going to work out
very well under WAL journaling.

00:48:35.206 --> 00:48:37.746 A:middle
Also for network file
systems, we've seen a bunch

00:48:37.746 --> 00:48:39.396 A:middle
of people try and
they keep trying.

00:48:39.756 --> 00:48:43.036 A:middle
But at the end of the day
-- at the end of the day,

00:48:43.036 --> 00:48:47.006 A:middle
the caching that's going on
in the kernel is not going

00:48:47.006 --> 00:48:49.746 A:middle
to be coherent between multiple
different physical machines.

00:48:49.746 --> 00:48:53.306 A:middle
Right? So it's OK to
have an SQLite file

00:48:53.306 --> 00:48:55.016 A:middle
in a network home
directory that's being used

00:48:55.016 --> 00:48:58.136 A:middle
by a single machine,
but sharing these files

00:48:58.136 --> 00:49:01.956 A:middle
across multiple different
machines simultaneously is not

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

00:48:58.136 --> 00:49:01.956 A:middle
across multiple different
machines simultaneously is not

00:49:01.956 --> 00:49:02.946 A:middle
going to end very well.

00:49:04.006 --> 00:49:06.966 A:middle
And finally, a lot of
people try to change

00:49:06.966 --> 00:49:09.536 A:middle
for performance reasons
the synchronous pragma,

00:49:10.946 --> 00:49:13.996 A:middle
and especially under WAL mode,
we've customized this behavior

00:49:13.996 --> 00:49:15.596 A:middle
for Apple's build of SQLite,

00:49:15.656 --> 00:49:18.576 A:middle
so please just don't
change it at all.

00:49:19.746 --> 00:49:21.826 A:middle
And if you want to continue
doing whatever it is you're

00:49:21.826 --> 00:49:25.766 A:middle
doing with the rollback
journaling, that's fine.

00:49:26.316 --> 00:49:28.506 A:middle
And as part of some
of this other work,

00:49:28.506 --> 00:49:30.266 A:middle
there are general
infrastructure changes going

00:49:30.266 --> 00:49:33.666 A:middle
on with the SQLite store,
in particular to integrate

00:49:33.846 --> 00:49:37.536 A:middle
with the power and I/O
changes, the throttling changes

00:49:37.536 --> 00:49:39.116 A:middle
that have been talked
about earlier in the week

00:49:39.326 --> 00:49:41.976 A:middle
to improve battery
life on Mac OS X.

00:49:42.096 --> 00:49:46.026 A:middle
So, we've done some extra
work in Core Data to integrate

00:49:46.026 --> 00:49:51.056 A:middle
with I/O throttling and improve
the amount of battery time

00:49:51.096 --> 00:49:55.236 A:middle
that SQLite is using if you have
multiple contending connections.

00:49:55.756 --> 00:49:59.416 A:middle
And finally, there's also a
guarded file descriptor concept

00:49:59.416 --> 00:50:00.176 A:middle
that's being used.

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

00:49:59.416 --> 00:50:00.176 A:middle
that's being used.

00:50:00.176 --> 00:50:02.436 A:middle
We're not going to go
into this very much,

00:50:02.436 --> 00:50:05.586 A:middle
but you should be aware that
it exists and SQLite is going

00:50:05.586 --> 00:50:08.716 A:middle
to be making efforts to
prevent accidentally corrupting

00:50:08.716 --> 00:50:11.006 A:middle
databases by smashing
the file descriptor

00:50:11.196 --> 00:50:13.126 A:middle
by closing a file
descriptor that doesn't belong

00:50:13.126 --> 00:50:14.376 A:middle
to you and things like that.

00:50:14.726 --> 00:50:18.096 A:middle
So that's available on
Mac OS X 10.9 and iOS.

00:50:19.486 --> 00:50:20.486 A:middle
And so that's most

00:50:20.486 --> 00:50:23.196 A:middle
of the infrastructure
we've done this release,

00:50:23.926 --> 00:50:26.256 A:middle
and for more information,
you can contact Dave DeLong,

00:50:26.656 --> 00:50:28.776 A:middle
or send your email to
the Cocoa feedback group,

00:50:28.776 --> 00:50:31.626 A:middle
and we have documentation
in all the usual places

00:50:31.626 --> 00:50:34.516 A:middle
and we have some
related sessions.

00:50:34.626 --> 00:50:37.536 A:middle
Tim Isted is going to be doing a
Core Data performance talk this

00:50:37.536 --> 00:50:40.756 A:middle
afternoon and there
will also be a --

00:50:40.756 --> 00:50:43.726 A:middle
hidden gems in Cocoa and
Cocoa Touch on Friday.

00:50:43.726 --> 00:50:44.956 A:middle
Thank you very much.

00:50:45.516 --> 00:50:47.516 A:middle
[Applause]

00:50:48.016 --> 00:50:58.146 A:middle
[Silence]