That would work great if there was a way to set the property I need at runtime. Currently there does not seem to be a way to set the app launch voice trigger string at runtime. Probably because Glass needs this trigger before your application even launches. This trigger will show up in a menu inside glass so it must be parsing my application to find this.
This is why I need that variable set at build time, because there does not seem to be a way, via code, to set this property. I am not sure if you can see this link without being a glass explorer but here it goes anyway https://developers.google.com/glass/develop/gdk/input/voice On Wed, Jan 1, 2014 at 11:18 AM, Axel Nennker <ignisvul...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
