Home > Mobile >  Why is fetchContents(...) called when opening an already materialized file?
Why is fetchContents(...) called when opening an already materialized file?

Time:11-22

I am implementing a file provider based on NSFileProviderReplicatedExtension on macOS. Currently I am working on the download of remote dataless files which works fine so far. It is materialized and available locally and the related NSFileProviderItem object I provide to the system returns true for isDownloaded and isMostRecentVersionDownloaded.

When I open the plain text file in Finder in TextEdit, then it is actually opened by the app but almost immediately the system also calls fetchContents(...) on my extension object. I do not understand why because there is no need to fetch the contents.

I tried various ways to call the mandatory completion handler of fetchContents(...), but apparently either a URL to a local content file and the NSFileProviderItem have to be provided or an Error.

Note: When opening the plain text file through Finder in TextEdit the modifyItem(...) function on my file provider extension is called, too, to update the .lastUsedDate. In that completion handler I provide false as the argument which tells the system to request the item contents.

How can I make clear that the system should not call fetchContents(...) for already downloaded files over and over again?

CodePudding user response:

In the modifyItem(...) call I passed through the NSFileProviderItem argument provided by the system. That was my mistake. The item provided by the system does not have an itemVersion property defined as it is defined by the other baseVersion argument on modifyItem(...) and tracked by my own code. Returning my own NSFileProviderItem with the correct version information is the key for the system not requesting content retrieval again.


See also: my crosspost in the Apple Developer Forums.

  • Related