Hm, okay, it looks like a look into the crystal ball is unavoidable to answer this.
I tried it out on iOS 10.3.3 and indeed there is no difference in behavior of this method, regardless of whether the Airdrop was accepted by the other device or declined.
Apparently, the completed
boolean in the HandleActivityViewControllerCompletion
so far means this:
"The data was given to a selected activity" or "The data was not given to any activity". It corresponds to whether the button below the share sheet says "Done" or "Cancel". Unfortunately the airdrop activity sets this button to Done even when the drop was declined and well, that kind of makes sense, because it "did something".
I think the problem (design wise) lies in the fact that, usually, activities (custom ones, for example) dismiss the entire UIActivityViewController
when they call activityDidFinish(_:)
. The AidropActivity is obviously special in that it doesn't seem to do that at all, it just displays a "Declined" indicator below its icon when the connection goes through but the other side, well, declines. Plus it changes the sheet's button.
Besides, the entire operation is asynchronous. To me it looks like the Airdrop activity calls its perform()
or prepare(withActivityItems:)
function, starts a remote connection asynchronously and immediately sets the button to "Done" while that is running (I don't even see a way for other activities to do that, but I didn't try). You can even press Done before the other side has accepted or declined, that won't abort the transfer. The Activity even gets notified (if the sheet wasn't yet closed with "Done") to update its icon.
All in all it appears to have special privileges, which makes sense, as the entire Airdrop functionality is special: It runs in the background. The activity merely passes it data and as soon as that's done, itself is done as well (regardless of outcome).
Of course I agree that this is insufficient, but I changing this would probably require Apple to change the API. So it'd be a feature request for you, I strongly doubt there's a (AppStore conform) workaround that I didn't think of...