pub unsafe trait NSFileProviderEnumerator: NSObjectProtocol {
// Provided methods
unsafe fn invalidate(&self)
where Self: Sized + Message { ... }
unsafe fn enumerateItemsForObserver_startingAtPage(
&self,
observer: &ProtocolObject<dyn NSFileProviderEnumerationObserver>,
page: &NSFileProviderPage,
)
where Self: Sized + Message { ... }
unsafe fn enumerateChangesForObserver_fromSyncAnchor(
&self,
observer: &ProtocolObject<dyn NSFileProviderChangeObserver>,
sync_anchor: &NSFileProviderSyncAnchor,
)
where Self: Sized + Message { ... }
unsafe fn currentSyncAnchorWithCompletionHandler(
&self,
completion_handler: &DynBlock<dyn Fn(*mut NSFileProviderSyncAnchor)>,
)
where Self: Sized + Message { ... }
}NSFileProviderEnumerating only.Expand description
Provided Methods§
unsafe fn invalidate(&self)
Sourceunsafe fn enumerateItemsForObserver_startingAtPage(
&self,
observer: &ProtocolObject<dyn NSFileProviderEnumerationObserver>,
page: &NSFileProviderPage,
)
unsafe fn enumerateItemsForObserver_startingAtPage( &self, observer: &ProtocolObject<dyn NSFileProviderEnumerationObserver>, page: &NSFileProviderPage, )
Enumerate items starting from the specified page, typically NSFileProviderInitialPageSortedByDate or NSFileProviderInitialPageSortedByName.
Pagination allows large collections to be enumerated in multiple batches. The sort order specified in the initial page is important even if the enumeration results will actually be sorted again before display. If results are sorted correctly across pages, then the new results will be appended at the bottom of the list, probably not on screen, which is the best user experience. Otherwise results from the second page might be inserted in the results from the first page, causing bizarre animations.
The page data should contain whatever information is needed to resume the enumeration after the previous page. If a file provider sends batches of 200 items to -[NSFileProviderEnumerationObserver didEnumerateItems:] for example, then successive pages might contain offsets in increments of 200.
§Execution time:
This method is not expected to take more than a few seconds to complete the enumeration of a page of items. If the enumeration may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to either report an error (for instance NSFileProviderErrorServerUnreachable) or return everything that is readily available and wait for the enumeration of the next page.
Sourceunsafe fn enumerateChangesForObserver_fromSyncAnchor(
&self,
observer: &ProtocolObject<dyn NSFileProviderChangeObserver>,
sync_anchor: &NSFileProviderSyncAnchor,
)
unsafe fn enumerateChangesForObserver_fromSyncAnchor( &self, observer: &ProtocolObject<dyn NSFileProviderChangeObserver>, sync_anchor: &NSFileProviderSyncAnchor, )
Enumerate changes starting from a sync anchor. This should enumerate /all/ changes (not restricted to a specific page) since the given sync anchor.
Until the enumeration update is invalidated, a call to -[NSFileProviderManager signalEnumeratorForContainerItemIdentifier:completionHandler:] will trigger a call to enumerateFromSyncAnchor with the latest known sync anchor, giving the file provider (app or extension) a chance to notify about changes.
The anchor data should contain whatever information is needed to resume enumerating changes from the previous synchronization point. A naive sync anchor might for example be the date of the last change that was sent from the server to the client, meaning that at that date, the client was in sync with all the server changes. A request to enumerate changes from that sync anchor would only return the changes that happened after that date, which are therefore changes that the client doesn’t yet know about.
NOTE that the change-based observation methods are marked optional for historical reasons, but are really required. System performance will be severely degraded if they are not implemented.
§Execution time:
This method is not expected to take more than a few seconds to complete the enumeration of a batch of items. If the enumeration may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to either report an error (for instance NSFileProviderErrorServerUnreachable) or return everything that is readily available and wait for the enumeration of the next batch.
Sourceunsafe fn currentSyncAnchorWithCompletionHandler(
&self,
completion_handler: &DynBlock<dyn Fn(*mut NSFileProviderSyncAnchor)>,
)
Available on crate feature block2 only.
unsafe fn currentSyncAnchorWithCompletionHandler( &self, completion_handler: &DynBlock<dyn Fn(*mut NSFileProviderSyncAnchor)>, )
block2 only.Request the current sync anchor.
To keep an enumeration updated, the system will typically
- request the current sync anchor (1)
- enumerate items starting with an initial page
- continue enumerating pages, each time from the page returned in the previous enumeration, until finishEnumeratingUpToPage: is called with nextPage set to nil
- enumerate changes starting from the sync anchor returned in (1), until finishEnumeratingChangesUpToSyncAnchor: is called with the latest sync anchor. If moreComing is YES, continue enumerating changes, using the latest sync anchor returned. If moreComing is NO, stop enumerating.
- When the extension calls -[NSFileProviderManager signalEnumeratorForContainerItemIdentifier: completionHandler:] to signal more changes, the system will again enumerate changes, starting at the latest known sync anchor from finishEnumeratingChangesUpToSyncAnchor.
NOTE that the change-based observation methods are marked optional for historical reasons, but are really required. System performance will be severely degraded if they are not implemented.