Shortcut to read file

[jfoclpf]

Originally posted by @breautek in #426 (comment)

@breautek why reading a file with this plugin needs to be so painful ;) ?
Can't we have a shortcut, such as in NodeJS, simply readFile

I propose the creation of this shortcut to read a file (with Promises)

export function readFile (path, options) {
  options = options || {}
  return new Promise(function (resolve, reject) {
    window.resolveLocalFileSystemURL(path, (fileEntry) => {
      fileEntry.file((file) => {
        const reader = new FileReader()
        reader.onloadend = () => {
          resolve(reader.result)
        }

        switch (options.format) {
          case 'arrayBuffer':
            reader.readAsArrayBuffer(file)
            break
          case 'binaryString':
            reader.readAsBinaryString(file)
            break
          case 'dataURL':
            reader.readAsDataURL(file)
            break
          default:
            reader.readAsText(file)
        }

        reader.onerror = () => {
          reject(Error(`Error occurred reading file: ${path}`))
        }
      })
    }, (error) => {
      reject(Error('resolve error', error))
    })
  })
}

[jfoclpf]

We would use it for example like this

readFile(cordova.file.applicationDirectory + 'www/json/anomalies.json')
  .then((res) => {
     console.log(res)
  }).catch((err) => {
     console.error(err)
  })

[breautek]

@breautek why reading a file with this plugin needs to be so painful ;) ?

The plugins that Apache maintains for the most part aims to follow the W3C spec, so that (in theory) once the spec is implemented by the actual browser/webview, the plugin can simply be removed and the code will continue to work. We don't necessary choose/design the API ourselves. Most of this stems from the aim to "cease to exist" as PhoneGap used to put it.

But I do agree, the W3C spec API is garbage and that's probably why the spec has been discontinued. With that being said, I don't foresee this plugin's API changing though. At least not until W3C has a new spec that replaces the one this plugin is based on, which afaik does not exists.

Abstractions can be made to hide the meat of the filesystem API by creating utility classes/methods like your example, but I think that belongs in the community. If the plugin added those APIs, it will be very difficult to remove or potentially change in the future, should a new W3C spec be introduced.

[jfoclpf]

Abstractions can be made to hide the meat of the filesystem API by creating utility classes/methods like your example, but I think that belongs in the community. If the plugin added those APIs, it will be very difficult to remove or potentially change in the future, should a new W3C spec be introduced.

But don't you agree that these abstraction layers serve exactly to maintain the API stable over the time as W3C spec change, since the end user would be faced only with a readFile(path) function?

Yes, it would demand more maintenance, and that would be a problem, I agree

[breautek]

But don't you agree that these abstraction layers serve exactly to maintain the API stable over the time as W3C spec change, since the end user would be faced only with a readFile(path) function?

This is before my involvement with Apache Cordova but from what I understand, all the Apache plugins were built to "cease to exists" which is why they were created as closely to W3C spec as possible. Many of these plugins were deprecated/discontinued because the webview caught up and these APIs were available. So adding any API that is not part of the spec would mean giving the user encouragement to rely on something potentially won't be replaced by a native webview implementation. As a result, adding "custom" APIs goes against the "cease to exist" mantra that Apache Cordova/PhoneGap had.

This is why I said abstractions or providing an alternate API probably belongs in the third-party community space.

To be clear, I'm not an authoritative figure here. I'm just simply stating what the Apache Cordova community used to do and describing how adding custom APIs doesn't fit in that mantra. To get a broader feel for whether the community supports deviating from W3C spec APIs, for the purposes of adding utility methods, a vote thread could be raised in the mailing list. Personally, I'd probably vote +1.

[jfoclpf]

just a further question @breautek , since XHR requests are blocked with AndroidInsecureFileModeEnabled disabled, how do we download now files from the web to the FS or as dataURL? I was using a function taken from this cordova blog post but it doesn't seem to work anymore, as I am getting CORS issues. But it was working before the new releases of cordova (<=9).

I have in config.xml

  <allow-intent href="http://*/*"/>
  <allow-intent href="https://*/*"/>

and proper <meta http-equiv="Content-Security-Policy" in index.html. As said, it was working before the new release of cordova.

The server is also replying with the header Access-Control-Allow-Origin: *

Thanks again for your time

[jfoclpf]

@breautek I saw now your reply on other thread.

[jfoclpf]

Because this was becoming off topic I opened an issue accordingly

apache/cordova-android#1549