A user launches my app, and adds an attachment to an email via a file open dialog. That works fine. My app has permission to access the attachment because the user granted access explicitly through the dialog.
Now my app saves the user’s work as a file, including the path to the attachment as a Folderitem.URLPath.
Next, when the user launches the app and tries to send the attachment, my app throws an error, because of sandboxing, since the user did not explicitly grant access to the file.
I save file data as XML. Using a URLPath used to work fine, and now that Apple requires sandboxing, it “just doesn’t work”. Thanks a lot, Apple.
What is the correct way to do this now that we have no access to files external to our app? There must be a simple solution, but I’ve not found it.
Thanks for the link. But it sounds like SSBs don’t work reliably?
“they work on 10.6, but not on 10.7 ~ 10.7.3 so it will break your application on the earlier versions of 10.7.”
“even when they work on our machines, we’ve found situations where they didn’t for our customers and this then left our customers unable to use our application and incurred negative reviews on the Mac App Store”
Are there any code examples of how to implement an SSB so it actually works reliably?
@Sam Rowlands has a Sandbox kit in the Omegabundle that is supposed to make things like SSB easier. I do not know if it’s available separately.
You could try copying the attachment to your app’s Application Support folder for future use, but I don’t know what your app is or it’s workflow, so it may not be a viable solution.
[quote=165697:@Aaron Hunt]A user launches my app, and adds an attachment to an email via a file open dialog. That works fine. My app has permission to access the attachment because the user granted access explicitly through the dialog.
Now my app saves the user’s work as a file, including the path to the attachment as a Folderitem.URLPath.
Next, when the user launches the app and tries to send the attachment, my app throws an error, because of sandboxing, since the user did not explicitly grant access to the file.
[/quote]
What you could do is to copy the file to your space in appsupport while you have access to it, then point to the copy the next time instead of the original.
[quote=165885:@Tim Parnell]No, because they don’t work reliably
You could try copying the attachment to your app’s Application Support folder for future use[/quote]
That sounds like a pretty reasonable workaround.
But to implement it right, so I’m not misleading customers and wasting their disk space, I’ll have to do a lot of work. If I’m copying the attachments, then I need to add user management of the copied attachments. I’ll also need to make it very clear to the user the attachment is being copied, why and where. Otherwise unwanted copies could persist forever. Users might not like the fact that the file is copied in the first place, but it seems like a much better option than trying to use SSBs since those don’t work… it also seems like a lot of unnecessary fuss. Oh well!
I’m afraid in order to do it right, it’s going to cost you some work.
Consider SSBs as a last resort and yes there is a ton of issues with them, including some new issues when customers migrate to Yosemite (some SSBs get hosed and resort to the root of the boot disk).
The easiest ways are to utilize Apple’s Recent Documents mechanism and/or use Apple’s Window Restoration functions. The code for these are part of the Sandbox kit. Currently the Sandbox Kit is exclusively sold via the Omegabundle.
If you really have to use SSBs, I (of course) would recommend using the code in the Sandbox Kit, yes it is work, but apart from the new issue with Yosemite, it’s the most reliable mechanism yet (and it’s modeled on Apple’s own Objective-C how to).
I love the concept of Sandboxing, I think it’s a brilliant process and frankly am surprised that it took this long to realize. It’s the implementation that I have a problem with. Seems like when they designed it, they missed some pretty simple scenarios and then hastily implemented SSBs to make up for it.
You may be complicating it too much. Look at the way GMail handles attachments.
When you click the clip, it lets you choose a file, then it uploads it and shows it as attached to the message at the bottom of the text editor. If you absolutely want the user to know it has been copied, you could pop a message saying “attachment saved as draft” or something to that effect. Since you will have to keep a pointer to that file with your message to work with it, it is on you to delete it after the message has been sent. You also want to make sure to delete the copy if the user cancels the message.
