cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo
Date Fri, 18 Oct 2013 18:17:38 GMT
Not feeling hot about the namespace thing - as Jesse said it might limit
us. Ok - if we do a cordova-plugins repo it won't be hard to move the
plugins branch to it with a filter-branch option, preserving history --
great.

I think a generic preferences plugin is ok  (wouldn't be hard to convert
the interface anyway for the existing code I have for iOS) with the usual
problems of user education/documentation for upgrades. Putting in the
preference name itself might be error prone (who's a great speller here?),
but I would amend the pseudo code to actually have a failure/success
callback as well for these situations.

navigator.cordovaPreferences.setPreference(win, fail,
'iOS-GapBetweenPages",0);
navigator.cordovaPreferences.getPreference(win, fail,
'iOS-GapBetweenPages");

On Fri, Oct 18, 2013 at 10:59 AM, Jesse <purplecabbage@gmail.com> wrote:

> If you namespace it to the platform, and later it makes sense to support it
> on another device, you will have even more issues.
> I think the best approach mentioned is the cordova-plugins repo which is
> like the wild-west that is purplecabbage/phonegap-plugins except it is
> managed by cordova contributors only.
>
> Another alternative is to create a generic 'preferences' plugin which IS
> supported by all platforms, BUT the actual preferences differ between
> platforms.
>
> Something like:
> navigator.cordovaPreferences.setPreference('iOS-GapBetweenPages",0);
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Oct 18, 2013 at 10:45 AM, David Kemp <drkemp@google.com> wrote:
>
> > I would hate to see plugins that are currently ios only get put there,
> and
> > then later have another platform supported. That would be ugly.
> >
> > Can we at least insist that any plugin that goes in the ios platform
> have a
> > name like ios-* (likewise for other platforms)
> >
> >
> > On Fri, Oct 18, 2013 at 1:07 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >
> > > +1 to metadata for repo location.
> > >
> > > However, I'm still not 100% why these plugins should live in the
> platform
> > > repo?  Its just an arbitrary container, right?  I think the fact thats
> > its
> > > a plugin is more relevant than the fact that they only support ios.  If
> > > cordova-labs doesn't feel right, then why not make a single
> > cordova-plugins
> > > repo?  I know we used to have a phonegap-plugins repo and we didn't
> like
> > > that, but thats because it had external contributions and unsupported
> > stale
> > > code.
> > >
> > > It doesn't really matter I guess, but I just don't see the point of
> > having
> > > seperated out all of the plugins into separate repos and now we shove
> > some
> > > back alongside platforms.
> > >
> > > -Michal
> > >
> > >
> > > On Thu, Oct 17, 2013 at 7:32 PM, Shazron <shazron@gmail.com> wrote:
> > >
> > > > Also, to avoid any "git entanglements" with trying to keep history
> > > between
> > > > the two repos (it's possible but I'm not at level of git black-belt
> > yet),
> > > > I'm just going to copy the folders in, and add them.
> > > >
> > > >
> > > > On Thu, Oct 17, 2013 at 4:11 PM, Shazron <shazron@gmail.com> wrote:
> > > >
> > > > > I propose moving these iOS only plugins to the cordova-ios repo,
> and
> > > > > adding the corresponding components in JIRA (ios-statusbar,
> > > ios-keyboard)
> > > > > for issue tracking.
> > > > > With https://issues.apache.org/jira/browse/CB-5026 - plus these
> two
> > > > > plugins, that would make a total of three plugins in cordova-ios
> > > > (probably
> > > > > in a plugins subfolder)
> > > > >
> > > > > Also, would be great to add the extra meta-data (new tags?) to
> > > > plugins.xml
> > > > > to show which repo this comes from, where issues are supposed to
> go.
> > I
> > > > > believe we discussed this in the hangout.
> > > > >
> > > > >
> > > >
> > >
> >
>

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