public interface NSFileProviderEnumerator
| Modifier and Type | Interface and Description |
|---|---|
static interface |
NSFileProviderEnumerator.Block_currentSyncAnchorWithCompletionHandler |
| Modifier and Type | Method and Description |
|---|---|
default void |
currentSyncAnchorWithCompletionHandler(NSFileProviderEnumerator.Block_currentSyncAnchorWithCompletionHandler completionHandler)
Request the current sync anchor.
|
default void |
enumerateChangesForObserverFromSyncAnchor(NSFileProviderChangeObserver observer,
NSData syncAnchor)
Enumerate changes starting from a sync anchor.
|
void |
enumerateItemsForObserverStartingAtPage(NSFileProviderEnumerationObserver observer,
NSData page)
Enumerate items starting from the specified page, typically
NSFileProviderInitialPageSortedByDate or NSFileProviderInitialPageSortedByName.
|
void |
invalidate() |
default void currentSyncAnchorWithCompletionHandler(NSFileProviderEnumerator.Block_currentSyncAnchorWithCompletionHandler completionHandler)
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.
default void enumerateChangesForObserverFromSyncAnchor(NSFileProviderChangeObserver observer, NSData syncAnchor)
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.
void enumerateItemsForObserverStartingAtPage(NSFileProviderEnumerationObserver observer, NSData page)
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.
void invalidate()