incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Consistent implementation of the whitelist
Date Tue, 31 Jan 2012 22:14:50 GMT
Sounds good.

I would aim for 1.6 as well. On that topic, we should start a thread about
1.5 targets :)

On 12-01-31 2:10 PM, "Shazron" <shazron@gmail.com> wrote:

>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
>confetti)
>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 <fil@adobe.com> wrote:
>> On 12-01-31 1:46 PM, "Shazron" <shazron@gmail.com> wrote:
>>
>>>>* for most platforms, config.xml does not map to a single file. On
>>>>Android,
>>>>for example, AndroidManifest.xml, strings.xml and phonegap.xml are all
>>>>involved;
>>>
>>>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.
>>


Mime
View raw message