cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexis Kofman <alexis.kof...@gmail.com>
Subject Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests
Date Tue, 22 Mar 2016 14:11:22 GMT
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