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 13:51:33 GMT
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
> > >>
> >
> >
>

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