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" <shaz...@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 <f...@adobe.com> wrote: >> On 12-01-31 1:46 PM, "Shazron" <shaz...@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. >>
