Ever since PhoneGap 2.0, we have been trying to migrate to the W3C Widget Specification so that Apache Cordova’s configuration would be more in line with the configuration found in PhoneGap Build, just to provide one example. The new format that we will be migrating to for PhoneGap 3.0 may be a surprise, but it’s relatively easy to migrate to the new format.
widget vs cordova:
Since we are adopting the widget specification, the document must be a widget document, as specified as this header:
<widget xmlns = "http://www.w3.org/ns/widgets"
id = "io.cordova.helloCordova"
version = "2.0.0">
There are other tags such as description, and author that are mostly ignored by the current Android implementation. The first relevant tag is the access tags for whitelisting:
Currently, we only whitelist http and https sites, and we do not support specifying a port in the whitelist. The whitelist looks like this:
<access origin="apache.org" subdomains="true">
The start page is specified in this document, Cordova Android and iOS supports both local and remote documents:
<content src="index.html" />
<content src="http://mysite.com/index.html" />
The preferences may or may not be platform-specific, and consist of name/value pairs. More information can be found in our Cordova Documentation:
<preference name="loglevel" value="DEBUG" />
Instead of specifying a plugin, we now specify features and the platforms that they are associated with, for example:
<param name="android-package" value="org.apache.cordova.Echo"/>
<param name="ios-package" value="CDVEcho"/>
In the above example, we are migrating the Echo plugin over to Android and iOS. The feature is called Echo across all platforms, so this is the feature name. If you have a plugin that has a different name across platforms, each of them will need their own feature tags. The following child tags indicate where each type of package could be found. On Android, Cordova Plugins are Java classes, so the full class name, including the namespace belongs in the value. On iOS, Cordova Plugins are Objective-C classes, so you would only use the class name as the value.
There are additional features in the config.xml, but this should cover the basic ones that you will need when migrating from the old format. More information can be found in our documentation.