My app successfully saves and reads data from a “Printer Settings” that I create, but it lives in the default folder where the application lives. This is from my code for saving the prefs:
var f As FolderItem
f = New FolderItem("Printer Settings", FolderItem.PathModes.Native)
How do I modify this with the correct syntax to save instead to the current user’s Documents folder? This way, whoever logs into the computer will simply be saving or reading the app preferences from their own Documents folder.
SpecialFolder.ApplicationData.Child(“My App Name”) would be a good choice. This folder, that you create, could also hold other custom settings. Since this is in the ~/Library folder, it would indeed allow settings unique to each user account on the machine.
Thanks all. I’ve been through the documentation above but can’t figure out how to modify my code to support using SpecialFolder.ApplicationData.Child(“My App Name”) .
Here is my code for saving print settings:
Var f As FolderItem
Var bs As BinaryStream
// get a folderitem
f = New FolderItem("Printer Settings", FolderItem.PathModes.Native)
// create a binary file with the type of text (defined in the file types dialog)
bs = BinaryStream.Create(f, True)
// check to see if it was created
If bs <> Nil Then
//write the contents of the editField
bs.Write(App.s.ConvertEncoding(Encodings.UTF8))
// close the binaryStream
bs.Close
End If
This time, developing is quite simple, just replace the above line with: f = SpecialFolder.ApplicationData.Child("My App Name").child("Printer Settings")
Also, no PathModes.Native is required here.
The result looks like:
~/Users/YourName/Library/Application Support/My App Name/Printer Settings
Yes. @Scott_Kahn needs to make his app go step by step through the setting up process. Is the folder there? If not, create it. If it is, is it readable and writeable? If not, abort and tell the user. If it is, does it contain the app’s prefs file? If so, is it really the app’s prefs file? (mine is an SQLite database, so I check it has the expected tables?) If the app’s Prefs file is not there, then create a default one. At this stage, abort the app if a step that is expected to work, doesn’t. But tell the user and preferably write something into a log file.
There are many hundreds of folders and files in my ~Library/ApplicationSupport folder, and not a single one, including those of Apple’s own apps, Adobe’s, and Xojo, conforms to that convention.
In ~Library/Preferences you’ll find a lot of reverse bundle identifiers, but I never use the Preferences folder for my apps’ data.
Weird, I have 18 com.apple.xxx folders from Apple, but yes, almost all does not use com.company. Only com.company from apple, brother and 2 other companies, the rest use the product name (Firefox, Xojo, LibreOffice, Slack, and so on).
@AlbertoD@Julia_Truchsess I can no longer find the reference material and reasons we had been recommending this in the past, so I would agree that it doesn’t look like it’s a requirement.
However, consider how much more useful a bundle identifier is than just a name after an application is gone. It provides the user, should your domain actually exist, a place to start looking into who made that folder.
The bundle identifier system has other benefits too. A matching bundle identifier helps app cleaners and uninstallers know that files belong to your app when a user is attempting to clean it up. It’s also much more reasonably unique when you’re hoping to write app data in that folder.
Considering the benefits for both us as developers and the end user, no it’s not a requirement, but it’s a pretty good place to start.
