I am not sure why you need to modify my_val at build time. Could you please change your example so that you really need this at build time?
If you want a "product name displayed in your glass app then you could use the <preference like in your example and fetch the value from the activity's extras. All preferences from config.xml are passed in into your activity as extras. Just use getStringExtra("PRODUCT_NAME") to get it and use the value "foo" in your activity/plugin. With this you do not need the "variable" at build time because you get it at run time. -Axel You get the extras in onNewIntent and in initialize. @Override public void onNewIntent(Intent intent) { Log.d(TAG, "NewIntent " + getIntent()); Bundle extras = intent.getExtras(); if (extras != null && extras.size() > 0) { for (String key : extras.keySet()) { Log.d(TAG, "KEY=" + key); } } else { Log.d(TAG, "onNewIntent intent does NOT have extras"); } ...... } public void initialize(CordovaInterface cordova, CordovaWebView webView) { Bundle extras = cordova.getIntent().getExtras(); } 2014/1/1 Ross Gerbasi <rgerb...@gmail.com> > Alrighty I can get on board with the separate xml file but I was not > concerned about the android build system parsing the res file I am worried > about cordova setting the res file prior to building. What would be the > user workflow for this? Ideally it needs to be something like > > - run add plugin > - add preference to config.xml > - run build android project > - CLI, prior to executing build, modifies RES file with preference set in > config.xml > - android project is built > > In order to do this we need some way of hooking into the build process from > a plugin. > > I like Andrews idea of allowing a config file to load a variable we would > also need a way to make this happen at build time possible via a 'build' > flag? We could then check that resource, see if there is a matching > element, if not add it. Something like this. > > plugin.xml > <config-file target="res/values/strings.xml" parent="/*" build="true"> > <string name="my_val">{$PRODUCT_NAME}</string> > </config-file> > > config.xml: > <preference name="PRODUCT_NAME" value="foo" /> > > Then you can combine this with Axels suggestion and just change the target > of the config-file to glass.xml and add it as a resource at plugin add. > > > > On Wed, Jan 1, 2014 at 1:37 AM, Axel Nennker <ignisvul...@gmail.com> > wrote: > > > Every res file is parsed by the Android build system at apk build time. > > It is a good practice to group e.g. related string resources in separate > > files instead of munching everything into strings.xml. It doesn't matter > > whether this is a non-cordova Android project or a cordova plugin. > > > > Axel > > Am 31.12.2013 22:42 schrieb "Ross Gerbasi" <rgerb...@gmail.com>: > > > > > When would this happen though? Resources seem to be applied when you > add > > a > > > plugin or when you add a platform and a plugin already exists. We need > to > > > allow the user a chance to edit this file. Would this resource be > copied > > > every build? > > > > > > The other issue I have with this is strings.xml is pretty standard for > > any > > > text in your android application, it seems a bit odd to move this > > > elsewhere. > > > > > > -ross > > > > > > > > > On Tue, Dec 31, 2013 at 2:31 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > That's clean > > > > On Dec 31, 2013 12:09 PM, "Axel Nennker" <ignisvul...@gmail.com> > > wrote: > > > > > > > > > I suggest to introduce e.g. <resource-file src="glass.xml" > > > > > target="/res/xml/glass.xml/> for Android and other platforms that > > need > > > > it. > > > > > One platform already has it. Can't remember which. > > > > > Plugman would then add/remove that file. > > > > > > > > > > Axel > > > > > Am 31.12.2013 19:57 schrieb "Ross Gerbasi" <rgerb...@gmail.com>: > > > > > > > > > > > Thats not a bad idea, would we then inform the user to edit the > > > > > plugin.xml > > > > > > after they add it? Remember we need user to be able to customize > > > > > > PRODUCT_NAME somehow. > > > > > > > > > > > > And editing strings.xml isn't horrible it just breaks abstraction > > of > > > a > > > > > > plugin. So if you edit it, then remove it it wont remove the > > entries > > > > you > > > > > > have modified. So when you add it again you have 2 and that > throws > > an > > > > > > android compile error. > > > > > > > > > > > > The other issue is with a team working together. If we do not > want > > > > people > > > > > > checking plugins & platforms into source control then other team > > > > members > > > > > > need to add all the plugins themselves and they would then need > to > > > > modify > > > > > > the xml file in the same way. Not major but again just these > little > > > > > > branches that pop up. Would be cool if we could tighten it up > with > > > some > > > > > > solution. > > > > > > > > > > > > > > > > > > On Tue, Dec 31, 2013 at 12:34 PM, Andrew Grieve < > > > agri...@chromium.org > > > > > > >wrote: > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >