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.
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...
I'm developing a Chrome application where I want to do basic stuff with currently downloaded files(mostly I want to move them to a new location using an application or extension whichever is possible).
I'm able to get access to the image, audio, video file using the mediaGallery API of Chrome apps. Is there a possible way I can get access to and being able to move other format file from their current location to some other location using Chromium apps?
You certainly read the contents of any directory that the user has given you access to. And, once the user has done this, you can retain the entry so on subsequent executions you don't have to keep asking the user to select the directory. Then, once you have a file, you can use the file API to manipulate it.
This is in principle all the media API does, except that it comes with knowledge of some built-in media directories.
I'm building a Store App using WinJS and I need to create a structure with some info related the user's tree folder (every drive, not only C:), is there any way to get the whole Folder structure from every drive without using the File/FolderPicker?
No, by design Windows Store Apps run inside an app container that limits what they're allowed to do without user consent. The only areas of storage that are openly accessible without further consent are the app's package location (which is read-only, see [Windows.ApplicationModel.Package.Current.installedLocation][1]) and its app data folders (see Windows.Storage.ApplicationData).
If the app declares library access in its manifest (for Pictures, Videos, and Music), these are noted on the app's page in the Store such that the act of installing the app amounts to user consent. There is also a RemovableStorage library that's similar, but for that you have to declare specific file types.
If an app is registered for a file type association in its manifest, and the user launches the app through a file, that grants access.
Beyond this, the way you get access to any other storage location is through the pickers. However, if you have the user pick once, you can save that consent by saving the StorageFolder into the Windows.Storage.AccessCache API, so that you can open the folder again in an future app session without having to reacquire consent.
For all the details of this, refer to the first section of Chapter 11, "The Story of State, Part 2: User Data," of my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition.
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.
I'm using the HTML5 FileSystem API in a Chrome Packaged App to write to a log file. I want the user to be able to download this file, so I tried something along the lines of:
fs.root.getFile('log.txt', {create: false}, function(fileEntry) {
var url = fileEntry.toURL();
// do something with the file url
});
This doesn't help though, because the URL is something like filesystem:chrome-extension://eekedjcagggbfigdmifkmhkjbhiklnpj/temporary/log.txt and it's not possible to open it somewhere.
What technique would you recommend to make a FileSystem API file in a Packaged App downloadable?
Edit: After reading through Ben Well's answer below, I realized that I'll have to clarify even more what I want. It would seem especially nice to me if there would be a technique that doesn't imply loading the HTML5 Filesystem API file contents, building a blob from it and writing that to a user-chosen path with chrome.fileSystem API.
Have you tried using chrome.fileSystem.chooseEntry? This API lets your app save files to the user's hard disk, wherever they want, letting your program have a Save As kind of command. This is a bit different to a download link, but is also more in harmony with V2 apps being like native apps.
chrome.fileSystem pops up a dialog asking the user to choose a location for a file. If you use the options for saving files, this returns you a file entry that has permissions to write to the location chosen by the user. The user can also create new files when you use these options.