CloudKit Best Practices - Apple WWDC 2016

good morning and thanks for checking out our session my name is Dave browning and here with me today is Neha Sharma and we're gonna be we're both engineers in the cloud good team and we're going to be talking to you today about some best practices when building your applications with cloud kit so what are we gonna cover specifically well first I'm gonna walk through how we here at Apple use cloud kit we'll talk about the workflow and the api's that we use in order to provide a seamless experience for our customers and by that I mean allowing them to access the same data in their applications across all of their devices next n'yar is going to come up and talk about some details when using the CKD operation API and the configurability and flexibility you can get when you use it then he's going to talk about some things to consider when data modelling what you're gonna storing cloud kit how you're gonna store it how you're gonna build your schema and then he'll talk about error handling which we've always said is very important in cloud kit applications you're going to cover the different types of errors that you'll encounter potentially when using the API and how to consider responding to those depending on your applications use case so quick reminder we here at Apple have bill cloud kit or built at many applications on top of cloud kit and so you can be confident that yours will scale because we've scaled it to hundreds and millions of users I also wanted to do a quick refresher about the conceptual model so at the highest level we have what's called a container this is usually a one-to-one mapping to an application so the photos application has a container and cloud get the notes application in your application inside of a container you have a public database this is where you can store data that all users can see so an example of this is the dub WC app or the news app in iOS they're built on cloud kit they use the public database for storing article news that kind of stuff that everyone can see next there's the private database this is where you store data specific to a single user that user can see their data across all of their devices but no other users can see it and then new this year is the shared database if you want to learn more about this make sure to go back and check out the video for yesterday's session on what's new and cloud kit and they dive on the sharing stuff inside of a database you then have a zone and there's a default zone in a public and private database where if you throw records in there by default that's where they'll end up but you can choose in the private database to create one or more custom zones and you can store stuff in those zones and then when content is shared to a user from another user that shows up as a shared zone in their shared database what you can think of is basically a proxy to the custom zone and a private database of the owner and then of course if multiple users share stuff with you and multiple custom zones you're going to end up potentially seeing a lot of shared zones in the shared database and now what I'm going to focus on with this workflow is mostly in the custom and shared zones that we're talking about right here finally at the lowest level you have records this is your key value structured data where you store everything and a record always exists in a specific zone so a quick reminder on the benefits of using cloud kit at the high level you can focus on building your application and not worried about building backing services we do that for you your users get what we like to call automatic authentication that means if they're signed into iCloud on a device you do not need to prompt them for signing up or logging in or any of the stuff that can usually be a barrier to using your application if they're signed into iCloud with cloud kit you immediately have a uniquely identifier for that user and you can start storing data on their behalf and then finally what the focus is today is you can get that same data your users can get their same data across all of their devices when you store it and clock it all right so let's talk about the common use case that we see when we're building our apps on top of cloud kid and so what happens is you have a user who runs an application in this example let's talk about notes so notes is built on cloud kid they create a note on their iPhone let's say that's stored over to the cloud and then when they open up notes for the first time maybe on a second device their iPad it feels like that data was sort of magically pushed and it's already there in their iPad and if they make edits on the iPad it feels like it's just magically pushed the other way so that's sort of the use case that we're looking at providing for our users so the way to think about this is iCloud the servers are the source of truth your devices have a local cache of that truth data and cloudkit the API is the glue in between the two alright so how does this actually work well basically when your app launches the works what we recommend is that you fetch changes from the server especially the first time your app launches because you don't know if something already exists that the user wrote from another device right so you talk to the server you fetch down any data that you don't have yet and then you ensure that you are subscribed to future changes by subscribing the future changes it tells cloud get the server to send push notifications to your applications on their other devices and then of course when you get a push you'll want to fetch changes again to pull down the new changes that happen from the users other device all right so let's dig into these in a bit more detail so subscribing the changes the way this works is when your application is launched for the first time and we'll talk about why in just a second but when it's launched for the first time you create a subscription telling the server here is the set of data I care about subscribing to and then when that data changes it will let you know when your application launches for the first time on another device the subscription might already exist for the user on the server but your app doesn't know that because it's launching for the first time so you need to make sure it exists so you'll do the same thing as you did before on the other device now that you're subscribing to changes and cloud kit is sending you push notifications you want to listen for those push notifications so let's walk through an example the user writes a new note the application stores that down to the server the server says AHA there's a subscription for this user they wanted to know when new data showed up it says it came from the iPhone so I don't need to bug the iPhone but that user also had an iPad so it looks up the proper Apple push notification service token talks to APNs on your behalf and tells them to send a push to the iPad so you don't have to deal with sending pushes yourself in the back end so then finally your iPad gets to push what does it do next well as we said now it goes and fetches that new changes from the server so it talks to cloudkit pull down the new data update it's local cache and then when the user opens up notes band they see the same stuff they just wrote on their iPhone alright so let's look at actually building this let's walk through the code the specific API that we use to make all of this happen so first we'll talk about subscribing to changes so remember what I said before this is one of those things that you only need to do the first time your app launches so you'll notice we have a check here at the top of our code that says have we locally cached on this device the fact that we've already created this subscription because if we've already created it we don't need to keep doing it every time we launch you save yourself Network requests you say there's a user some Network stuff all right so if we haven't done this before let's look in the code to set it up so new this year in iOS 10 there is API called seek a database subscription this allows you to subscribe to any change across an entire database and it works in the private database and the shared database so in this example let's focus on the new shared database so you can give a subscription an ID which allows you to check it later we'll talk about that in just a minute but in this case because we're dealing with the shared database let's call it shared changes next you need to tell cloudkit what type of push you want it to send when the subscription triggers and so let's dig into the different types you can do so the first one that we actually use a lot and recommend in most cases is a silent push notification and the way to do that in our API is on a subscription object you can set the notification info using the seek a notification info object and if you set the property should send content available to true and only that property you will get a silent push the back and we'll send a silent push on your behalf for this subscription and the key to this is that you do not need to prompt the user for acceptance so we've had people ask in the past hey we have this subscription but it's popping up you know you guys have seen it allow push notifications for this app and a lot of people hit no to that you don't get push and then you rely on polling if you do it this way you're not going to be alerting the user in any way so you don't need to ask for acceptance and then finally you can listen for these notifications in your app delegate register for remote notifications so if you do want to send a UI push you actually want to badge or banner or make a sound then you can set any one of these three properties and that will tell cloudkit to send a UI push to your user because you will be alerting them you do need to ask for user acceptance in this case and then of course you register for remote notifications in the same way as before so a little bit of fine print if you read the API documentation they tell you that pushes can be coalesced depending on the conditions of the device so that means if a subscription triggers and a push is sent to your users device there are many cases low battery bad network etc where they may not get that push but the coalescing piece means they promise to deliver at least one of those so what that means is you should not think of push as a way to tell your apps what changed because if five pushes were sent when you missed four of them you're going to miss for those what's instead think of push as a way to tell you that something changed one or more things and that's why we need to go talk to the server to figure out what those were and the good news is the cloud kata API provides you a way to ask for only what has changed so you don't have to pull down all the stuff you already have all right let's jump back into our code remember we're creating a subscription and in this case we've set up a silent push notification by doing should send content available to true now we need to take this subscription and ask the cloud kit client to save it off to the server and you're probably familiar with this if you've used cloud kit but the way you do everything is with operations and in this example we do a CKD modify subscriptions operation and we tell it about the subscription we've just created and this is the one we want to save with cloud kit because the client is going to be talking to the server over the network and that might take a bit of time everything is asynchronous so that means all of your operations have completion blocks that get called once a response comes back and so in this case we have a modified subscriptions completion block and the first thing you want to do in all of your completion blocks I know we say this all the time is check for errors and Nihar is going to talking to talk to a bit more details about this but in this case let's say if there is not an error then we know that the subscription was saved now we can locally cache the fact that we've done this so that we don't do it next time because of that check up at the top quick note and Nihar is going to talk about this to see key operations inherit from nsobject we add it to the shared databases operation queue and the client will now go off and send that to the server okay so we're subscribed to changes now so now the next step is to listen for pushes since cloudkit will send them to us when the data is changed in another device so you want to make sure that an xcode you've turned on background modes and you want to check the box for remote notifications and potentially background fetch if you want to do this while your app is in the background once you've done that there's a method in the app delegate that you might be familiar with which is application did receive remote notification fetch completion handler this method gets passed a user info dictionary and cloudkit provides you a handy way to see if you can get ACK notification out of that dictionary so if you can remember there might be pushes for other reasons but if it's coming from a cloud get subscription you'll be able to get a secant notification and now we can check the subscription ID so the reason this is important is because likely you're going to end up having a database subscription for the Private database and a shared database and maybe for other things so this is how you differentiate which subscription triggered this push so in this case let's say it was our shared changes now we can go off and fetch that shared data and we'll talk about that in just a second and when that's done we call the completion handler that was passed into this method okay so now we are listening for pushes and let's say sometime later your application gets a push so what do we do I remember what we said we need to fetch new changes and so let's look at a graphical example of sort of how this works so we got a push into our device and we said okay it was for the shared database there are sort of two steps you need to take the first one is you go and ask the server for which zones changed in the shared database remember we talked about zones before right because there may be new zones that showed up that you don't even know about because someone shared something with you and you pass along a server change token so it tells the server where in history you are and we'll dig into that in just a minute step two is now within those zones you go back to the server and say ok please tell me what records were changed inside of those specific zones and again you have changed tokens for each zone marking where in history your local device caches all right so let's talk about that change token thing in a bit more detail so imagine your user has a device the iPhone we were talking about before they're using your application and they send some changes down to the server those changes are accepted and the server wants to mark that point in history it does that what the server change token and in this case for simplicity sake let's say it's the letter A yeah that device sends down another set of changes that are accepted goes to B etc goes to see sometime later the user runs your app on a second device let's say that iPad we were talking about before and the first thing that iPad needs to do remember on app launch is go and ask for any changes that it doesn't have so it goes and says I would like to fetch the changes from the server the server says ok here you go here's what exists at the end of that it says you are now at server change token C so device 2 is now marked where in history it is now let's say device 2 then later write some data somewhere along the way device 1 gets a push device 1 fetches down the new changes and at the end of that the server says ok you're now it changed token e alright device 2 makes another set of changes device 1 gets a push pulls that stuff down it's now it changed took an AI now you'll notice that device 2 is still at change took and C and that's because when you're writing data you're not getting changed tokens back you don't get those until you actually fetch it so let's say device to the app restarts or they restart their iPad or something your app launches up you go and fetch changes the server will send you the stuff that you wrote from that device because it doesn't know if you had that locally cached or not for various reasons right so don't be surprised if you see some of the same this allows you to confirm that you have this stuff and now at the end of that the server will send down a change token I you notice that both devices are now at the same state at the same server change token so that's sort of an example of how that works ok so let's look at actually writing the code for fetching these changes so in this case we're going to talk about database so a new API and iOS 10 is CK fetch database changes operation and again you pass in the server change token that we just talked about and the first time you ever do that that will be nil and it will tell the server that you have nothing and it will give you everything that exists on the server next in previous versions of the API at into this operation you had to actually check a flag to see if the server said that there was more data coming and we'll talk about in just a second but if that was set to true it was your job on the client side to reach rigor this operation but what we've done is we've added a new property on these operations called fetch all changes and it defaults to true and what it does is it tells the cloud kick client to do that on your behalf so that you don't have to fool with it so if after wedding were these operations if the client sees that the server has more data it will automatically in queue your operation again for you and of course call your callbacks along the way so that you don't have to worry about that anymore next you want to implement this completion block record zone with ID changed block and this is where you will be told about the zones that changed in the shared database so you'll want to collect these zone IDs and we'll talk about what to do with them in just a second next there's record zone with ID was deleted block this tells you about the zones that no longer exists on the server and allows you to clean up any local cache data that was in those zones from before and you'll see this in cases potentially where something was unshared with your user because that zone no longer exists in their shared database and then new is a change token updated block so let's dig into this so remember before we had device one had written some data down to the server we had device two had written some data down and then some time way later device three for this user comes along and remember the first thing it needs to do is go talk to the server and fetch any changes and because fetch all changes was true it's asking for everything but there might be a lot of data there like in this case right and the server might decide it doesn't make sense to send all of this back in a single response so we're gonna chunk it up so you're just gonna send you back a chunk of it the cloud kick client will see that there's more coming from the server so it needs to go back and issue another operation on your behalf but before it does that it's going to call change token updated and tell you that your now it changed token C and this allows you to sort of move along with the client adds it's making these operations that you update your local change token and don't repeat some of the stuff you've already done so let's say this client on your behalf says there's more stuff coming from the server let's go back and get it sees some new data at the end of that calls change took an updated see if there's new data goes back to the server again but this time there's an error your air-handling it's likely that you're gonna end up calling fetch changes again but instead of starting all the way back at a because you have a change token updated block your local change stuckness now at e so when you call your next one the server says okay you only need FDI you don't need the old stuff that you've already processed so that's why it's important to implement the change took an updated block and you just cache the server change token just like you normally do and then finally we have our completion block which in this case is fetch database changes completion block again the first thing you do error handling again the our we'll talk about this and then you'll get a final change token which in that last example have you not received an error would have been the I at the end cache that just like you normally do and so now we've collected a set of zones that changed in that database now we need to go fetch the records that changed that was step two in that diagram before and we do that via a new API CK fetch records own changes operation and it allows you to pass in a set of zone IDs so you don't have to worry about calling all these for all the different zones that changed you call one pass in all the zones that changed and we won't dig into the code but it looks very much like this you're gonna have some completion blocks where you're dealing with records instead of zones and you'll be getting changed tokens along the way alright so quick recap of what we talked about so you subscribed to changes to tell cloud code that you want to receive pushes when the user changes the data on another device you've listened to those push notifications and when you receive one you're going and talk to the server and fetch exactly what changed and by doing this your application now provides that seamless experience for your users across all of their devices alright so now Nihar is going to come up and dig into some more specific best practices thanks Dave good morning everyone thanks for coming out today my name is Neha Sharma and I'm an engineer on the cloud kit team and today I'm very excited to share with you some cloud kit best practices that we've learned here at Apple over the past few years that you can take advantage of in your apps today let's take a look at what we're going to cover first I'd like to talk about automatic authentication Dave touched on this briefly I'd like to go into a little bit more detail about what it is how you can take advantage of it next I'd like to talk about the C key operation API which is the workhorse of our native cloud kit frameworks then we'll dig into a couple of tips that you can keep in mind when designing the schemas for your apps that'll help you take advantage of the cloud KPI more effectively and finally we've told you before just how critical great error handling is to writing a cloud kit app and I'd like to reiterate it reiterate that today and talk to you about a few different class of errors and how your applications should handle them so let's get started first up automatic authentication now you might be familiar with a UI like this where on first launch an app requests a lot of private information from a user even before the user has started using their apps well we think in cloud kit we have a great way for you to increase the chances of engaging with your users without requiring any private information upfront the way we do this is via the cloud kit user record as a reminder this user record is automatically created for every user that when they first use your apps that is logged into an iCloud account in this manner it is unique per cloud container and it offers you a stable identifier for that user that is stable across a pre launches OS upgrades etc so you can save this identifier to your servers and start building a profile for that user right away and when you notice that they're engaged with your apps a lot more then go ahead and request information to enrich their profiles the way you access the user record ID for the current user is via the fetch user record ID completion handler API on seek a container so that was automatically with cloudkit now let's talk about CKD operations as a recap there are two main ways in which the cloudkit framework exposes operations to your apps one is via convenience API calls which work on one item at a time and the other is via the C key operation counterpart so in this manner every convenience API call that we expose that works on one item has a CIA operation counterpart and that works on a batch of those items so for example we have the fetch with record ID API on seek a database to fetch one record at a time and we have its corresponding CKD fetch records operation that takes an array of record IDs and fetches them in a batch now there are certain advantages to using the C key operation API that you get over a convenience API call I'd like to walk through a lot of those today so first and foremost C key operation is a subclass of nsobject operations you can assign a quality of service to them to let the system know how important that operation is to you or even manage queue priorities when scheduling them on your own NS operation queues and you even get cancellation for Sica operations that have already started executing so I'd like you to go up go back and read up the documentation on s operations to take full advantage of the C key operation API a great reference for this is our advanced NS operation stock that we gave at WWDC last year so now since we're talking about cloud care operations there are a few more things that come along with the ride and I'd like to touch upon three of those main things today first is the configurability that c key operation gives you next is how it lets you optimize resources both for the system and you as a developer and last I'd like to talk about lifetime management which is something new that we've enabled you to be able to do in iOS 9.3 so first up a quick recap on just what you can configure on a CK operation operations let you have fine grain access to whether or not you wish network activity for that operation to go out over cellular you can also specify keys for operations that fetch items from the server if you want to download just partial records instead of the entire record which the convenience API does not let you do you can even limit the number of results that a particular operation returns to you and finally long-running operations also give you progress updates that you can use to drive certain UI elements so now let's talk about resource optimization the number one resource used by your operations on the system are Network requests now every convenience API call turns into at least one Network request on the system so when you use the c key operation batch API you allow the system to minimize the number of requests needed to be able to send your changes to the server so for instance if you want to save a batch of records and you use a ck modify records operation the system will take that batch and be able to optimize the requests needed to send that to the server so now in this manner it is not only good for the system resources but it also R helps you optimize your network request code as developers additionally by default CK operation lets you opt your network activity into discretionary behavior what we mean by this is that you let the system decide an opportune time for your request to be scheduled for more information I encourage you to check out the discretionary property on nsurl session configuration the way we expose this to you on ck operation is via the quality of service properties so by default ck operations have a quality of service utility any QoS which is utility or below will opt into this discretionary behavior so if you notice that your ck operations are taking a much longer time to execute the new expect that might be because the system does not think that it's a good time for your requests to go out yet now additionally there are a few other behaviors that you should keep in mind when opting into discretionary behavior network failures will be automatically retried for you and along with that by default you get a 7-day resource timeout for every single request that your operation executes so that was resource optimization now let's talk about CQ operation lifetime management on our platforms there are various reasons why our application may exit for instance you might be suspended in the background and be evicted or a user might force quit your app now you might have certain updates running while this happened which were either user initiated and you really wanted to just save them to the server regardless of whether your app may have exited or you might have longer running updates at a lower priority that you wish to finish whether or not your app sticks around so to serve this purpose in iOS 9.3 we introduced the concept of cloud kit long-lived operations what these operations that you do is once you mark them long live the system will execute that operation on your apps behalf whether or not your app sticks around we will cache any server responses we get for that operation and we'll provide you with an API to be able to replay those responses once your app returns so let's take a look at the API that we have exposed to be able to do this well on C key operation it's pretty straightforward you have an is long-lived flag so you create a secret operation like normal once you've set this flag you've turned it into a long-lived operation along with that you have an operation ID which is a system assigned string that uniquely identifies every C key operation and we'll take a look at why that's important in just a second so here's the general architecture of how you run a long-lived operation you've initialize an operation like you would normally you just set the is long live flag on it along with your arguments and callbacks and you run the operation now when you wish to resume it you will search that long live operation from the seeker container class via the operation ID you will set the callbacks that you're interested in hearing about and you will run that operation once more let's take a look at an example let's say we wish to run a long-lived fetch records operation so we set up the operation like we did normally with our arguments but we remember to set the is long live flag and we save the operation ID property to our local cache so that we remember what this operation represented we set up the callbacks and in queue the operation now when you wish to resume it you can use the fetch long live operation with ID API available on seek a container to fetch that operation and since you know what that operation represents in from your cash you can safely cast it and set the appropriate callbacks on it you do not need to set the arguments again or tweak any of the other operation properties that you might have previously and you resume that operation now cloud kid will then replay all of the cache responses we have back for that operation and either catch you up to the progress that the operation has made while your app was not around or give you the entirety of the results of that operation now what this also means is that these operations are cleaned up at some point of time and normally this happens when the completion block of that operation is called you must note that your apps will have at least 24 hours to resume any long live operations that they might have in queued so that was all about C key operation API now let's switch gears and talk about data modelling there are three main tips that I'd like to give you today the first one is around schema redundancies how you can use them and how they help you leverage the cloud KPI more effectively the second one is how to use references to avoid a certain class of errors that you might encounter in your cloud collapse and lastly I'd like to talk about parent references which is which are a new type of reference that we've added in this release to support cloud keys sharing so let's talk about schema redundancies let's take an example of developing a photo sharing app now the first thing that you might have on the server for this app is a record type for photo where you store a user's high-resolution photograph that they've taken on one of our iOS devices as a CG asset now let's say when the user first launches the app while you're fetching changes like Dave recommended before you wish to display just a thumbnail view of all the users most recent photos something like this which the Photos app does then it seems like an awful waste of network bandwidth to be able to download that entire high-resolution asset every single time you have to load this page so what can you do here well it's pretty straightforward you can think about adding a redundant field on that record which represents the downscaled asset and what this allows you to do is coupled with the usage of CK operation and the desired keys property that we talked about that enables you to fetch partial records you can now fetch just the key that you need to drive the UI that your user is interested in you can even set the results limit property to limit just a number of results that you're showing on a single page so in this manner you can in queue an optimized download to be able to present a dynamic UI to your users you fetch only what is needed when it is needed and the desired keys property is also available on the new CK fetch records own changes operation as well as CK fetch records operation both of which fetch items from the cloud for you now as a reminder these api's are also available to you on the web via cloud KS so by using them you enable your users to have a more dynamic experience in your apps because they're not waiting for you to finish operations that are downloading data that they're not gonna use next let's talk about CK references as a quick reminder what are these well the cloud gets way for you to point records to other records so for instance if we have two records here record a and record B we store a reference on record a initializing it with record B we've created a second reference now let's say we wish to add albums to our photo sharing app which can contain multiple photographs so how would we go about modeling this one too many relationship well in a simple manner naively you might think that this might be a good data model for this storing the record IDs the references to the photo records that are part of that album right on the album record itself as an array this is what that would look like now let's take a look at what happens when multiple devices for your user try to add albums to that try to add photographs to that same album so let's say we have an album record up on the cloud that does not have any photos yet now remember that your users are going to have multiple devices they all fetch this album record see that it has no photos they're happy with it now they have photos they each have photos that they wish to add to the same album so now they in queue that update on that record let's say our iPhone gets there first and now the server knows about one of the photographs the references to one of those photographs but now when the other two devices come in and try to make their updates they're no longer updating the latest version of the server record so in this case both of those devices will see the error CK error server record changed now I invite you to take a look at our advanced cloud kkatalk from WWDC 14 for more details on how you can handle this error but let's see if we can figure out a way where we can avoid it entirely well in this case we know that our album record is going to have frequent writes on it so instead if we model our one-to-many relationship using a back pointer by storing the reference on the photo record that is part of that album we completely the right contention that we had on our album record so in this case whenever new photo needs to be added you just set a reference on it to the album record that it's a part of and save the photo record by doing this you've completely eliminated your contention that you had previously and now you might wonder well how do I fetch all of those photos which is part of my problem to begin with well you can use queries for this purpose here's the query that you need to be able to fetch all photo records that are part of this album it's pretty straightforward all you need to do is equate it to the album reference field that you have on your photo records next let's talk about parent references on seeker record this year we've added a new type of reference called a parent reference that will help you model your data in a way that better supports cloudkit sharing what we'd like to recommend is that if your app supports sharing you use the parent references to set up a hierarchical data model recognize the unit of sharing in your apps and set up the parent references accordingly let's take a look at an example of what I mean by that our photo and album records are a great example of using a parent reference an album is clearly a parent of a photo photo record so all we need to do is set the parent property on the photo record to our album record ID and save that photo record now let's say that we've used this model throughout our app and we end up with a hierarchy that looks like this and now a user comes along that wishes to share this entire album well all you would need to do in this case is create a seka share with that album record as the route record and in one fell swoop you will share the entire hierarchy that you've set up using parent references now cloud kit also supports partially shared hierarchies so in this case if a user might have only wanted to share photos see for example you could have created a share just with photos seen and in this case only the photo see and that all all all its descendants set up parent references will be part of that chair and that was data modeling let's talk about error handling now there are a few different types of errors and your application should handle these in a few main different ways and let's take a look at each of them so let's say we have a simple example where your device comes along and issues a c key modify records operation and tries to talk to the server there are two main things that the server might respond with it could either say that I didn't like that request at all please don't try it again or it could say that everything was fine with your request but right now is not a good time come back a little later and try it again now we need your apps to handle these two types of errors in very different ways and let's take a look at what that is the first kind of error which is a fatal error you really can't do much there are a couple of error codes which indicate a fatal error for example internal error server rejected request invalid arguments or permission failure in this case we want you to show appropriate UI to your users in your apps and let them know that something went wrong which cannot be retried however the other type of error where the server wants you to come back at a later point in time we will tell you the amount of time that the server wishes for you to wait here are a couple of error codes that will have that value of time embedded in them zone busy service unavailable and request rate limited when you receive any of these error codes you should check for the CK error retry after key in the errors user info dictionary you should wait for that period of time and reinitialize the same CK operation with the same arguments and retry that operation here's all the code you need for a simple example of how to wait for that period of time represented by the CK error retry after value and realize the same secret operation now what happens in some cases when your operations might be failing on the device before even talking to the server there are two main cases that I'd like to discuss today where cloudkit may be completely unavailable to you the first one is when the device is offline well in this case what we recommend is that you monitor Network reach ability just like you would for any other network based app if you're using a quality of service of user initiated or above such that network failures are not being automatically to recharge for you you will see this error code seek an error in network unavailable so once your monitoring network reach ability which you can do via the SC network reachability API for example in system configuration framework you can then let the user know that hey these changes are not going to make it to the to the server yet but we recommend that you let your users keep interacting with your app while the device is offline you should save these changes to your local cache and when your reachability api tells you the device is back online then you in queue your cloud operations to save those records to the server the others main state is when you're trying to use the private database for a user and the user is not logged in to an iCloud account in this case we will return the error code CK error not authenticated to you now what we recommend is for for all of your apps on first launch always register to listen to the CK account change notification when it fires use the account status with completion handler API to refetch the account status for the current user and let them know that certain operations may fail because they don't have an iCloud account sign them so in summary let's take a look at what we've seen today we saw how to subscribe and fetch changes to efficiently stay up to date with the server we saw the advantages of using the batch CK operation API which we'd recommend all of your apps adopt we saw a couple of tips on how to design your schema to completely avoid a certain class of errors or to use the cloud KPI more effectively and finally we saw how to handle certain types of errors and how to differentiate between them and what the server means when it comes back with certain error codes as opposed to others now we had a related session yesterday if you could not check it out and invite you to go back and look at it online more information is available here thank you and have a great day

Channel: beBetterDev

Views: 3,807

Keywords: WWDC 2016 - Session 231 - iOS, macOS, tvOS, watchOS

Id: -B9BiKsej4Y

Length: 42min 48sec (2568 seconds)

Published: Mon Sep 12 2016