incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 22:10:05 GMT
Thanks Fil.

I think this is what I would plan for iOS:

1. Convert PhoneGap.plist settings into config.xml settings
(whitelist, plugins, other features)
2. Change Objective-C code to read from config.xml
3. Add config.xml to the Xcode template
4. Add post-build phase to the Xcode template to read config.xml
settings and write them into the Info.plist (possibly using Andrew's
4. Write upgrade steps for PhoneGap.plist --> config.xml in the
Upgrade Guide doc

Would we target this1.5 or later? We don't have to do it all at the
same time. I would propose it to be in 1.6 for all platform support,
so 1.5 we can have interim support in some platforms. I haven't
consulted the backlog of tasks for the product roadmap

On Tue, Jan 31, 2012 at 1:54 PM, Filip Maj <> wrote:
> 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