For Android plugin developers if they want to keep their source hidden they
could provide only the class that extends from CordovaPlugin in source form
and have it call their code in a provided jar file. Just trying to think of
a simple way for folks to provide for pay plugins.
Simon Mac Donald
For Android plugin developers if they want to keep their source hidden they
could provide only the class that extends from CordovaPlugin in source form
and have it call their code in a provided jar file. Just trying to think of
a simple way for folks to provide for pay plugins.
Good to
Again, thanks for the feedback guys!
The original proposal said that pre-compiled Can be an alternative (not
replacement) to distributing plugins as source-code. so I don't think the
original intent was for selling plugins.
Please, don't read too much into what I wrote. I just wanted to get
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
I agree with all that Marcel said, and I think most of the points he
outlined are well under way. So, I vote we just revisit this once those
are done and we have some time to ingest the changes, and see if we still
have a use case for this.
For the example of 2 year old plugin, it seems unlikely
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson bra...@chromium.orgwrote:
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
The original proposal said that pre-compiled Can be an alternative (not
replacement) to distributing plugins as source-code. so I don't think the
original intent was for selling plugins. Thats not to say that that isn't
useful, but my understanding is that end goal of this particular thread is
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
Hi Michael,
Thanks for raising this. We went through this exact question on BlackBerry
10 WebWorks SDK last year and eventually made the decision to pre-compile
plugins.
- For each platform, how feasible is this?
BlackBerry 10 is unique in its nature of plugins, as in the Framework
(non-plugin
Feasibility
---
For iOS, plugins can be static libraries, that is no problem. You cannot
use dynamic libraries in iOS (the .frameworks you see used are essentially
static libs in a different packaging). Assets should be .bundle packages
(essentially folders with the .bundle suffix). So
On Fri, Feb 22, 2013 at 2:02 PM, Shazron shaz...@gmail.com wrote:
Feasibility
---
For iOS, plugins can be static libraries, that is no problem. You cannot
use dynamic libraries in iOS (the .frameworks you see used are essentially
static libs in a different packaging). Assets
I think compiled distribution should be an option, that we support.
In WP7+8 one of the new project options includes all Cordova native code in
a compiled dll.
The dll is duplicated for each project ( not truly a shared dynamic library
), but it does allows for a simplified user project structure.
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
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
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
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.
16 matches
Mail list logo
