(This is a guest post by Iva Koevska, a technical writer on the
When you develop hybrid mobile applications with Apache Cordova, at some point in time, you will need to use a device capability that the core Apache Cordova APIs just don't support. That's when you'll either dig through GitHub in search of a custom
Whether you're using
To satisfy the almighty
plugin.xml file.The plugin.xml file defines the entire plugin, including its structure, changes to the configuration files, dependencies, and so on. plugin.xml and applies the corresponding changes to the structure and the configuration files of the application package. With a proper plugin.xml file, you do not need to go and add code Info.plistAndroidManifest.xmlconfig.xml manually. Also, if you declare the plugin JavaScript file in <js-module> element, you do not need to reference the plugin script file in the index.html file for your app.
You can find the complete plugin.xml specification here. In a glimpse, it breaks down to the following steps.
<plugin> element with a plugin namespace, version, and identifier.<asset> or <js-module> element.<asset> element, you declare one or more files or folders of any type that need to be copied to the application file structure. These files and folders contain the plugin functionality and you need to explicitly reference them from the application code.<js-module> element, you declare one or more JavaScript files in the CommonJS module format. These files contain the plugin functionality and you do not need to reference them from the application code. You do not need to make any references because Apache Cordova handles any <script> includes for you.<platform> element.
<config-file> element. Set the path and the parent XML element for the changes.
config.xml to map it to the native APIs.<plugin> element.<feature> element.AndroidManifest.xmlAndroidManifest.xml manually.Info.plistInfo.plist manually.<source-file><resource-file><header-file> elements.A more thorough overview of the process, including sample code, is available here.
You can also use the following templates as a starting point. Just replace the placeholders with the correct values for your plugin and comment out or delete any unnecessary elements. Most of the time, the changes you will need to make to these templates will be trivial.
| Targeting iOS and Android | Targeting Android | Targeting iOS | |
|---|---|---|---|
| Targeting Apache Cordova 2.x | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. |
| Targeting Apache Cordova 3.x | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. | A plugin.xml template using the <asset> element.A plugin.xml template using the <js-module> element. |
Sometimes, plugin.xml might require additional work though. For example, this is the case with the BarcodeScanner plugin which contains multiple source files and depends on some native iOS frameworks. Here's how you can check out the implementation of the BarcodeScanner plugin and its valid plugin.xml file in
Or, you can enable any of the integrated plugins in an plugin.xml files for reference.
This one is more of a recommendation and less of a requirement. The rules are pretty simple.
plugin.xml goes in the root of the plugin.www folder in the root of the plugin.src src\android and iOS files - src\iospackage declaration in the JAVA file for the plugin.)You can find the complete guide for the changes you need to make to the directory structure along with some examples here. After you make all the necessary changes, your folder structure should look like this.
When using a custom plugin,
If after you cover the requirements of
Iva Koevska is the technical writer on the