CKOperation
The abstract base class for all operations that execute in a database.
Declaration
class CKOperationMentioned in
Overview
All CloudKit operations descend from CKOperation, which provides the infrastructure for executing tasks in one of your app’s containers. Don’t subclass or create instances of this class directly. Instead, create instances of one of its concrete subclasses.
Use the properties of this class to configure the behavior of the operation before submitting it to a queue or executing it directly. CloudKit operations involve communicating with the iCloud servers to send and receive data. You can use the properties of this class to configure the behavior of those network requests to ensure the best performance for your app.
Long-Lived Operations
A long-lived operation is an operation that continues to run after the user closes the app. To specify a long-lived operation, set isLongLived to true, provide a completion handler, and execute the operation. To get the identifiers of all running long-lived operations, use the allLongLivedOperationIDs() method that CKContainer provides. To get a specific long-lived operation, use the longLivedOperation(for:) method. Make sure you set the completion handler of a long-lived operation before you execute it so that the system can notify you when it completes and you can process the results. Do not execute an operation, change it to long-lived, and execute it again as a long-lived operation.
The following is the typical life cycle of a long-lived operation:
The app creates a long-lived operation and executes it.
The daemon starts saving and sending the callbacks to the running app. 2. The app exits.
The daemon continues running the long-lived operation and saves the callbacks. 3. The app launches and fetches the long-lived operation.
If the operation is running or if it completed within the previous 24 hours, the daemon returns a proxy for the long-lived operation. If the operation completed more than 24 hours previously, the daemon may stop returning it in fetch requests. 4. The app runs the long-lived operation again.
The daemon sends the app all the saved callbacks (it doesn’t actually rerun the operation), and continues saving the callbacks and sending them to the running app. 5. The app receives the completion callback or the app cancels the operation.
The daemon stops including the operation in future fetch results.