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