cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From julio cesar sanchez <jcesarmob...@gmail.com>
Subject Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests
Date Tue, 22 Mar 2016 14:55:15 GMT
Yes, Simon, that's my opinion, and we should show the conficting values and
the id of the plugin with the conficting values so the user knows he has to
change the values on the config.xml or remove the plugin.

But we still will have problems if the plugin uses a hook to write values
instead of using the config-file tag

2016-03-22 15:11 GMT+01:00 Alexis Kofman <alexis.kofman@gmail.com>:

> Maybe the configured values of the plugins are sometimes just default
> values that the user can override through the config.xml file.
> What about adding a flag indicating whether the value is overridable ? My 2
> cents ...
>
> On Tue, Mar 22, 2016 at 3:02 PM, Simon MacDonald <
> simon.macdonald@gmail.com>
> wrote:
>
> > So for Android's case you are thinking the order of precedence should be:
> >
> > config.xml
> > plugin.xml
> > AndroidManifest.xml // created by the "cordova" cli
> >
> > Then if config.xml overrides something that one of the plugins depends on
> > then the app won't build. I can actually get behind that proposal if I'm
> > understanding you correctly.
> >
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> > On Tue, Mar 22, 2016 at 9:51 AM, julio cesar sanchez <
> > jcesarmobile@gmail.com
> > > wrote:
> >
> > > I think, if there is a conflict between config.xml and plugin.xml we
> > should
> > > not build.
> > >
> > > If we pick config.xml values, the plugins with conflicting values might
> > not
> > > work, and if we pick the plugin.xml values, the app might not work the
> > way
> > > the user wants.
> > >
> > > I think both options are bad, the user wants the plugin to work and to
> > get
> > > the values he manually added and both aren't possible if there are
> > > conflicts.
> > >
> > >
> > > 2016-03-22 13:28 GMT+01:00 Simon MacDonald <simon.macdonald@gmail.com
> >:
> > >
> > > > When it comes to the AndroidManifest if config.xml and plugin.xml
> > > (possibly
> > > > multiple plugin.xml's) disagree on the value of an attribute:
> > > >
> > > > - if the value is a boolean then it should default to 'false'. For
> > > instance
> > > > if it is an attribute like supports small screens if one plugin sets
> it
> > > to
> > > > false it should be false for or else the app may not build.
> > > > - if the value is a integer then it should default to the highest
> > integer
> > > > provided. For instance minimum SDK version, again have to pick the
> > > highest
> > > > or the app won't build.
> > > > - if the value is a string, damned if I know if there are conflicts
> in
> > > > multiple plugin.xml files but plugin.xml should take precedence over
> > > > config.xml.
> > > >
> > > > Sound reasonable?
> > > >
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > > >
> > > > On Tue, Mar 22, 2016 at 3:27 AM, Parashuram N <
> panarasi@microsoft.com>
> > > > wrote:
> > > >
> > > > > The disagreement could also like in a “preference” specifying
a
> > value,
> > > > > that is overwritten by this fragment.
> > > > >
> > > > > On 3/21/16, 11:28 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> > > > >
> > > > > >I like having the same xml fragments in config.xml as we use
in
> > > > plugin.xml
> > > > > >
> > > > > ><platform name="android">
> > > > > >    <config-file target="AndroidManifest.xml"
> > > > > >parent="/manifest/application">
> > > > > >        <activity android:name="
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > "
> > > > > >android:label="@string/app_name">
> > > > > >            <intent-filter>
> > > > > >            </intent-filter>
> > > > > >        </activity>
> > > > > >    </config-file>
> > > > > ></platform>
> > > > > >
> > > > > >We will need to address precedence, as a plugin.xml and config.xml
> > can
> > > > > >disagree.
> > > > > >
> > > > > >
> > > > > >
> > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron <shazron@gmail.com>
> wrote:
> > > > > >>
> > > > > >> Continuing on Simon's point, we already have duplication
of
> > entries
> > > > > >> for preference tags in
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9264&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Amj46nGpbpE3scp6sjDw1FemeGton2Hu6YSyQqZNT4M%3d
> > > > > >> and a post-processing step does the removal of dupes. Not
sure
> if
> > > this
> > > > > >> removal method would be adequate (as long as the desired
tag to
> > > > > >> express is written to the config file *last*)
> > > > > >>
> > > > > >> On Mon, Mar 21, 2016 at 3:41 PM, Simon MacDonald
> > > > > >> <simon.macdonald@gmail.com> wrote:
> > > > > >>> I agree the config-file is the way to go but we need
to go one
> > step
> > > > > more
> > > > > >>> and enable the changing of attributes in the config
file
> instead
> > of
> > > > > just
> > > > > >>> adding lines to AndroidManifest.xml. For instance, the
first
> bug
> > > > > CB-10894
> > > > > >>> talks about adding a preference for screen sizes.
> > > > > >>>
> > > > > >>> The default AndroidManifest.xml that is created with
Cordova
> > > Android
> > > > > will
> > > > > >>> add the line:
> > > > > >>>
> > > > > >>>    <supports-screens android:anyDensity="true"
> > > > > >android:largeScreens="true"
> > > > > >>> android:normalScreens="true" android:resizeable="true"
> > > > > >>> android:smallScreens="true" android:xlargeScreens="true"
/>
> > > > > >>>
> > > > > >>> and if you want to make smallScreens="false" you have
no way of
> > > doing
> > > > > it
> > > > > >as
> > > > > >>> it adds a duplicate line if you are using the config-file
way
> of
> > > > doing
> > > > > >>> things. We really need attribute level granularity in
the
> > > config-file
> > > > > >tag.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> Simon Mac Donald
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%2fsimonmacdonald&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
> > > > > >>>
> > > > > >>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll <
> > > > riknoll@microsoft.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> I agree that config-file is the way to go. After
an offline
> > > > discussion
> > > > > >>>> with Nikhil, Parashu, and Jason, one question that
came up was
> > > > whether
> > > > > >all
> > > > > >>>> of this native config stuff belongs in config.xml
or should be
> > > > > separated
> > > > > >>>> out. One idea would be to define separate files
for each
> > > > configuration
> > > > > >file
> > > > > >>>> you wish to modify (something like AndroidManifest.merge.xml).
> > > Those
> > > > > >files
> > > > > >>>> would follow the same format as the config-file
tag and you
> > could
> > > > add
> > > > > >>>> entries to build.json or config.xml specifying what
native
> > config
> > > > each
> > > > > >file
> > > > > >>>> modifies. It breaks from how we do it in plugin.xml,
but it
> > > prevents
> > > > > >having
> > > > > >>>> gigantic config.xml files that are mostly composed
of native
> > > > > fragments.
> > > > > >The
> > > > > >>>> current config file mixing that we do is somewhat
messy.
> > > > > >>>> Thoughts?
> > > > > >>>>
> > > > > >>>> Richard
> > > > > >>>>
> > > > > >>>> -----Original Message-----
> > > > > >>>> From: Alexis Kofman [mailto:alexis.kofman@gmail.com]
> > > > > >>>> Sent: Monday, March 21, 2016 1:39 PM
> > > > > >>>> To: dev@cordova.apache.org
> > > > > >>>> Subject: Re: [Android] Need a solution to config.xml
and
> > > > > >>>> AndroidManifest.xml feature requests
> > > > > >>>>
> > > > > >>>> Hello all,
> > > > > >>>>
> > > > > >>>> I agree with Julio that it is less confusing  keeping
the same
> > > > > mecanism
> > > > > >>>> that the one it already exists with the plugin.xml.
> > > > > >>>> Le 21 mars 2016 19:17, "julio cesar sanchez" <
> > > > jcesarmobile@gmail.com>
> > > > > a
> > > > > >>>> écrit :
> > > > > >>>>
> > > > > >>>>> I think we should add the config-file tag to
the config.xml.
> > > > > >>>>> It's already implemented on the plugin.xml.
It allows you to
> > > modify
> > > > > >>>>> the AndroidManifest.xml or the info.plist when
you install a
> > > > plugin.
> > > > > >>>>> But the number of plugins that just modify the
> > > AndroidManifest.xml
> > > > or
> > > > > >>>>> info.plist is increasing, I think that should
be on the
> > > config.xml
> > > > > too.
> > > > > >>>>>
> > > > > >>>>> So we don't duplicate anything with our own
tags, we just let
> > > them
> > > > > add
> > > > > >>>>> whatever they want from the config-file tag.
> > > > > >>>>> And if something can't be edited from the config-file
tag, we
> > > tell
> > > > > >>>>> them to create a hook.
> > > > > >>>>>
> > > > > >>>>> Phonegap build uses the config-file tag on the
config.xml to
> > > allow
> > > > > >>>>> their users to edit the AndroidManifest.xml
and the
> info.plist
> > > > > >>>>>
> > > > > >>>>> @Parashuram idea might work on android, but
I think we should
> > > have
> > > > > >>>>> something that can be used on all the platforms
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> 2016-03-21 18:40 GMT+01:00 Parashuram N <
> > panarasi@microsoft.com
> > > >:
> > > > > >>>>>
> > > > > >>>>>> Given that we are now using Gradle for builds,
could these
> > > simply
> > > > be
> > > > > >>>>>> gradle sub-projects that define an AndroidManifest.xml,
that
> > > gets
> > > > > >>>>>> merged during Android build ? One way could
be to support
> > > > specifying
> > > > > >>>>>> "sub-projects" in config.xml, and these
changes get picked
> up.
> > > > Would
> > > > > >>>>>> it work for all cases ?
> > > > > >>>>>>
> > > > > >>>>>> -----Original Message-----
> > > > > >>>>>> From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > >>>>>> Sent: Monday, March 21, 2016 10:07 AM
> > > > > >>>>>> To: dev <dev@cordova.apache.org>
> > > > > >>>>>> Subject: [Android] Need a solution to config.xml
and
> > > > > >>>>>> AndroidManifest.xml feature requests
> > > > > >>>>>>
> > > > > >>>>>> Hey
> > > > > >>>>>>
> > > > > >>>>>> So, if you've been paying attention to the
JIRA, we've been
> > > > getting
> > > > > >>>>>> slammed with a ton of feature requests/bugs
regarding the
> > > Android
> > > > > >>>>> Manifest
> > > > > >>>>>> where people want to add a 1:1 mapping between
the two XML
> > > files.
> > > > > >>>>>>
> > > > > >>>>>> The thing is that it's getting out of control,
and we need
> to
> > > > find a
> > > > > >>>>>> better solution to this problem.  I'm not
sure what a better
> > > > > >>>>>> solution to this is, but if you want to
see some of the
> issues
> > > > that
> > > > > >>>>>> are related to this, here's a small list:
> > > > > >>>>>
> > > > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > >>>>> s.apache.org
> > > > > %2fjira%2fbrowse%2fCB-10894&data=01%7c01%7cpanarasi%40micr
> > > > > >>>>> osoft.com
> > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > >>>>>
> > > > >
> > cd011db47%7c1&sdata=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OA
> > > > > >>>>> y9RMA%3d
> > > > > >>>>>
> > > > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > >>>>> s.apache.org
> > > > > %2fjira%2fbrowse%2fCB-10917&data=01%7c01%7cpanarasi%40micr
> > > > > >>>>> osoft.com
> > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > >>>>>
> > > > >
> > cd011db47%7c1&sdata=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> > > > > >>>>>
> > > > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > >>>>> s.apache.org
> > > > > %2fjira%2fbrowse%2fCB-8159&data=01%7c01%7cpanarasi%40micro
> > > > > >>>>> soft.com
> > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > >>>>>
> > > > d011db47%7c1&sdata=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> > > > > >>>>>
> > > > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > >>>>> s.apache.org
> > > > > %2fjira%2fbrowse%2fCB-10755&data=01%7c01%7cpanarasi%40micr
> > > > > >>>>> osoft.com
> > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > >>>>>
> > > > cd011db47%7c1&sdata=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> > > > > >>>>>
> > > > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > >>>>> s.apache.org
> > > > > %2fjira%2fbrowse%2fCB-8976&data=01%7c01%7cpanarasi%40micro
> > > > > >>>>> soft.com
> > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > >>>>>
> > d011db47%7c1&sdata=4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%3d
> > > > > >>>>>>
> > > > > >>>>>> All of these are either indirectly or directly
related to
> the
> > > > > >>>>>> AndroidManifest, and it's clear that if
we just allowed
> people
> > > to
> > > > > >>>>>> edit an AndroidManifest, or at least allow
portions of it to
> > be
> > > > > >>>>>> immutable, we
> > > > > >>>>> would
> > > > > >>>>>> be better off.  Obviously, plugins that
install third-party
> > > > > >>>>>> activities
> > > > > >>>>> and
> > > > > >>>>>> content providers would have to edit the
manifest, but I
> think
> > > > that
> > > > > >>>>> things
> > > > > >>>>>> are getting out of hand with the things
that people want to
> > > > control
> > > > > >>>>>> from config.xml.
> > > > > >>>>>>
> > > > > >>>>>> What do people think? Does anyone have a
good solution to
> this
> > > > > >problem?
> > > > > >>>>>> Are we really abstracting anything out by
duplicating the
> same
> > > > > >>>>>> config in our own config.xml?
> > > > > >>>>
> > > > > >>>>
> > > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Alexis Kofman
>

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