> > 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. > > My users *will* notice because I display this path in the export dialog, along with the other export options they can use.
Side note: I'm using SWT and it boils down to the NSOpenPanel and NSSavePanel. > > 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. > > Actually, the Documents directory in the Container is NOT a symlink. It is an actual directory. So the 2 key questions are: 1. Is there a way to convert from /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to ~/Documents/somefile.csv to display in the UI for the user? 2. If the file gets saved to /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can other applications (such as Excel) access the file from ~/Documents/somefile.csv ? > > @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. > > Platform specific code for any Java desktop app is inevitable. What bothers me about this proposed change is that you're taking away a useful property (the user's $HOME) and replacing it with something that, to me, is best done in an app's platform specific code, not in the JDK's. And I still need to know the user's $HOME, since the answers to my 2 questions above are probably 'no', so I'll have to add more to my app's Mac sandbox-specific code to get it. Windows 8: I do have a few people using my software on W8, but I have not done anything specific for it. That is to say, I do the same platform specific stuff as I do on W7. Nick
