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
name="my_val">{$PRODUCT_NAME}</string></config-file>
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 <rgerb...@gmail.com> 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
>
