If the share destination wants that an item is stored to Fastlane after user does the sharing, the destination must register to action "open-shared" for the MIME types it knows how to share.
When the user clicks on a Fastlane item, the share destination is opened and the same id argument is passed as what is passed in the original share transaction. This way, the destination can deep link the user into the right view corresponding to what was shared and what is the status of the sharing transaction. For example, it might be that a big image was being shared, but the sharing didn't complete last time the application was running. When user deep links back to this sharing transaction, the destination implementation may offer the user the possibility to re-try the sharing.
Assuming destination has registered to action "open-shared", the Fastlane item will be added if the destination returns with Invocation.OK status, which in the code might look something like this:
If the user cancels the sharing inside the destination application UI or if the user uses the hardware back-key to navigate away from the destination application, the destination must return Invocation.CANCELLED and quit itself. With this, it is made sure that the user can see the list of destinations again to potentially re-initiate sharing to some other destination. In the, this can look something like:
contentHandlerServer.finish(invocation, Invocation.CANCELLED); destroyApp(true); notifyDestroyed();
If the destination wants to keep the user in the destination application experience, but has not yet been able to handle the sharing properly, it can reply with Invocation.INITIATED. As a result of this, Share UI considers that sharing has ended, but does not create a Fastlane item, because the sharing was not completed.
Last updated 9 October 2013
We appreciate your feedback.