cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Axel Nennker <ignisvul...@gmail.com>
Subject Re: Android Plugin Resource Control
Date Wed, 01 Jan 2014 20:32:40 GMT
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 <rgerbasi@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 <ignisvulpis@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" <rgerbasi@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 <ignisvulpis@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 <rgerbasi@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 <
> ignisvulpis@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" <rgerbasi@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" <
> > ignisvulpis@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" <
> > rgerbasi@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 <
> > > > > > > agrieve@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 <
> > > > > > rgerbasi@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
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message