I'm working on our prototype for automatic installation of Javascript from
plugins in cordova-cli. We already have installation for native code and
non-JS www assets. I don't see anything to be gained from precompiled
libraries, since a user of Cordova already has the device SDK in place and
is using either our scripts (cordova build, bin/emulate, etc.) or
Eclipse/Xcode/etc. to build the deployable application.
Switching to libraries loses us transparency for bugfixes ("make this
change in some/plugin/File.java and see if that fixes your bug") and error
messages, and it's not like we've got closed-source products we want to
make sure people can't read.
Braden
On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald <simon.macdon...@gmail.com
> wrote:
> The other issue with jars on Android is they will be unable to refer to
> anything in the res folder. That's basically why Android library projects
> exist as conventional jars just don't cut it. Luckily since most Cordova
> plugins will do their UI in HTML the likelihood of the plugin needing to
> access the res folder is very low.
>
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Fri, Feb 22, 2013 at 7:33 PM, Michael Brooks <mich...@michaelbrooks.ca
> >wrote:
>
> > Sweet, thanks for the Android input Joe!
> >
> > It's awesome to see such detailed responses for Android, BlackBerry, iOS,
> > and Windows!
> >
> > I suppose we can proceed as Marcel suggestion? Create JIRA issue, link to
> > this thread, but keep our vision forward by finishing source-code
> > distributed plugins.
> >
> > Michael
> >
> > On Fri, Feb 22, 2013 at 4:23 PM, Joe Bowser <bows...@gmail.com> wrote:
> >
> > > Hey
> > >
> > > I'm definitely a fan of pre-compiled libraries for plugins. The main
> > > reason I like JARs instead of Java files is because of the following:
> > >
> > > * Cleaner projects
> > > * Installation is extremely easy for non-Activity plugins (drop in the
> > > libs directory)
> > >
> > > The downsides on Android:
> > >
> > > * You can't verify a JAR - Have to trust that the JAR isn't sketchy,
> > > signatures can mitigate this, but not eliminate it
> > > * JARs can't transport assets, assets would have to be transported
> > > separately
> > >
> > > Overall, if you sign the JARs and allow for a mechanism for our users
> > > to check the signature of the JAR, I'm cool with this approach. We
> > > should remember that our users aren't the type of people who will
> > > check a Java file to make sure the plugin does what it says it does,
> > > and it would be nice to be able to have a tool to give them some
> > > assurance that the plugin does only what they think it does.
> > >
> > > Joe
> > >
> > >
> > > On Fri, Feb 22, 2013 at 1:30 PM, Michael Brooks
> > > <mich...@michaelbrooks.ca> wrote:
> > > > Great responses everyone. We've now got a decent overall of the iOS
> and
> > > WP
> > > > landscape, not to mention use-cases of other projects such Google
> Maps.
> > > >
> > > > tl;dr: IMHO, those three things listed above is where we should put
> our
> > > >> effort to make plugins easier, then see where that gets us. I think
> it
> > > will
> > > >> drive us the furthest forward. Then go back an reevaluate whether or
> > > not to
> > > >> provide precompiled libs to see if it truly makes life easier for
> the
> > > user,
> > > >> or if it complicates life for the user.
> > > >
> > > >
> > > > Marcel, this is the feedback that I was hoping to see! Thanks a bunch
> > for
> > > > the analysis.
> > > >
> > > > The project is always driven by what gives ours users the most value.
> > So,
> > > > it makes sense to not lose sight of our goal - offering plugins to
> > users.
> > > > If the first phase is source-code only, then so be it.
> > > >
> > > > The intention of packaging plugins as libraries is entirely around
> > making
> > > > the users' life less painful. I was reminded of this problem last
> > night,
> > > > when I had to compile a 2 year old OS X library because the developer
> > did
> > > > not publish the .framework. Unsurprisingly, it failed to build
> because
> > > > Xcode no longer bundles the necessary libraries. Similarly, if I
> needed
> > > to
> > > > a use a JPG or MP3 library, I would not want to include the source
> code
> > > in
> > > > my project simply because it takes too long to compile (assume it
> does
> > > > compile).
> > > >
> > > > Michael
> > > >
> > > > On Fri, Feb 22, 2013 at 12:38 PM, Marcel Kinard <cmarc...@gmail.com>
> > > wrote:
> > > >
> > > >> So if I back up for a moment and look at the bigger picture, it
> looks
> > > like
> > > >> what you are going for is to make it easier for Cordova users to
> pick
> > up
> > > >> plugins, either base ones or third-party ones. There are many ways
> to
> > do
> > > >> that, providing precompiled code is one way.
> > > >>
> > > >> If I were to step into the shoes of a relatively new Cordova user
> who
> > > >> wanted to pick up a plugin for my app, I don't think the compilation
> > is
> > > >> difficult enough to warrant some workaround such as providing
> > > libraries. My
> > > >> [admitedly, limited] understanding is that as a Cordova user I
> always
> > > need
> > > >> to use the device SDK to build my app. Therefore the compiler is
> right
> > > >> there and it's not difficult to invoke (i.e., iOS always needs
> > > compilation).
> > > >>
> > > >> While still in the shoes of that Cordova user, what appears to be
> more
> > > >> challenging in that role is figuring out what files are needed,
> where
> > to
> > > >> put them, and what to edit (i.e., config.xml). Basically, getting
> the
> > > >> environment and content setup for the SDK to run against. After
> that,
> > > >> running the SDK/compiler is easy. So for this difficulty, the kinds
> of
> > > >> helps could include:
> > > >> - docs: overall on how to install/remove plugins, and
> plugin-specific
> > > docs
> > > >> on their specific requirements/quirks
> > > >> - tooling: a CLI (i.e., plugman) that could make it as easy as npm
> > > >> - verification: help me as a user understand if the plugin is in
> there
> > > >> correctly, (i.e., smoke test or something like 'rpm -V')
> > > >>
> > > >> tl;dr: IMHO, those three things listed above is where we should put
> > our
> > > >> effort to make plugins easier, then see where that gets us. I think
> it
> > > will
> > > >> drive us the furthest forward. Then go back an reevaluate whether or
> > > not to
> > > >> provide precompiled libs to see if it truly makes life easier for
> the
> > > user,
> > > >> or if it complicates life for the user.
> > > >>
> > > >> The library idea is neat, it ought be captured in Jira while these
> > other
> > > >> things are worked on first.
> > > >>
> > > >> -- Marcel Kinard
> > >
> >
>
