I don't understand the "other users"-part. Not sure about the "mess" part. I looked at the plugman code and it looks ok. The plugin in <project_root>/plugins/glass_root has the modified resource files with "OK Glass" or whatever. It should not matter whether you add the plugin before or after the platform. Cordova takes the files from <project_root>/plugins and applies them to the platform files.
My project layout is as this: <project_root> - src/plugins/glass_root - src/www This (src) is all that is in my source code repository. Now I have an ant script that creates the project, adds the platform and the plugins. cordova create GlassApp # and move src/www to www cordova platform add Android cordova plugin add plugin_id --variable key=value Afterwards the <project_root> looks like this (in addtion to the src dirctory) - www - plugins/plugin_id/res/values/glass.xml - platforms/android/... Now you can build the app and run it (for one "OK Glass" phrase). If you need a second/third phrase you need to uninstall the plugin and reinstall it with the new phrase. Did you mean this with "other users"? 2014/1/1 Ross Gerbasi <rgerb...@gmail.com> > Variable was a mess. You can add a variable when you add a plugin so if you > worked this way all was ok > > -- create cordova project > -- add android platform > -- add plugin with variable > > but if you do it on a different order like > > -- create cordova project > -- add plugin with variable > -- add android platform > > Essentially if you removed your android project and re-add it after you > have the plugin, everything goes to hell. > > It doesn't work properly. It also isn't a good solution in the long run as > we are hoping in the future to ignore plugins and platforms from version > control. If that happens we would then have a plugin manifest that would > install plugins for other users. We would then have to store any variables > in this manifest so other users can get an "exact" copy, just seems like a > whole bunch of headaches. Ideally this needs to be a config variable. > > hope this all makes sense :/ > > > On Wed, Jan 1, 2014 at 11:52 AM, Axel Nennker <ignisvul...@gmail.com> > wrote: > > > Didn't you solve this with --variable? > > I never used --variable myself. > > -Axel > > Am 01.01.2014 18:24 schrieb "Ross Gerbasi" <rgerb...@gmail.com>: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
