IMHO, no-one uses this api so this would be an extremely low risk project. Please, before providing a Promise polyfil, verify that it is not already defined by the browser. ... and before providing the Battery api, verify that it is not already defined by the browser.
Personally, I think if you wanted to take on a project that would get used, the Contacts API is dangling there for the taking, and a much better candidate. My team is hiring! @purplecabbage risingj.com On Tue, Jul 7, 2015 at 12:01 PM, julio cesar sanchez <jcesarmob...@gmail.com > wrote: > It's only supported by android 5 webview (12% share right now), so I think > the plugin makes sense for now even if it's going to be deprecated in the > future and replaced by the browser battery status when more people have > android 5 or greater > > But the discussion about this should be better on the cordova-discuss > https://github.com/cordova/cordova-discuss/issues > > > > 2015-07-07 20:42 GMT+02:00 Joe Bowser <bows...@gmail.com>: > > > I hate to dash your hopes, but I think that we should probably not have a > > Battery Status plugin and defer to browser behaviour on Android, since > > Battery Status is supported on the browser with the latest Android > > WebViews, and with Crosswalk. Any plugin should just be glue code for > > facilitating this behaviour, similar to how we deprecated the Geolocation > > plugin on Android in favour to Browser Geolocation. > > > > That's my two cents on the issue right now. > > > > On Tue, Jul 7, 2015 at 11:17 AM Brian LeRoux <b...@brian.io> wrote: > > > > > exactly so and by all means please feel free to use that, bluebird, > rsvp, > > > q, jakes es6 polyfill or any of the 5000+ libs for Promises [1] > > > > > > though I suggest one limits the scope to the other 200+ libraries > > claiming > > > A+ support! [2] > > > > > > ;P > > > > > > [1] https://www.npmjs.com/search?q=Promise > > > [2] https://www.npmjs.com/search?q=Promise+A%2B > > > > > > > > > On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> > wrote: > > > > > > > I'd just like to mention that jQuery has promises built-in as the > > > > $.Deferred object. It's not quite the same as the official Promises > > spec, > > > > but can be used similarly in most cases. > > > > > > > > > > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote: > > > >> > > > >> We experimented with Promise polyfills and had nothing but trouble. > > I'd > > > >> like to preface by saying: lets not get into a theory war. Some > people > > > like > > > >> promises (fine) and some do not (also fine). My stance is that we > > should > > > >> leave that choice up to our end users. > > > >> > > > >> Lets throw some facts out to colour things. > > > >> > > > >> 1. Promises are a spec that will land in browsers natively [1] > > > >> 2. Promises as a concept have MANY polyfill implementations > > > >> 3. The polyfill landscape is largely divergent and implement > different > > > >> flavors of the concept > > > >> > > > >> Since we implement a User Agent we *could* polyfill to spec. As a > > > plugin. > > > >> (Jake's is probably best [2]) I'd be in favor of this and making > that > > > THE > > > >> plugin dep for companion plugins that require Promises. The problem > > with > > > >> this is #3. If we have a window.Promise it could be clobbered by a > > user > > > >> that is not super aware of how things are composed under the hood. > If > > it > > > >> *could* happen guess what: it will. Some frameworks even force the > > idea > > > of > > > >> Promises that may not be totally on spec. Older jQuery and Ember > come > > to > > > >> mind. > > > >> > > > >> The other way to solve this problem is patience. This is the path I > am > > > most > > > >> in favor of. Lets wait out the native implementation to land in the > > > various > > > >> webviews and at such time we can start using those. > > > >> > > > >> Plugins really should wrap device and operating system API's (in my > > > >> opinion) and we should leave library code for the user land to > figure > > > out. > > > >> The Promise API *is a library* until such time as it has been > > > implemented > > > >> into the language runtimes natively (and not just speculatively > > > >> standardized). Ok I guess faltered into the theory war part there. > ;) > > > >> > > > >> [1] https://promisesaplus.com/ > > > >> [2] https://github.com/jakearchibald/es6-promise > > > >> > > > >> > > > >> > > > >> > > > >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mura...@microsoft.com > > > > > wrote: > > > >> > > > >> Hey Paul, > > > >>> Welcome to Cordova! I've looked at your changes on github and have > > > some > > > >>> early feedback. > > > >>> > > > >>> 1) As per spec you return a Promise on battery.js but to my > > knowledge > > > we > > > >>> don't have a fallback for ES6 Promises on platforms that don't > > > support it > > > >>> yet. I would like to know what other committers think about this > > > problem. > > > >>> 2) I think the old API and the new API can co-exist for a while > > > before we > > > >>> deprecate and remove the old one. I see that the new spec uses a > > > different > > > >>> method name so we should be fine here. > > > >>> > > > >>> Thanks, > > > >>> Murat > > > >>> > > > >>> -----Original Message----- > > > >>> From: Paul Contat [mailto:contat.p...@gmail.com] > > > >>> Sent: Wednesday, July 1, 2015 12:38 AM > > > >>> To: dev@cordova.apache.org > > > >>> Subject: Introduction > > > >>> > > > >>> Hello everyone, > > > >>> > > > >>> My name is Paul Contat, and I'm an engineering student and > currently > > > doing > > > >>> an internship at W3C focusing on aligning cordova API with W3C > ones > > > where > > > >>> applicable, as part of the HTML5Apps EU project ( > > > >>> > > > > > > http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/ > > > >>> ) > > > >>> > > > >>> For my internship, I’m planning to contribute to the cordova > > project, > > > >>> starting by the BatteryStatus API ( > > > >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible. > > > >>> > > > >>> I've just signed the ICLA, created an account on Apache JIRA so > I’m > > > ready > > > >>> to start and submitted my first pull request: > > > >>> https://github.com/apache/cordova-plugin-battery-status/pull/24 > > > >>> > > > >>> I’m looking forward to feedback on whether I’m on the right path > for > > > >>> updating the Battery plugin API; I’m in particular interested to > > > understand > > > >>> if and how the current API should be deprecated once we get to a > > stage > > > >>> where the new API is deemed in a good enough shape. > > > >>> > > > >>> Best regards, > > > >>> Paul > > > >> > > > >> > > > >> > > > > -- > > > > Tyler Freeman > > > > CTO, Tappur > > > > http://tappur.co > > > > > > > > Sent from mobile > > > > > > > > > >
