incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 22:47:09 GMT
I would also vote for leaning more towards the config.xml for whitelisting. 

I know I didn't even know about plugins.xml and its purpose until I had been working on android
for a week or so. I may have been biased by coming from BlackBerry first and expecting it
to use my values from the config.xml
Sent on the TELUS Mobility network with BlackBerry

-----Original Message-----
From: Filip Maj <>
Date: Tue, 31 Jan 2012 13:54:16 
Subject: Re: Consistent implementation of the whitelist

On 12-01-31 1:46 PM, "Shazron" <> wrote:

>>* for most platforms, config.xml does not map to a single file. On
>>for example, AndroidManifest.xml, strings.xml and phonegap.xml are all
>Not sure what you mean about Android - the three .xml files are
>compiled into a config.xml?

Other way around. A config.xml file would, at build-time, be parsed and
compiled into however many native documents a platform needs. In Android's
case, a AndroidManifest.xml, strings.xml, etc. iOS would do the same but
compile into the app .plist file and whatever other files iOS use. If you
want specifics, take a look at Andrew's confetti project and what it does
to parse config.xml into app.plist or whatever.

>Where would plugins.xml fit in with config.xml?

Plugins.xml creates a simple name to native class mapping for the various
cordova APIs. Specifying an API in plugins.xml makes it available to the
app. The native-webview bridge method (exec) calls the label/name
associated to the class it wants to access.

To replace plugins.xml with a config.xml,we can use the <feature> element.
It's a direct one-to-one mapping. Vanilla BlackBerry WebWorks apps already
use this approach to define which blackberry WebWorks JS APIs you want
access to in the application.

View raw message