Other users would be team members that are working on the project with you via git or svn or something.
Just to confirm if you run cordova platform remove android in your example then run cordova platform add android again it applies the variable to the new android project? So the whole thing would be cordova create GlassApp cd GlassApp cordova platform add android cordova plugin add plugin_id --variable key=value cordova platform remove android cordova platform add android You see the variable applied in the new android project? If this does work like you say what would you then suggest if the user then wants to change this value? They have to remove and re-add the plugin again? it just seems like this should be in config.xml. On Wed, Jan 1, 2014 at 2:32 PM, Axel Nennker <ignisvul...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
