>
> 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 t
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
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
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
a
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson wrote:
> 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, si
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
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 usi
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
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
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
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
>
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 sh
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.
On Fri, Feb 22, 2013 at 2:02 PM, Shazron 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 should be .bundle
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
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-plugi
Hi all,
I'd like to pick your brain around the feasibility of plugins existing as
static or dynamic libraries.
I had this idea a few years ago, when we first started discussing plugins.
At the time, it was
possible on BlackBerry and, with some work, possible on Android and iOS.
However, a lot
has
17 matches
Mail list logo