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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
