I'm a Windows developer finally getting my feet wet on Mac - I've already stumbled across translocation.
I have a Qt-based application that I am porting to Mac and have a few basic types of user data. The app is distributed currently via zip file
1) Settings/config data. I understand this belongs in a plist file
2) XML-based application data. This data is intended to be edited by both users and the application. In most cases, it will only be power users that manually edit these files.
3) Image-based (jpg/png) in-application icons. This data is used by the application and expected to be created/provided separately by users.
On Windows, both 2 and 3 are simply located in subdirectories of the .exe.
What are the options or "correct" locations for such application data?
The usual location is a custom folder in the Application Support directory. This directory exists in the local domain (/Library/Application Support/) to save data for all users and in the user domain (~/Library/Application Support/) to save data per user.
There is a convention to name the custom folder in Application Support with the bundle identifier of the application but this is not mandatory.
While the Application Support directory is created implicitly your app is responsible to create the custom folder.
(NS)FileManager provides an API to get the Application Support directory without hard-coding paths. If your app is sandboxed you must use this (NS)FileManager API anyway
Related
I am using MS Access 2016. I have a project which in part creates and moves folders around. I am currently using Application.CurrentPath & [form control value] & "\" (etc.) to store the created folders (and to move them when users are done). When I deploy I want to split the db so I can work on the front-end without disturbing users, and so that multiple users can work simultaneously. The back-end will be stored at a shared network location. Users will get a copy of the front-end on their PC to speed things up.
If I do it this way, the folders that the solution creates will be created in the same directory as the users' front-end (no bueno.)
Should I change the code to be hard-coded to some network location (which means moving it is a pain) or change the code to refer to the back-end location? If I refer to the back-end location, what does that code look like?
Many thanks in advance!
I'm using WER to generate crash dumps for my application using this method:
https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
My app runs in pods in Kubernetes, and I'm writing these dumps to a network share mounted in the pods. I then have a web application that queries this share for dump files and displays them in a view for download.
The problem I'm running into is the file name of the dumps. The file name is in this format:
<exe name><PID>.dmp
I'd like to add some identifying information (particularly hostname) to the name of the file. Is this possible? I've been searching Google since yesterday (using various phrasing, etc.) but I'm coming up blank.
I'm quite new to android and I am currently working on a app which should utilize a Room database. Following the documentation a room database can be created through the following lines:
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Now where did room create the database file?
It can't be found in my project folder.
The documentation doesn't mention anything about it and -generally speaking- barely gives any information about how this thing works.
Where is the database?
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
The list of questions is long.
Any information about the .build() thing aswell as further information about Room (misconceptions etc.) are very appreciated, for the documentation doesn't really make things clear for me.
Thank you!
Now where did room create the database file?
The database (a file) will be placed at the default location on the actual device which is data/data/<the_package_name>/database/MyDB.
In your case, as you have coded :-
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Then the database files will be: -
data/data/<your_package_name>/databases/MyDB
data/data/<your_package_name>/databases/MyDB-wal
data/data/<your_package_name>/databases/MyDB-shm
It can't be found in my project folder.
The database file is not part of the project, it is a file that is created and maintained on the actual device on which the App has been installed.
However, you can use Database Inspector (now App Inspection) on Android Studio to view the database e.g. :-
You can also view the files, if whatever device you test on allows access, by using Device File Explorer. e.g.
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
Yes, if the file exists then it is opened otherwise the file is created. If you uninstall the App this effectively delete's the file. The whole idea of a database is that it persists.
The build() undertakes various tasks, primarily seeing if the underlying file exists and then opening the file. In doing so it
extracts the version number that is stored in the file and compares the number against the number coded within the App (via the #Database).
If the version number from the App is greater then an attempt is tried to find a Migration (recently AutoMigration's have been added to Room).
compares the expected schema (according to the entities defined as part of the #Database), against what is found in the file.
A mismatch will result in the app crashing, so fixes would have to be made.
Note references to file is a simplification, by default Room uses a loggin mode called WAL (Write-Ahead Logging). In WAL mode there will be an additional 2 files that the SQLite routines maintain (you don't need to do anything):-
the database file name suffixed with -wal is the primary wal file into which changes are written (they are applied to the main database automatically).
the database file name suffixed with -shm (this is a WAL file for the WAL file).
When I run my Eclipse RCP application, it creates a whole lot of directories in my $HOME/.eclipse directory. What is this?
I don't want the files there, how can I hinder them from getting there? The rational for this: the application must run very clean and only leave files at one specific location (not $HOME/.eclipse).
I'd figured it was controlled by osgi.instance.area so tried to set this to different values (a directory, #none, #noDfault etc...) but can't stop the application from creating directories in $HOME/.eclipse. -data and other arguments works as expected.
On my system the only thing that is stored in .eclipse is the Equinox Secure Storage. Here is the blurb on the doc page for that:
By default, secure storage is located in your home directory. On Windows that typically resolves to "C:\Documents and Settings\.eclipse\org.eclipse.equinox.security". This location is selected to allow multiple Eclipse-based applications to share the same secure storage.
If you would like to modify the location of the default secure storage, you can use the "-eclipse.keyring " runtime option. The is a path to the file which is used to persist the secure storage data.
Here is the online reference.
What's the standard path on MacOS X for storing application data that is to be shared by different users? I am not talking about temporary data, but data which is used by one particular program on a regular basis and belongs to no particular user. For example a game highscore table.
Thanks,
Adrian
I believe you're talking about Support files - a file that supports the application but is not required to run (your highscore table for example).
These files should be put in ~/Library/Application Support/YourApp or /Library/Application Support/YourApp for shared users.
The Library Directory Stores App-Specific Files
To get the directory, you can use the function "NSSearchPathForDirectoriesInDomains", with the directory parameter being "NSApplicationSupportDirectory", and the domainMask parameter being "NSLocalDomainMask".
(NSApplicationSupportDirectory is the "Location of application support files", while NSLocalDomainMask means "Local to the current machine—the place to install items available to everyone on this machine.")
Some applications put files into the /Users/Shared-directory. I know it's the standard way to share files between users, but I'm not 100% sure it's thought for application data storage.
The there's the /Library*-folder which is thought for systemwide common data, similiar to the /Users/Usernames/Library.
But you certainly shouldn't write data to the Application.app-directory. Users without admin rights won't even have the right to write to these directories.
* = Or /System/Library. Need to verify.