Is it mandatory to return NSProgress before calling completionHandler in fetchPartialContentsForItemWithIdentifier

Question

Created 2w

Replies 1

Boosts 0

Participants 2

In the FileProvider framework, most of the functions (such as fetchPartialContentsForItemWithIdentifier, fetchContentsForItemWithIdentifier etc.) are expected to return an NSProgress object. In a case where an error is encountered before the function returns the NSProgress object, is it allowed to invoke the completionHandler with an error prior to returning the NSProgress object to the File Provider framework?

Answered by DTS Engineer in 841530022

In the FileProvider framework, most of the functions (such as fetchPartialContentsForItemWithIdentifier, fetchContentsForItemWithIdentifier etc.) are expected to return an NSProgress object. In a case where an error is encountered before the function returns the NSProgress object, is it allowed to invoke the completionHandler with an error prior to returning the NSProgress object to the File Provider framework?

This is one of those situations where the right way to think about this isn't "will the system let me so this" but is really "what's the safest possible way I can do this".

The problem is that unless we've specifically documented that your is supposed to/allowed to do this, then any answer I (or ANY engineer at Apple....) could give isn't actually really reliable. More specifically:

It may very well work fine today (I haven't actually tried to validate that in great detail), but that doesn't mean it will work in the future.
The engineering team might even want/expect it to work fine... but the fact that it hasn't been documented as such means we haven't actually promised that it will work.
That lack of formal guarantee means that IF a problem were to occur in the future, it's more likely that the fix would be delayed (because restoring an "informal" behavior had lower priority) or not a occur at all (because circumstances prevented a straightforward fix and/or would require excessive work).

You can (and should) file a bug (please post the bug number back here if you do) asking us to provide official guidance on to how handle this, but until something is actually in our documentation there's always a risk that it it could break...

...at which point your right back where you started, dealing with the same issue. The details may vary a bit depending on the API you're interacting with, but what I would probably do is:

Return an NSProgress object that's already "done", either as "Cancelled" or possibly as "Finished". That way you don't need to worry about generating artificial progress on an operation that isn't actually doing anything.
Use an async API like DispatchQueue async / asyncAfter to "immediately" call the completion handler. Note that the exactly asynchronous API use doesn't necessarily matter, the goal is simply that you don't call the completion handler until after you've returned the progress object..

The overall idea here is have your implementation stay within the expected API flow while minimizing any unnecessary complexity in your implementation (like fake progress tracking).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

2w

Recommended

In the FileProvider framework, most of the functions (such as fetchPartialContentsForItemWithIdentifier, fetchContentsForItemWithIdentifier etc.) are expected to return an NSProgress object. In a case where an error is encountered before the function returns the NSProgress object, is it allowed to invoke the completionHandler with an error prior to returning the NSProgress object to the File Provider framework?

This is one of those situations where the right way to think about this isn't "will the system let me so this" but is really "what's the safest possible way I can do this".

The problem is that unless we've specifically documented that your is supposed to/allowed to do this, then any answer I (or ANY engineer at Apple....) could give isn't actually really reliable. More specifically:

It may very well work fine today (I haven't actually tried to validate that in great detail), but that doesn't mean it will work in the future.
The engineering team might even want/expect it to work fine... but the fact that it hasn't been documented as such means we haven't actually promised that it will work.
That lack of formal guarantee means that IF a problem were to occur in the future, it's more likely that the fix would be delayed (because restoring an "informal" behavior had lower priority) or not a occur at all (because circumstances prevented a straightforward fix and/or would require excessive work).

You can (and should) file a bug (please post the bug number back here if you do) asking us to provide official guidance on to how handle this, but until something is actually in our documentation there's always a risk that it it could break...

...at which point your right back where you started, dealing with the same issue. The details may vary a bit depending on the API you're interacting with, but what I would probably do is:

Return an NSProgress object that's already "done", either as "Cancelled" or possibly as "Finished". That way you don't need to worry about generating artificial progress on an operation that isn't actually doing anything.
Use an async API like DispatchQueue async / asyncAfter to "immediately" call the completion handler. Note that the exactly asynchronous API use doesn't necessarily matter, the goal is simply that you don't call the completion handler until after you've returned the progress object..

The overall idea here is have your implementation stay within the expected API flow while minimizing any unnecessary complexity in your implementation (like fake progress tracking).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0