Promises supported?

[GitToTheHub]

Hi, does this API supports Promises, so that i can do
resolveLocalFileSystemURL(url).then(...)
or must i wrap every api call in Promises?

Thanks for responding!

[breautek]

Promises are not supported.

[GitToTheHub]

Can you maybe integrate it? I did a polyfill and it was not so much work.

[breautek]

I'll treat this as a feature request, but I don't think we can support promises for as long as we support Android 4.4, not without a polyfill library anyway.

I can't guarantee when this will be done as Cordova is a bunch of volunteers with limited time. You are however welcome to make a PR.

[GitToTheHub]

Thank you, for treating it as a feature request.
I looked for the minimum Android version of promise support, and saw the minimum version 4.4.3. Would this not be enough to support? I'll see, if i can make pr or something else.

[breautek]

I believe Cordova supports 4.4.x. Additionally, plugins that offer the Browser platform support I believe needs to be able to support IE. So polyfills will also be needed in those cases.

[GitToTheHub]

Ok, it's not that hard to add a polyfill. I will see, what i can do.

[Nashorn]

Now all hope is on 1 man, the GitToTheHub

[GitToTheHub]

;)

[brody4hire]

I would actually favor using some kind of Promise-like utility such as https://github.com/joelnet/XPromise rather than an actual polyfill for multiple reasons, major is unpredictability of behavior and interference with other modules & packages. Some nice arguments here: https://ponyfoo.com/articles/polyfills-or-ponyfills

[breautek]

I Disagree. The arguments in that article is mostly for language syntax features such as arrow functions (Which you can't really polyfill properly anyway, as stated in the article).

Using a promise-like utility is just another piece of software that will need to be kept up-to-date. Using a polyfill is something that can be activated for older browsers that don't support a particular feature and can be safely removed in the future without refactoring anything, as the codebase is already using the same interface as the browser API.

Additionally, using Promise that is supplied by the native code will likely outperform any javascript implementation of a feature which is why polyfilling when required is generally better than using an alternate "feature-like" library in my opinion. I think this is particularly important in this case because asynchronous code obviously happens very frequently in most applications, so if promises are used, they should as efficient as possible.

I've used es6-promise to support IE, older versions of Safari, as well as android 4.1+ in my projects. It has consistent behaviour native-browser Promise on modern browsers.

Also, https://github.com/joelnet/XPromise is not a production library. It's built as a challenge to create usable/tangible library without the use of variables for fun.

The challenge is to create a piece of software (something real, tangible and more than a hello world) without any variables. The idea came from a tweet of Samer Buna’s article. Which I responded (in jest) with try to “code without variables”.

[GitToTheHub]

@breautek Really good explained. For the majority, we don't even need a polyfill. iOS has support since iOS 8 and Android since 4.4.3.

What i don't understand is, that there are so many Promise polyfill solutions. When i'm searching for a polyfill, the first entry i found is
https://www.npmjs.com/package/promise-polyfill
So i don't understand, for example, why @breautek is choosing another package, or why e.g. the creator of cordova-plugin-googlemaps was choosing https://github.com/then/promise

Maybe a lot ot this persons wanted to understand the techniques behind the scenes and published there experiences. But i think the api is not that hard and it should be not a great thing which polyfill to choose or which is better then the others.

[Nashorn]

This might be a stupid question but why do you even need promises?