Interface NSFileProviderChangeObserver


  • public interface NSFileProviderChangeObserver
    API-Since: 11.0
    • Method Detail

      • didDeleteItemsWithIdentifiers

        void didDeleteItemsWithIdentifiers​(@NotNull
                                           @NotNull NSArray<java.lang.String> deletedItemIdentifiers)
        Delete existing items. No-op if the item was unknown.
      • didUpdateItems

        void didUpdateItems​(@NotNull
                            @NotNull NSArray<?> updatedItems)
        Send updates to existing items, or insert new items.
      • finishEnumeratingChangesUpToSyncAnchorMoreComing

        void finishEnumeratingChangesUpToSyncAnchorMoreComing​(@NotNull
                                                              @NotNull NSData anchor,
                                                              boolean moreComing)
        This method is used to complete a batch of changes. Follow the advice in -[NSFileProviderChangeObserver suggestedBatchSize] to determine when to call this method. It is expected that the sync anchor passed here be different than the sync anchor that the enumeration started at, unless the client was already up to date on all the changes on the server, and didn't have any pending updates or deletions. Additionally, if the client is up to date on all the changes on the server it should set moreComing to NO. Sync anchor data is limited to 500 bytes. Setting a larger anchor has the same effect as calling finishEnumeratingWithError with an expired sync anchor error.
      • finishEnumeratingWithError

        void finishEnumeratingWithError​(@NotNull
                                        @NotNull NSError error)
        If the enumeration fails with NSFileProviderErrorSyncAnchorExpired, we will drop all cached data and start the enumeration over starting with sync anchor nil.
      • suggestedBatchSize

        default long suggestedBatchSize()
        Size of the batch suggested by the system for better performance. The system will set that property to the value it considers is best suited for the current enumeration. The system can enumerate changes on a container in various cases (container presenter in the UI, file opened in an application, ...). Each case has its own performance profile. In case the enumerator has already more than suggestedBatchSize pending changes ready to enumerate, it is suggested it split the list of changes into several batches. If the enumerator does not have suggestedBatchSize ready to enumerator, the enumerator should finish immediately and not wait for more incoming changes to enumerate. By taking into account the suggested size, the enumeration will guarantee the best user experience possible. Large batches can cause performance issues. And when the device reboots, enumerations will resume from the latest known sync anchor. Telling the system about the latest sync anchor more frequently will reduce the number of re-enumerations on system reboot. The system enforces a maximum of 100 times the suggested size. API-Since: 16.0