cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From julio cesar sanchez <jcesarmob...@gmail.com>
Subject Re: Introduction
Date Tue, 07 Jul 2015 19:01:30 GMT
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 <bowserj@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 <tyler@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 <muratsu@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.paul@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message