I am familiar with the regular properties APIs for storing app-specific metadata to a file, but is there any way I can store App metadata within drive without linking it to a specific file?
I would prefer to store some configuration settings, but the only approach I've seen for this so far has been to create an actual file in GDrive (and hope the user doesn't delete it).
Is there a more stable approach?
You can store a configuration in you Application Data Folder on Google Drive.
More infos in the actual documentations, but a quick explanation is that you can store files in an hidden folder visible only by your application (any application using the same api key share the same AppData folder).
For example I store a text file with the settings of an Android application, when the user installs it on a different device, the settings are downloaded to the new device.
The approach using a file to store settings let you keep track of the changes made on the configuration by using versions, but if you are more keen to use properties, you can still create an empty app.config file and store properties on it.
Related
I am working on a windows store app, one of the workflows within the app would allow the user to export a report in html format. The html report relies on a css file so I would like to ensure that the install process could deploy the file in a local folder. If not I would need to read out the file from the assets folder (within the install bundle) and manually write it out but that seems pretty kludgy
https://learn.microsoft.com/en-us/uwp/api/Windows.Storage.KnownFolders?view=winrt-22000
mentions that "The Documents library is not intended for general use." so would require use through file picker but I would prefer to be able to export the document without user intervention without additional store approval headaches (apparently adding Documents library capability to manifest requires additional Microsoft store approval).
Questions
When I create files within the store app it seems the location options are limited and I can only write to Localfolder (which is actually hidden and users cannot easily get to it) - There must be a way to create a file within the MyDocuments directory that is easily accessible by users but looks like that is off limits to a windows store app? So what is the best approach to write reports to storage that can be easily accessed by users
How can one deploy files to a specific directory during install time? Assuming there are some installer commands/manifest directives that would allow this capability?
Or maybe there is a entirely different mechanism to allow for this functionality within the store app and I am just looking in all the wrong places...
Lets say I have a web URL to a file on a cloud storage (like Dropbox, Google Drive, etc). How do I convert that to the corresponding file path on my pc? On Android? On iOS?
Assuming of course I have the utilities/apps installed locally.
EDIT: I interested in file name the reverse direction too. (I.e. when I have the local file path, what is the web path?)
EDIT 2: #Greg just made me realize that the problem with file name is much worse on Google Drive than on Dropbox.
And that is very bad. :-(
The reason? Google has good search capabilities on Drive and therefor I and many, many others have put their documents on Drive. However, once I found it I must locate it on my on computer/device. (If I want to edit a pdf for example.)
EDIT 3: #Dan McGrath kindly asked what parts remain unsolved.
Short answer: All. ;-)
Long answer: My actual use case, see below.
My actual use case is a Zotero web app. Zotero is a reference database where you store references to scientific articles, web pages, etc. The items stored in Zotero may include PDF files or - which I prefer - links to PDF files.
I just want to be able to easy access (read) this PDF files from any computer through the web app. And on my own computer I want to be able to edit the files with my local PDF editor. (Be it Android, Windows or whatever.)
By using a cloud storage I do not have to download/upload the files myself. The cloud storage takes care of that part.
For the "reverse" scenario, that is, you have a file and you want the Dropbox shared link, you can use this API endpoint, assuming you're connected to the account via the API:
https://www.dropbox.com/developers/core/docs#shares
My chrome app needs to save a file with human-readable or standard format such as SQLite (It should be readable outside Chrome).
Is there any API suitable for this purpose?
Some files with .localstorage extension (SQLite format) are in Chrome\User Data\Default\Local Storage folder. Is it possible to create such files by the app?
Edited: The app should not ask user for extra permission.
Thanks for your consideration.
chrome.fileSystem API is what you need.
You will need to ask the user at least once where to save the file, but then you can retain the entry to write again to the same file/folder.
There is no way around asking the user to "escape the sandbox".
You'll want to use the Quota Management API. This is per-origin storage, and you request specific amounts of quota.
It sounds like you also want your users to open the files directly? There's an HTML5 filesystem explorer Chrome app that you can use. It'll show you the files, and you can figure things out from their URLs (e.g. I'm currently using filesystem:http://localhost:8000/temporary/bar for a local experiment).
Or are you looking for something more user friendly? I think you have to use file save in that case, the same way Google Drive does.
I am building a chrome app for Digital Signage where I need the user to select some files from a particular folder (preferably in the app's directory) i.e audio, videos, photos which should be created by the app on install.
The sample code provided by Google requires that the user navigates to a folder like this
chrome.fileSystem.chooseEntry({type: 'openDirectory'}, function(theEntry) {
if (!theEntry) {
output.textContent = 'No Directory selected.';
return;
}
// use local storage to retain access to this file
chrome.storage.local.set({'chosenFile': chrome.fileSystem.retainEntry(theEntry)});
loadDirEntry(theEntry);
});
However, my app simply needs the name of files in that (say Video) known directory for the user to build a playlist, rather than actually selecting a video file.
Is this supported in chrome.fileSystem API? Any pointers to how I cold get this done?
It sounds like you should be using either the app's sandboxed file systems, or the app's install folder itself.
The sandboxed file systems allow the app to store whatever data it wants, in whatever structure it wants. There are two to choose from: persistent or temporary. Temporary may be cleared at any point in time. To use these check out this article. Some of its code may be out of date with the spec. Note also apps need to request the unlimitedStorage to use these.
The install folder itself can be used in a read only way. To do this you use chrome.runtime.getPackageDirectoryEntry.
I'm aware of shortcut links. Looking for behavior similar to that of a native Google doc. File exists, possibly takes up storage, can be renamed/moved/deleted, but the data inside shouldn't be modified except by the app. Possibly, defining export formats/links.
I believe the answer is a simple "no" - Google Drive is for storing user files, not protected application data or configuration data. So you could put a file to a users drive, but only the owner of the drive can control whether the file is shared or changed. So they can edit it, you can't stop them, and there's no reason to think that'll ever be a feature in the future.
To have such control you will need to store such data on your own server, or some other such storage medium.
The only other thing that you would do with only Google Drive is encrypt the configuration file you store, for instance, so it couldn't be easily edited - but that's probably just a bad idea. If you must save a configuration file to a persons drive, bury it inside an application folder and sanity check it to ensure it isn't corrupt - but don't count on a person or application never opening and editing it. If it's something a person shouldn't be able to read or change, don't save it to their drive.
As of April 2012, application data is supported: What is the Application Data folder?.
"Export format links" could be done with Custom file properties, though, I'm unsure of what kind datatypes are supported for the value beyond the example string.