How can I enumerate files under a static folder (such as images where all the static images used by my app are stored) while developing a chrome app?
What I have tried:
- looked at these links 1, 2. i am not trying to read from local or user storage. i want to read from static storage. static storage are the folders where an app stores its static contents - assets like images, css, js etc.
- looked at this link. but my app needs to be able to enumerate all files under a static folder without prompting the user for any action/permission.
i will give an example of why this is useful. imagine i want to release an app using which users can read my poems. i want a static folder where i save poems i write. then as i write new poems, these poems should then be made available automatically without having to do any code changes. further i was able to do this on android without any user prompt whatsoever so expect chrome platform should also support this - there cannot be any security excuses.
If you are looking to enumerate app's own files, it's possible via chrome.runtime.getPackageDirectoryEntry.
It returns a DirectoryEntry for the root of your app that you can navigate and iterate through.
See this question: How do I get a list of filenames in a subfolder of a Chrome extension?
You can't. The user will have to choose some parent folder with chrome.fileSystem.chooseEntry at some point. However, you can arrange things so this is done only once when the app is first installed, and then save the FileEntry using the retained-entry API.
Related
Is it always safe to use the path "/storage/emulated/0/{MY APP NAME}" to store the files ?
I Want to store files in the external storage of the android device and I want to store it in a folder named after the app name this folder needs to be located in the external storage.
Have you tried the package path_provider https://pub.dev/packages/path_provider/install?
It comes with the methods getExternalStorageDirectory() and getApplicationDocumentsDirectory() which might be what you are looking for. As far as I know different os types are automatically considered as well.
try the same package of ext_storage named android_external_storage its the same concept putting the downloaded data for example to the download folder.
Check this thread.
The directory an app can access on sdcard looks like /storage/1718-0217/Android/data/com.example.app_name/files. You can get this with the code below.
(await getExternalStorageDirectories())?[1].path;
One app should only access some restricted directories on sdcard. Or you should use Permission.manageExternalStorage.request(), it is strongly restricted and always return false.
Fortunately, per-app directories can also be scanned by other services such like media.
What is the best way to use assets in Flutter , for example if i have a file for app configuration , should I store the file by getting the app directory using the path_provider plugin -without using assets- and store it ?, or should I add the file to my program folder -add the file to my assets- ?
the same question if I have a small Sqlite database.
and which of these methods is faster , and which is more secure ?
Assets are files that you add to your app during development. You can load them with rootBundle.load() or rootBundle.loadString() but you cannot modify or delete them.
In the app's directory you can store any files that your app downloads or generates from the internet while running. These files can then be opened, deleted, modified, etc. To access your app directory you need the package path_provider, which tells you the path to your app folder.
A sqlite database is normally stored in the app directory. An example package would be here sqflite.
For speed and security I can't make a difference. An app directory is designed so that only the app can access it. Assets are a part of the app, the application file can theoretically be unpacked by anyone. Therefore I would at least not store secret things in the assets.
Well, if by app configuration you mean the user's settings you can use Sqlite, SharedPreferences or Hive (Hive shows a benchmark that says that it is faster than SharedPreferences).
I believe that assets folder is used to store some common files for the app, like images, icons, fonts, etc. And I think that isn't recommended to store files with some kind of config file, mainly with critical info about the app configuration.
Note: I am very new to Swift programming (2 days only) and I am working on this piece of code as part of an ElectronJS project. So please don't mind my ignorance regarding the basics of the language. Thanks.
I have created a Swift app containing a Share App Extension.
Requirements:
The Share App Extension should be able to send the absolute file path of the shared files to the container app, i.e. If the user selects a file (abc.txt) from Desktop in Finder and Shares to my Application, then the Share App Extension should be able to get the file path as
/users/userName/Desktop/abc.txt
What I am struggling with here is how to get the file path of the files shared with the Share App Extension. What is the way to get file path of the attachments in NSExtensionItem that is available to the Share App Extension or is it available from some other object ?
(I am able to successfully use App Groups to share data between Share App Extension and the Application)
In the final project, the Share App Extension becomes a part of an ElectronJS project as mentioned earlier.
Is there a standard way to share the aforementioned information (file path of the attachments) from the Share App Extension to the main/renderer processes of the Electron application.
I am sharing the solutions below. Please bear in mind that these might not be the best possible solutions and I am open to suggestions.
Solution to Point #1:
Briefing: The user selects files from Finder to be shared via the Share App Extension of the application which is registered with the OS if the extension context of the selection matches to that of the Share App Extension. Upon doing so, the Share App Extension receives the extension context alongwith NSExtensionItem. The NSExtensionItem object contains the NSItemProvider object which is the object you'd get for all the files (attachments) shared via the Share App Extension.
Now, for each item type that you receive via the Share App Extension, after looking for the data that your function recognizes via hasItemConforminToTypeIdentifier(_:), you can use UTI (Uniform Type Identifier) to identify its data.
Remedy: Here, the crucial part is to understand that one should be treating their input files as firstly being of the type: kUTTypeURL. Then, in the completionHandler for the loadItem method of the NSItemProvider object one would get NSURL which is basically the file path I was looking for.
Solution to Point #2:
Briefing: The Share App Extension has the luxury of being written in Swift but the main app in our project does not ! The main application is written in ElectronJS which is far far far far from being integratable with Swift ! Except for the fact that the application written in ElectronJS has the ability to be packaged in the form of a dmg application, there is very little integratability between ElectronJS and Swift as far as the language and framework intertwining is concerned.
Premise:
So, the premise is to be able to share the filepaths extracted earlier to be passed from the Share App Extension (written in Swift) to the main application (written in ElectronJS). Now, if the main application was a Cocoa application, things would have been much easier. If both of them belong to the same App group, then using the Swift APIs they could have read/written synchronously to the Shared Memory. However, the problem arises as those APIs are not available in ElectronJS. One remedy can be to run the Swift code in a sandboxed environment within the ElectronJS application using nodeJS libraries. However, a sandboxed environment presents its own nuances in data sharing. So, I have kept this approach on hold for now.
So, the approach that I have chosen right now is to use App Data Directory to share this intermediary information. The Share App Extension would be writing the filepath information in the App Data directory of the application and the ElectronJS application would use nodeJs APIs to access this information. Keep in mind that this is a very primitive approach and requires menial efforts but the requirements for this particular case doesn't need stringent security measures anyhow.
However, I am positively looking for a better way to solve Problem #2.
The Chrome Apps API has the very useful FileSystem API which allows a user to select a file for an app to edit (read and write changes to). However, with the entire Apps API soon to be removed, what other ways exists to edit a file on the local file system?
This is not an opinion-based question, I am asking for all conceivable alternatives.
Per https://developers.chrome.com/apps/migration:
Q: My app uses the chrome.fileSystem API to read and write user-specified files and / or directories. Can this be done on the open web?
A: In general, no. The open web can read single files that the user opens, but cannot retain access to those files, write to those files, or have any access to directories.
If it is critical for your app to read and write directories (e.g. it is a text editor with a folder view), you will need to either have a native helper app and extension combo, or create a native app.
I need help. I'm trying to create a multiplatform mobile application. One of the functionalities is a local file browser that will allow user to select a directory and create a list of file in this directory. I've already spent couple of hours on that issue and I can not find any solution for that.
I've checked http://ngcordova.com/docs/plugins/file/
But if I understand it correctly it is used when I already have a file, it not allows user to pick the directory.
I don't need anything fancy, it should as simple as possible
The Cordova FileSystem plugin (and ngCordova's wrapper) provide the ability the read directories from the file system. They do not provide any UI, so you would use the plugin to ask for a list of directories and then render it as you see fit. (A UL, a table, whatever.) To "browse" you could use a click handler on the list of directories such that when clicked, you then get the files/subdirectories of that folder. Again, the FS plugin adds support for doing that.