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 <[email protected]>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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > > 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 > > >
