My application stores logs in /Users/username/Library/Logs/appname and preferences in /Users/username/Library/Preferences/appname but where I should store the reports it creates.
Originally they were in Logs, but they are not really logs. I then thought about putting them in /Users/username/Library/Reports/appname but the Reports folder does not exist under Library and it seems bad practise to create additional folders at this level.
What is the correct mac-friendly way to do things ?
A good candidate would be your app's folder in ~/Library/Application Support/
You may need to create it, and you should really use the bundle identifier for your app as the folder name.
~/Library/Application Support/com.bundleIdentifier.something/
In there you can create whatever you need to to support your app.
File System Programming Guide
Important: The files in the user’s Documents and Desktop directories
should reflect only the documents that the user created and works with
directly. Similarly, the media directories should contain only the
user’s media files. Those directories must never be used to store data
files that your app creates and manages automatically. If you need a
place to store automatically generated files, use the Library
directory, which is designated specifically for that purpose. For
information on where to put files in the Library directory, see “The
Library Directory Stores App-Specific Files.”
Application Support Use this directory to store all app data files except those associated with the user’s documents. For example, you
might use this directory to store app-created data files,
configuration files, templates, or other fixed or modifiable resources
that are managed by the app. An app might use this directory to store
a modifiable copy of resources contained initially in the app’s
bundle. A game might use this directory to store new levels purchased
by the user and downloaded from a server. All content in this
directory should be placed in a custom subdirectory whose name is that
of your app’s bundle identifier or your company. In iOS, the contents
of this directory are backed up by iTunes.
As far as I figured, those are reports that are the end result of the app itself and are something the user needs to have access to.
Even more so, the reports are HTML (so a valid recognizable format)?
I think that constitutes them as documents.
I would put a folder in documents named after the app and put the reports there.
A lot of apps do that (Office comes to mind at the moment).
Related
I'm creating a macOS FileProviderExtension for the remote Document Storage System (kind of like GoogleDrive), where it is possible to share a single document with multiple folders.
For example, Document1.pdf can simultaneously exist in Folder A and Folder B because it's shared with both folders. In my FileProvider extension, this would mean that file should be accessible in both folders:
Folder A/Document1.pdf
Folder B/Document1.pdf
But the file provider extension will treat those as two completely separate files. I.e., if you download one of them, and then try to open the other one, it will redownload the other one, effectively doubling the used space on user's disk and consuming network connection.
I'm looking for a way to tell the FileProviderItem what is the backing data for the given file, and thus solve problems such as:
If user downloads a file in one location, ideally I would tell the FileProvider extension that the same document in all the other locations is also now downloaded (cloud icon should disappear from all files).
Some approaches I considered:
I thought of using symbolic links as part of solution, but I don't really think that's possible
When user tries to open non-downloaded file, fetchContents(for itemIdentifier) callback is invoked. Once file is downloaded, I would ideally now notify all the other files of the same document that they are downloaded, i.e. by updating the isDownloaded property in NSFileProviderItem, but that doesn't seem to work. Also, even if I do that, I still can't say to file, what his backing data file should be.
By turning off the Sandbox capability, I guess I could, when user tries to download/open the file which has already been downloaded in other location, immediately report that file has been downloaded and provide the copy of already downloaded file as data for the requested file, but there are two drawbacks here:
3.1. I would have to turn off the Sandbox capability because I want to access the file in FileProvider path directly
3.2 System would still use disk space for each file. So, if I have same document in multiple folders, extension would keep all those copies in the system, without the option to tell it that for all those files, there is same backing data file somewhere in extension's Container.
How do I decide which of my application's files go in Program Files (FOLDERID_ProgramFilesX64) and which go in ProgramData? (FOLDERID_ProgramData)? I don't understand what the reason is for splitting up my application's fixed files into these two categories or how I should decide which file goes in what.
For example - image files which my application displays, are they "program" or "data"?
Is there any problem with just putting everything under one or the other?
The application is installed for All Users and has no user-specific configuration files or data.
Program Files is for executables and other static files that came as part of the installation. ProgramData is for user-agnostic data generated during execution such as shared cache, shared databases, shared settings, shared preferences, etc. User-specific data goes in the AppData folder. Note that these are for non-user-visible data. User-visible data belongs in the documents folder (or music, video, custom sibling folder, etc.).
Please see Special Folders and Custom Folders for a detailed explanation. Note that the terminology used varies slightly between the name used in the documentation here, the name of the folder, and the name used by various enumerations used to get these paths from the system.
I have a set of applications that work together. It should be possible to start each of these applications individually by the user (i.e. one application provides a monitoring feature, another a configuration feature etc), therefore I would like them to show up in the Applications folder as different applications (possibly within a directory).
The applications are based on Qt5, so I would like to package Qt along with the applications privately to ensure that Qt is present and available. On the other hand I would like to make sure that I only include a single copy of Qt to avoid bloating the system.
I am using a package installer, due to the inclusion of a LaunchDaemon as well.
How do I place the Qt frameworks needed in order to avoid having multiple copies?
Here's the naive way:
/Applications/
MyCompany/
Foo.app/
Contents/
Info.plist (must use its own plist to specify some properties)
MacOS/
foo
Frameworks/
Qt-Goes-Here??
Bar.app/
Contents/
Info.plist
MacOS/
bar
Frameworks/
Qt-Goes-Here?? - Or can this be a link to the other location?
Since I am not a Mac-guru, any input (including informing me that I am trying something stupid) is very welcome!
There are two possibilities here, the first is
/Library
and the second
/Library/Application Support
If you look there, you'll find folders with contents for various applications. You should be able to create a folder there and add the Qt Framework, then update your applications to point to that using install_name_tool
The docs state the following for /Library: -
The Library directory is the top-level directory for storing private
app-related data and preferences. There are several Library
directories scattered throughout the system but you should always use
the one located inside the current home directory. Do not store files
directly at the top-level of the Library directory. Instead, store
them in one of the specific subdirectories described in this table. In
OS X v10.7 and later, the Finder hides the Library directory in the
user’s home folder by default. Therefore, you should never store files
in this directory that you want the user to access. To get the path to
this directory use the NSLibraryDirectory search path key with the
NSUserDomainMask domain.
For /Library/Application Support: -
The Application Support directory is where your app stores any type of
file that supports the app but is not required for the app to run,
such as document templates or configuration files. The files should be
app-specific but should never store user data. This directory is
located inside the Library directory. Never store files at the top
level of this directory: Always put them in a subdirectory named for
your app or company. If the resources apply to all users on the
system, such as document templates, place them in /Library/Application
Support. To get the path to this directory use the
NSApplicationSupportDirectory search path key with the
NSLocalDomainMask domain. If the resources are user-specific, such as
workspace configuration files, place them in the current user’s
~/Library/Application Support directory. To get the path to this
directory use the NSApplicationSupportDirectory search path key with
the NSUserDomainMask domain.
The full documentation can be found here.
I involved with the development of an application that is intended to deploy on multiple desktop system including the Macintosh.
Our team decided we would like to a drag and drop installation for the Macintosh. However, the application is intended to ship with other content besides the application itself such as example files.
Originally these files were placed in the application bundle, however this was discovered to be problematic as the cross platform libraries used for the user interface will not allow someone to access the contents in the bundle. Also force users to have to dive into a bundle to find content does not offer a great user experience.
To that end, we decided to pull these examples file and what not out of the bundle and place them in a separated folder that lived along side the application bundle. To make sure everything including the examples and the application were copied together during the drag and drop installation, a new top level folder was created that contained everything to be copied.
The problem that now exists is that whereby when originally just the application bundle was copied over to the system, the copying of this top level folder does not cause file associations for the application to occur automatically.
What can be done to associate an application with certain files when someone installs by dragging a folder contain the application bundle?
I suggest you to deliver it separately in one dmg. So your dmg structure will look like next:
MyApp -> Applications
MyApp Examples -> Application Support
Simple, user-friendly, no problems with association.
Actually it looks like the file association is working after all. Someone reported a defect against the installation not making the associations. However, I just tested the installation on a clean system and copying over the folder does seem to make the associations.
I'm building an application where I want to provide the user with a few dozen templates that will internally take the form of property lists. I would also want to group them in categories, which would conveniently be achieved using folders.
While I have contemplated shipping these files as simple resources in my application, I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
I can see that many applications have installed such resources in their application support directory (~/Library/Application Support//...), but I can't seem to find any documentation resource on how to achieve this.
I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
It is. Put them in folders in your project directory, then add the top-level folder(s) to your project. Make sure you add it/them as folder reference(s) and not group(s) (see? that sheet does have a purpose!).
Then, add the folder reference(s) to your Copy Bundle Resources or Copy Files phase.
One word of warning: When you change one of the files in the folder, you may need to “touch” the folder to get Xcode to re-copy it. You can do this in Xcode or from the terminal.
You can group items in sub-folders of your app bundle's Resources directory. Unless you want users to edit these plists, keeping them in your app bundle allows users to drag-n-drop install your app, rather than having to use an installer package (a big win).
You can group them into folders in your application bundle by adding a "New Copy Files Build Phase" to your project as described in this forum post:
http://forums.macrumors.com/showthread.php?t=458594