cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [cordova-plugins/statusbar] Publishing as core
Date Tue, 11 Mar 2014 14:37:21 GMT
Plugins allow us to share JS. Rolling statusbar into platforms means
different JS for all platforms, and make it easier for the APIs to diverge.

Plugins allow us to share docs, and to have the docs live with the code.
APIs like Android's "app" plugin don't have very good docs (or maybe they
are just undiscoverable, or maybe I've just missed where they are). But
having consistency with docs is a big win I think, so having statusbar as a
plugin means devs can go to its plugin page to find its docs.

I think just having default plugins would achieve the "everyone will
probably want it" concern. But having it show up in "cordova plugin ls"
will help devs discover that it's there and that they should probably use
it.


On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:

> On Mon Mar 10 04:07 PM, Jesse wrote:
> > More on the concept of rolling into a platform ...
> > My distinction is that there are some things that every platform should
> consider a
> > baseline of browser functionality, and if the OS SDKs do not provide it
> out of the
> > box, then we should. Some examples of this :
> >
> > 1. Local XHR, Windows Phone does not support xhr when trying to access a
> file://
> > url, I could have made this a plugin that would only be used on WP, but
> I think
> > this functionality should be intrinsic, so now it is.
>
> +1
>
> > 2. console.log: if you create a brand new iOS cordova project, the
> hello-world app
> > gives you some boilerplate code to get started.  One thing that new
> users may
> > notice is the use of console.log in index.js, however, they will never
> see the
> > output.  Hooking conosle.log output to go to the command-line output of
> a run
> > command, or the output window of visual studio, or xcode is the minimum
> > functionality, and I personally think it should be built in. This is
> probably best
> > discussed in a new thread, as I know Michal has a different opinion,
> because of
> > some weinre edge case, but this is meant to serve more as an example.
> >
>
> Yep agree, distinction here is there's ~ "web dev" flow and "native dev"
> flow (using an IDE)
>
> Both of those should be core somehow
>
>

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