Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-YztPsenUefMqCiZWWdykS3FUZhnecw-Z9wsgv_ZmNiGw@mail.gmail.com>
References: 
 <CAOBL_k78kLKsvoZx_tJnbsQmHNf59tj9zeE0aaXRiXfweFr5LQ@mail.gmail.com>
	<BL2PR03MB116CAC7CCEDC87770004BF0D68F0@BL2PR03MB116.namprd03.prod.outlook.com>
	<CAG5ZNwUPDVVs+ZuiQaederDTK84zp3j-742HD+9bf38Cghs8Ww@mail.gmail.com>
	<CAEwLf1rS-Cq-stHGb92+mnsC3dkxMfQdeCo6ZZ_V1yc+CAHbKg@mail.gmail.com>
	<CY1PR03MB231358E34990A69024205319B08F0@CY1PR03MB2313.namprd03.prod.outlook.com>
	<CAM1AYQDTWFj-r3bfxREfAyExC3dRCWQvAbGCW2v5GtujsRqc-g@mail.gmail.com>
	<CAE6O_-YztPsenUefMqCiZWWdykS3FUZhnecw-Z9wsgv_ZmNiGw@mail.gmail.com>
Date: Mon, 21 Mar 2016 20:28:38 -1000
Message-ID: 
 <CAKP6k2tsCUKSZ9=uyHoOiK_REhkVGfCnZyUv4B3nTe_qXQaqGw@mail.gmail.com>
Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml
 feature requests
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e015365f0dcbc91052e9d52c2

--089e015365f0dcbc91052e9d52c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like having the same xml fragments in config.xml as we use in plugin.xml

<platform name=3D"android">
    <config-file target=3D"AndroidManifest.xml"
parent=3D"/manifest/application">
        <activity android:name=3D"com.foo.Foo"
android:label=3D"@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://issues.apache.org/jira/browse/CB-9264
> 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-1089=
4
>> talks about adding a preference for screen sizes.
>>
>> The default AndroidManifest.xml that is created with Cordova Android wil=
l
>> add the line:
>>
>>    <supports-screens android:anyDensity=3D"true"
android:largeScreens=3D"true"
>> android:normalScreens=3D"true" android:resizeable=3D"true"
>> android:smallScreens=3D"true" android:xlargeScreens=3D"true" />
>>
>> and if you want to make smallScreens=3D"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
>> http://hi.im/simonmacdonald
>>
>> 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 separate=
d
>>> 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
>>> =C3=A9crit :
>>>
>>>> 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=3Dhttps%3a%2f%2fiss=
ue
>>>> s.apache.org%2fjira%2fbrowse%2fCB-10894&data=3D01%7c01%7cpanarasi%40mi=
cr
>>>> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
>>>> cd011db47%7c1&sdata=3Df3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5=
OA
>>>> y9RMA%3d
>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fiss=
ue
>>>> s.apache.org%2fjira%2fbrowse%2fCB-10917&data=3D01%7c01%7cpanarasi%40mi=
cr
>>>> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
>>>> cd011db47%7c1&sdata=3DI1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%=
3d
>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fiss=
ue
>>>> s.apache.org%2fjira%2fbrowse%2fCB-8159&data=3D01%7c01%7cpanarasi%40mic=
ro
>>>> soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
>>>> d011db47%7c1&sdata=3DHS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3=
d
>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fiss=
ue
>>>> s.apache.org%2fjira%2fbrowse%2fCB-10755&data=3D01%7c01%7cpanarasi%40mi=
cr
>>>> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
>>>> cd011db47%7c1&sdata=3DPeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
>>>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fiss=
ue
>>>> s.apache.org%2fjira%2fbrowse%2fCB-8976&data=3D01%7c01%7cpanarasi%40mic=
ro
>>>> soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
>>>> d011db47%7c1&sdata=3D4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%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
>

--089e015365f0dcbc91052e9d52c2--