cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gerbasi <rgerb...@gmail.com>
Subject Re: Android Plugin Resource Control
Date Wed, 01 Jan 2014 18:04:10 GMT
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