Whenever you need to read and write a file, you do so using a file coordinator, which is an instance of the NSFileCoordinator class. To prevent your app from interfering with the daemon (and vice versa), the system provides a coordinated locking mechanism that works with the files and directories you target for iCloud storage.Īt the heart of the iCloud locking mechanism are file coordinators and file presenters. The daemon that transfers the document to and from iCloud also needs to manipulate it periodically. Your app might not be the only app trying to manipulate the local file at any given moment. When your app needs to read or write a document in iCloud, it must do so in a coordinated manner. For additional information about using specific classes and interfaces, see the corresponding reference documentation. The sections that follow provide more details about how to implement different aspects of iCloud storage for your app. A magazine app might save the issue and page that the user read last, while a stocks app might store the stock symbols the user is tracking. Apps can use this feature to store important state information. It is a way for your app to share very small amounts of data (tens of kilobytes) with other instances of itself. In contrast, the iCloud key-value data store is not something a user would see. A user cares about whether documents are shared across devices and can see and manage those documents from a given device. This is the feature that users think of when they think of iCloud storage. Most apps will use iCloud document storage to share documents from a user’s iCloud account. You are not required to use the NSDocument class to manage your app’s documents, but using it requires less effort on your part. The class even helps handle the potential conflicts that can arise when two devices do manage to update the same file in conflicting ways. This class also seamlessly integrates document changes coming from other devices. Specifically, the NSDocument class handles the creation and use of file coordinators to modify the document. This class does most of the heavy lifting required to read and write files that are stored in iCloud. Figure 4-1 Pushing document changes to iCloudįrom an implementation perspective, the easiest way to manage documents in iCloud is to use the NSDocument class. In this way, the file coordinator acts like a locking mechanism for the document, preventing your app and the daemon from modifying the document simultaneously. File coordinators mediate changes between your app and the daemon that facilitates the transfer of the document to and from iCloud. To prevent large numbers of conflicting changes from occurring at the same time, apps are expected to use file coordinator objects to perform all changes. While in iCloud storage, changes made on one device are stored locally and then pushed to iCloud using a local daemon, as shown in Figure 4-1. After that transfer, the file is transferred to iCloud and to the user’s other devices as soon as possible. First, it is moved from its current location in the file system to a local system-managed directory where it can be monitored by the iCloud service. A document targeted for iCloud storage is not moved to iCloud immediately, though. All documents must be created on a local disk initially and moved to a user’s iCloud account later. If your existing code uses garbage collection, update your code to use ARC instead.ĭocuments in iCloud provide the central location from which updates can be delivered to a user’s computers and iOS devices. Important: The iCloud APIs do not work with garbage collection in macOS.
0 Comments
Leave a Reply. |