Sandboxed files

Trying to sandbox an app.
I placed support files into ApplicationSupport
Some of these support files are small images.
The app has the ability to add to these images, and allow for re-use.

Problem:
All user saving has to be done using a save as dialog.
To get the files to appear in the list of images, I need the save to occur in a sub folder of the application support folder for my app.

What I find is that in the save dialog, the existing images are hidden.
New images which I save in that folder save successfully, but dont appear in the list of files the app finds in the folder when it next starts
Its as if the originally unpacked files are invisible to ordinary users, and files saved in the folder using a file save dialog are invisible to the app.

Is this another useful feature?

How are you determining that the files have saved successfully if they are not there when your app looks for them?
You are looking in the same location, yes?
Are you saving to SpecialFolder.ApplicationData.Child(“myAppName”).Child(“myImages”) and recovering from there?
I save and recover files in a sandboxed app (as I suspect others here do also) without issue.

Seems I am being misdirected.
I know what folder the support files are in.
In a sandboxed app, that folder is a special one deicated to the app, created in ‘Containers’
(the titular sandbox)

If I set the known folder as the initialdirectory of a saveasdialog, it is ignored and the dialog opens into documents or elsewhere.
Which means customers cannot add to the support folders.
I cant see a way around this as I’d like them to be able to maintain support files in a folder structure.

OIC. Yes, that AFAIK, is by Apple design. If you allow your users to save to folders of their choosing, then you will need to save that location within your prefs or such so your app know to look there next time. As long as that folder was user selected, I THINK you will be OK having your app look there.

If you use GetSaveFolderItem, the user can save wherever he chooses.

As you are saving to a fixed location which is a Sandbox safe location, simply ask the user for the file name?

Then add a export function allowing the user to copy out those files.

We do this in several of our apps, get the occasional e-mail asking where files are saved, apart from that most users just accept it.

Thats where I am heading, I think. Keep it simple first then maybe do something more complex later if theres any feedback.

I don’t know your app, but asking the user for the file name might not be such a good idea. Can you remember EXACTLY what that file was called that you worked on last week?

Maybe show a list of available pictures?

The list of available pictures works as expected.
Saving without a SaveDialog works as expected, and the saved pictures do show up.
They obviously need some name (the file name appears as a caption at the moment) , and I dont fancy inventing some random key.

As Sam suggests, I have changed the routine to pop up a dialog asking for the root name of the saved image, and changed the menu item from ‘Save this thing as…’ into ‘Add this thing to the library…’
Hopefully that explains why we don’t ask for a path.

I wont know if I ‘got away with it’ until I try running this past a reviewer.
Maybe if thats still an issue, I can move to storing these items in a database file, but that feels like overkill.

I appreciate without seeing the whole thing end to end , this situation wont be ‘familiar’ to many people with apps in the store, so I’m grateful for all the input.

Take a look at Cardsmith, even if it’s just to get an idea of how we did it.
http://www.ohanaware.com/cards/

We combined the users card database with the templates on one screen (showing the users cards at the top). It’s far from perfect as I get the occasional e-mail “Where are my cards stored”. However for most of our customers, not a peep, which I interpret as no complaints.

Personally I like this method because it keeps the users cards organized within the application (they don’t have to remember where they saved them), and it solves a whole bunch of Sandbox issues at the same time!

Looks like a good plan.

Not a peep = no complaints.
But as I found out yesterday, one of our apps had a stupid bug in it for the last 2 years, and no-one mentioned it.
I often imagine people think ‘I must have done something wrong’ rather than ‘I’ll ask at least…’

Surprise, this morning I wake up to find a complaint!

The customer really doesn’t get the whole application managing her documents thing, and she’s used to having to pick a folder where to save.

I can see that I need to think about this, to help ease these customers in this way of working.

That’s not the case for a sandboxed app.
They don’t appear to be able to save into the container, or see it for that matter.

But in terms of Sam’s complaint, I might add that even giving non-sandboxed users the ability to save where they like, they still email me and ask me where their documents are. :slight_smile:
Rather like my storage methods in the garage… could be anywhere…

Ha! Can’t win!

Part of my Sandbox Kit, I include the OWRecentItems, which makes it easy to build a Sandbox Safe Recent Items menu (by using the same functions as Obj-C & Swift). Even in a non Sandboxed application, it still provides them with a Open Recent menu.

Perhaps an intro window that explains how CardSmith works and highlight certain features, like that it manages your cards for you.

hmmm… You’ve got me thinking, I wonder if a more direct approach would be the first time they save (most of the time it auto saves for them, so they should never have to do so), it tells them there and then and gives them a “Show Me” button?