cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Android Plugin Resource Control
Date Tue, 31 Dec 2013 18:34:20 GMT
Tough call on this one. I'm a bit wary of letting plugins install hooks,
because that power could be abused.

Maybe we could allow variables to be used by plugin.xml. E.g.:
   <config-file target="res/values/strings" parent="/*"><string
and in config.xml:
   <preference name="PRODUCT_NAME" value="foo" />

That said, I don't think it's that bad to tell users to edit their
strings.xml file.

On Tue, Dec 31, 2013 at 11:50 AM, Ross Gerbasi <> wrote:

> Hello all,
> I am trying to work through the best solution to this problem figured it
> was smart to bring it up to everyone here. Maybe there is a way to handle
> this but I haven't come across it.
> This problem came up in my Google Glass plugin but I am sure other plugins
> will need to handle this also.
> In the strings.xml resource we need to set a "voice trigger" element which
> is used to start the app when you talk to glass. There doesn't seem to be
> any way to do this with code and this string would be different for ever
> app out there. On top of that each voice trigger can optionally have
> prompts that follow it, to get more user input. Currently I just inform the
> user via documentation to go edit this xml file after they install the
> plugin.
> This is not good though because once they do that it is unhooked from the
> plugin add/remove workflow. if they remove the plugin those xml elements
> stay, and then if they add the plugin back everything starts to become a
> mess.
> Essentially I need a way to write to a xml resources before a user does a
> build. I also need to be able to access a config file, probably config.xml,
> in order to get the information to write to this resource.
> I am thinking maybe we allow plugins to have hooks also? So each plugin
> could have a hooks folder, which would then allow every plugin to run
> before build commands. I could then open that resource, grab the element
> and write the value in there before every build.
> Plugins do offer the ability to get variables during add with the
> --variable flag, but i found this to be a huge mess. Especially when
> dealing with plugins that have dependent plugins that need variables. It
> also is a problem if you install the plugin then add platform after it was
> looking for variables at the wrong time. Anyway this ended up being no good
> for me.
> I am all for any suggestions, and I can dive into the CLI code and try to
> hack together something to get it working but I would love to get some
> direction. Any ideas?
> -ross

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