cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Plugman support for Android libraries
Date Mon, 12 May 2014 14:35:04 GMT
Adding library support would be a definite win.

"android update project" is what we use in our create / update script right
now, and it has the side-effect of creating duplicate library entries each
time you update your project. Writing logic to manually edit the
project.properties file would be better I think.


On Mon, May 12, 2014 at 2:55 AM, Martin Bektchiev <
Martin.Bektchiev@telerik.com> wrote:

> Hi guys,
>
> I want to ask you for ideas about how would it be best to solve an issue
> that I'm facing. Sometimes a plugin's implementation depends on a native
> library, but there's no easy way to embed it as a .jar file in Android if
> the library has resources. Let's take
> https://github.com/phonegap/phonegap-facebook-plugin and
> https://github.com/wildabeast/BarcodeScanner for example. The former one
> can't be automatically installed and requires manually adding the
> FacebookSDK library. While the latter one relies on a gross hack which
> copies the resource files to the Cordova application project and then
> dynamically finds their IDs instead of using the R.* class. This is far
> from optimal because it makes updating the underlying library a lot more
> difficult, adds a lot of overhead in the plugin.xml file, adds performance
> overhead at runtime for retrieving the IDs and most importantly doesn't
> always work (e.g. the plugin installation will fail if the app itself
> contains a res/values/colors.xml file).
>
> Instead of these approaches it would be much better if plugman was capable
> of adding library references itself. How do you think that this should be
> implemented? Is it a good idea to use the framework tag? Should the
> implementation depend on calling "android update project" or would it be
> better to directly edit the project.properties file?
>
> Any ideas and suggestions will be more than welcome! Looking forward to
> your thoughts!
>
> Best regards,
> Martin Bektchiev
>

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