> In my app, I have an export dialog where the user can select the file to > export as well as choose some other export options. In that dialog, after the > user has selected the file to export (via the file selection dialog), I > display the full path to the file that was returned from the file selection > Dialog. > > So, if I understand you correctly (sorry, I haven't had time to verify this > myself), with this change, passing in "user.home/Documents" to the file > dialog, the user will see "~/Documents" in the file dialog, but the full > Container path will be returned as the selected file. So in my export dialog, > the user would see the full Container path, even though the file selection > dialog had shown a normal ~/Documents path?
If you're using FileDialog (or some variant that eventually boils down to NSSavePanel) then your app will continue to function properly. If you're using a custom dialog then you'll need to switch to FileDialog (or variant...) since NSSavePanel is what triggers powerbox to do it's thing, if NSSavePanel is not invoked to choose the exported file then your app will never be granted permission to write to the file (unless you incant some other, more complicated, voodoo magic). The bottom line is, if what you have now allows you to write to ~/Documents and you're sandboxed then this change should not affect your application at all, except maybe in the UI if you're displaying that path to the user. The user won't notice the difference otherwise. > Additionally what's not clear is (again, sorry, I haven't had time to verify > this myself), if I do export the file to the Documents directory under the > Container path, where does the file actually get saved? In > /Users/nick/Documents or in > /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the > Container's Documents folder, for other applications (Finder, Excel, Preview, > etc) will it be visible in /Users/nick/Documents ? If you look in the app container you'll see that the Data directory returned by NSHomeDirectory() is set up with symlinks back to the users home directory, so when you access files in those directories you're accessing the correct files. IOW, ~/Library/Containers/com.blah.someapp/Data/Documents is the same as ~/Documents, the system does all this for you when the app container is created. > @Brent - you wrote: > "As it is now, apps needing to write app-specific data would need to > special-case for the App Sandbox and go find the Container directory, since > $HOME is not accessible (and only becomes accessible if the user interacts > with a FileDialog)." > > Well, I already had to special case where I write app-specific data for each > of the 3 platforms I support (Mac, Windows & Linux). Any Java app that is > really cross-platform is going to have some platform specific code and > platform specific jvm-launching/packaging, if they want to do things the > recommended way for that platform. A sandboxed Mac version was just another > special case. For that, I use the AppBundler fork to launch the JVM and set > some MAS specific properties so that I know that I'm running in the Mac > sandbox and where the Container directory is. Then the right > platform-specific initialization code in my app can be used to build the > app-specific data in the right place. That's the unfortunately truth of modern (secure) applications, each platform has it's own way of doing things. Have you tried Windows 8 yet? Changes like what Brent is proposing is helping to keep Java consistent with the ever evolving app model, which is ultimately a good thing. -DrD-
