You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cordova.apache.org by mw...@apache.org on 2013/10/22 00:13:46 UTC
[04/14] docs commit: [CB-3825] globals; cleanup Android plugin text
[CB-3825] globals; cleanup Android plugin text
Project: http://git-wip-us.apache.org/repos/asf/cordova-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/c96e9d30
Tree: http://git-wip-us.apache.org/repos/asf/cordova-docs/tree/c96e9d30
Diff: http://git-wip-us.apache.org/repos/asf/cordova-docs/diff/c96e9d30
Branch: refs/heads/master
Commit: c96e9d305b7e86be8dae95160771ba1fa06aeb38
Parents: e63f5fb
Author: Mike Sierra <ms...@adobe.com>
Authored: Mon Oct 7 16:53:26 2013 -0400
Committer: Michael Brooks <mi...@michaelbrooks.ca>
Committed: Mon Oct 21 15:10:30 2013 -0700
----------------------------------------------------------------------
docs/en/edge/guide/platforms/android/plugin.md | 154 ++++++++++---------
.../edge/guide/platforms/blackberry10/plugin.md | 103 ++++++++++---
docs/en/edge/guide/platforms/ios/plugin.md | 41 +++--
docs/en/edge/guide/platforms/wp8/plugin.md | 17 +-
4 files changed, 204 insertions(+), 111 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/c96e9d30/docs/en/edge/guide/platforms/android/plugin.md
----------------------------------------------------------------------
diff --git a/docs/en/edge/guide/platforms/android/plugin.md b/docs/en/edge/guide/platforms/android/plugin.md
index 443fbf4..51b782e 100644
--- a/docs/en/edge/guide/platforms/android/plugin.md
+++ b/docs/en/edge/guide/platforms/android/plugin.md
@@ -23,51 +23,51 @@ The section provides details for how to implement plugin code on the
Android platform. See Application Plugins for an overview of how to
structure the plugin and implement its common JavaScript interface.
-Writing a plugin requires an understanding of the architecture of
-Cordova-Android. Cordova-Android consists of an Android WebView with
-hooks attached to it. These plugins are represented as class mappings
-in the `config.xml` file.
+Android plugins are based on Cordova-Android, which consists of an
+Android WebView with hooks attached to it. Plugins are represented as
+class mappings in the `config.xml` file.
A plugin consists of at least one Java class that extends the
`CordovaPlugin` class. A plugin must override one of the `execute`
-methods from `CordovaPlugin`. As best practice, the plugin should
-handle `pause` and `resume` events, and any message passing between
-plugins. Plugins with long-running requests, background activity such
-as media playback, listeners, or internal state should implement the
-`onReset()` method as well. It executes when the `WebView` navigates to
-a new page or refreshes, which reloads the JavaScript.
+methods from `CordovaPlugin`. As best practice, the plugin should also
+handle `pause` and `resume` events, along with any message passing
+between plugins. Plugins with long-running requests, background
+activity such as media playback, listeners, or internal state should
+implement the `onReset()` method as well. It executes when the
+`WebView` navigates to a new page or refreshes, which reloads the
+JavaScript.
## Plugin Class Mapping
-The JavaScript portion of a plugin always uses the `cordova.exec` method as follows:
+The plugin's JavaScript interface uses the `cordova.exec` method as
+follows:
exec(<successFunction>, <failFunction>, <service>, <action>, [<args>]);
This marshals a request from the WebView to the Android native side,
-more or less boiling down to calling the `action` method on the
-`service` class, with the arguments passed in the `args` Array.
+effectively calling the `action` method on the `service` class, with
+additional arguments passed in the `args` array.
-Whether you distribute your plugin as Java file or as a JAR of its
-own, the plugin must be added to the `config.xml` file in your
-Cordova-Android application's `res/xml/` directory.
+Whether you distribute a plugin as Java file or as a _jar_ file of its
+own, the plugin must be specified in your Cordova-Android
+application's `res/xml/config.xml` file. See Application Plugins for
+more information.
<feature name="<service_name>">
<param name="android-package" value="<full_name_including_namespace>" />
</feature>
-The service name should match the one used in the JavaScript `exec`
-call, and the value is the Java classes full name, including the
-namespace. Otherwise the plugin may compile but still be unreachable
-by Cordova.
+The service name matches the one used in the JavaScript `exec` call.
+The value is the Java class's fully qualified namespace identifier.
+Otherwise, the plugin may compile but still be unavailable to Cordova.
## Writing an Android Java Plugin
-JavaScript fires off a plugin request to the native side. The Android
-Java plugin is mapped properly via the `config.xml` file. So what
-does the final Android Java Plugin class look like?
-
-What gets dispatched to the plugin via JavaScript's `exec` function gets
-passed into the Plugin class's `execute` method. Most `execute`
+A JavaScript call fires off a plugin request to the native side, and
+the correspoinding Java plugin is mapped properly in the `config.xml`
+file, but what does the final Android Java Plugin class look like?
+Whatever is dispatched to the plugin with JavaScript's `exec` function
+is passed into the plugin class's `execute` method. Most `execute`
implementations look like this:
@Override
@@ -80,20 +80,19 @@ implementations look like this:
return false; // Returning false results in a "MethodNotFound" error.
}
-We compare the value of the `action` parameter, and dispatch the
-request off to a (private) method in the class, optionally passing
-some of the parameters to the method.
+The JavaScript `exec` function's `action` parameter corresponds to a
+private class method to dispatch with optional parameters.
When catching exceptions and returning errors, it's important for the
sake of clarity that errors returned to JavaScript match Java's
exception names as much as possible.
-### Threading
-
-JavaScript in the WebView does *not* run on the UI thread. It runs on
-the WebCore thread. The `execute` method also runs on the WebCore thread.
+## Threading
-If you need to interact with the UI, you should use the following:
+The plugin's JavaScript does _not_ run in the main thread of the
+WebView interface; instead, it runs on the the WebCore thread, as does
+the `execute` method. If you need to interact with the user
+interface, you should use the following variation:
@Override
public boolean execute(String action, JSONArray args, final CallbackContext callbackContext) throws JSONException {
@@ -110,7 +109,8 @@ If you need to interact with the UI, you should use the following:
return false;
}
-If you do not need to run on the UI thread, but do not want to block the WebCore thread:
+Use the following if you do not need to run on the main interface's
+thread, but do not want to block the WebCore thread either:
@Override
public boolean execute(String action, JSONArray args, final CallbackContext callbackContext) throws JSONException {
@@ -127,17 +127,22 @@ If you do not need to run on the UI thread, but do not want to block the WebCore
return false;
}
-### Echo Android Plugin Example
+## Echo Android Plugin Example
-Add the following to our `config.xml` file:
+To match the JavaScript interface's _echo_ feature described in
+Application Plugins, use the `plugin.xml` to inject a `feature`
+specification to the local platform's `config.xml` file:
- <feature name="Echo">
- <param name="android-package" value="org.apache.cordova.plugin.Echo" />
- </feature>
+ <platform name="android">
+ <config-file target="config.xml" parent="/*">
+ <feature name="Echo">
+ <param name="android-package" value="org.apache.cordova.plugin.Echo"/>
+ </feature>
+ </config-file>
+ </platform>
-Then add the following file to
-`src/org/apache/cordova/plugin/Echo.java` inside our Cordova-Android
-application:
+Then add the following to the
+`src/org/apache/cordova/plugin/Echo.java` file:
package org.apache.cordova.plugin;
@@ -172,39 +177,50 @@ application:
}
}
-Let's take a look at the code. The necessary `imports` are at
-the top. Our class extends from `CordovaPlugin`. We override the
-execute() method in order to recieve messages from exec(). Our method
-first compares against `action`: this plugin only supports one action,
-the `echo` action. Any other action returns `false`, which results in an
-error of type `INVALID_ACTION`, which translates into an error
-callback invocation on the JavaScript side. Next, we grab the echo
-string using the `getString` method on our `args`, telling it we want
-to get the 0th parameter in the parameter array. We do a bit of
-parameter checking: make sure it is not `null`, and make sure it is
-not a zero-length string. If it is, we call `callbackContext.error()`
-(which, by now, you should know invokes the error callback). If all of
-those checks pass, then we call `callbackContext.success()` and pass
-in the `message` string we received as a parameter. This finally
-translates into a success callback invocation on the JavaScript
-side. It also passes the `message` parameter as a parameter into the
-JavaScript success callback function.
-
-## Debugging Plugins
-
-Eclipse can be used to debug an Android project, and the plugins can be debugged if the Java source is included in the project. Only the latest version of the Android Developer Tools is known to allow source code attachment to JAR dependencies, so this is not fully supported at this time.
+The necessary imports at the top of the file extends the class from
+`CordovaPlugin`, whose `execute()` method it overrides to receive
+messages from `exec()`. The `execute()` method first tests the value
+of `action`, for which in this case there is only one valid `echo`
+value. Any other action returns `false` and results in an
+`INVALID_ACTION` error, which translates to an error callback invoked
+on the JavaScript side.
+
+Next, the method retrieves the echo string using the `args` object's
+`getString` method, specifying the first parameter passed to the
+method. After the value is passed to a private `echo` method, it is
+parameter-checked to make sure it is not `null` or an empty string, in
+which case `callbackContext.error()` invokes JavaScript's error
+callback. If the various checks pass, the `callbackContext.success()`
+passes the original `message` string back to JavaScript's success
+callback as a parameter.
+
+## Debugging Android Plugins
+
+You can use Eclipse to debug plugins as Java source included in the
+project. Only the latest version of the Android Developer Tools is
+known to allow source code attachment to _JAR_ dependencies, so this
+is not yet fully supported.
## Common Pitfalls
-* Plugins have access to a `CordovaInterface` object. This object has access to the Android `Activity` that is running the application. This is the `Context` required to launch
-a new Android `Intent`. The `CordovaInterface` allows plugins to start an `Activity` for a result, and to set the callback plugin for when the `Intent` comes back to the application. This is important, since the
-`Intent`s system is how Android communicates between processes.
+- Plugins have access to a `CordovaInterface` object. This object has
+ access to the Android `Activity` that is running the application.
+ This is the `Context` required to launch a new Android `Intent`. The
+ `CordovaInterface` allows plugins to start an `Activity` for a
+ result, and to set the callback plugin for when the `Intent` comes
+ back to the application. This is important, since the `Intent`s
+ system is how Android communicates between processes.
-* Plugins do not have direct access to the `Context` as they have in the past. The legacy `ctx` member is deprecated, and will be removed six months after 2.0 is released. All of `ctx` methods exist on the `Context`, so both `getContext()` and `getActivity()` are capable of returning the proper object required.
+- Plugins do not have direct access to the `Context` as they have in
+ the past. The legacy `ctx` member is deprecated, and will be removed
+ six months after 2.0 is released. All of `ctx` methods exist on the
+ `Context`, so both `getContext()` and `getActivity()` are capable of
+ returning the proper object required.
## Use the Source
One of the best ways to prepare yourself to write your own plugin is to
[look over existing plugins](https://github.com/search?q=%40apache+cordova-plugin).
-You should also read through the comments in [CordovaPlugin.java](https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaPlugin.java).
+You should also read through the comments in
+[CordovaPlugin.java](https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaPlugin.java).
http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/c96e9d30/docs/en/edge/guide/platforms/blackberry10/plugin.md
----------------------------------------------------------------------
diff --git a/docs/en/edge/guide/platforms/blackberry10/plugin.md b/docs/en/edge/guide/platforms/blackberry10/plugin.md
index bb28422..1dc2be2 100644
--- a/docs/en/edge/guide/platforms/blackberry10/plugin.md
+++ b/docs/en/edge/guide/platforms/blackberry10/plugin.md
@@ -23,7 +23,11 @@ The section provides details for how to implement plugin code on the
BlackBerry 10 platform. See Application Plugins for an overview of how to
structure the plugin and implement its common JavaScript interface.
-This is a continuation of the Plugin Development Guide for Cordova. Once you have reviewed that content, now let's look at things we need to have the Echo plugin for the BlackBerry 10 platform. Recall that the Echo plugin basically returns whatever string a user provides to the `window.echo` function:
+This is a continuation of the Plugin Development Guide for
+Cordova. Once you have reviewed that content, now let's look at things
+we need to have the Echo plugin for the BlackBerry 10 platform. Recall
+that the Echo plugin basically returns whatever string a user provides
+to the `window.echo` function:
window.echo = function(str, callback) {
cordova.exec(callback, function(err) {
@@ -31,19 +35,32 @@ This is a continuation of the Plugin Development Guide for Cordova. Once you hav
}, "Echo", "echo", [str]);
};
-A native BlackBerry 10 plugin for Cordova contains JavaScript code and may also contain native code. The Echo plugin example demonstrates how to invoke native functionality from JavaScript. The native and JavaScript code communicate with each other through a framework provided by JNEXT. Every plugin must also include a `plugin.xml` file.
+A native BlackBerry 10 plugin for Cordova contains JavaScript code and
+may also contain native code. The Echo plugin example demonstrates how
+to invoke native functionality from JavaScript. The native and
+JavaScript code communicate with each other through a framework
+provided by JNEXT. Every plugin must also include a `plugin.xml` file.
## Creating the native part of your plugin ##
-To create the native portion of your plugin, open the BlackBerry 10 NDK IDE and select File > New > BlackBerry Project > Native Extension > BlackBerry WebWorks. Enter your desired project name / location and click finish.
+To create the native portion of your plugin, open the BlackBerry 10
+NDK IDE and select File > New > BlackBerry Project > Native Extension
+> BlackBerry WebWorks. Enter your desired project name / location and
+click finish.
-The project created by the IDE contains sample code for a memory plugin. You may replace or modify these files to include your own functionality.
+The project created by the IDE contains sample code for a memory
+plugin. You may replace or modify these files to include your own
+functionality.
- `*name*_js.hpp`: C++ header for the JNEXT code.
- `*name*_js.cpp`: C++ code for JNEXT.
-The native interface for the JNEXT extension can be viewed in the plugin header file located in the public directory of your project. It also contains constants and utility functions that can be used in your native code. Your plugin must be derived from JSExt which is defined in plugin.h. That is, you must implement the following class:
+The native interface for the JNEXT extension can be viewed in the
+plugin header file located in the public directory of your project. It
+also contains constants and utility functions that can be used in your
+native code. Your plugin must be derived from JSExt which is defined
+in plugin.h. That is, you must implement the following class:
class JSExt
{
@@ -55,7 +72,8 @@ The native interface for the JNEXT extension can be viewed in the plugin header
std::string m_id;
};
-Therefore, your extension should include the plugin.h header file. In the Echo example, you use JSExt as follows in the echo_js.hpp file:
+Therefore, your extension should include the plugin.h header file. In
+the Echo example, you use JSExt as follows in the echo_js.hpp file:
#include "../public/plugin.h"
#include <string>
@@ -76,10 +94,17 @@ Therefore, your extension should include the plugin.h header file. In the Echo e
#endif // ECHO_JS_H_
-The `m_id` is an attribute that contains the JNEXT id for this object. The id is passed to the class as an argument to the constructor. It is needed to trigger events on the JavaScript side from native.
-The CanDelete method is used by JNEXT to determine whether your native object can be deleted.
-The InvokeMethod function is called as a result from a request from JavaScript to invoke a method of this particular object. The only argument to this function is a string passed from JavaScript that this method should parse in order to determine which method of the native object should be executed.
-Now we implement these functions in echo_js.cpp. For the Echo example, we implement InvokeMethod function as follows:
+The `m_id` is an attribute that contains the JNEXT id for this
+object. The id is passed to the class as an argument to the
+constructor. It is needed to trigger events on the JavaScript side
+from native. The CanDelete method is used by JNEXT to determine
+whether your native object can be deleted. The InvokeMethod function
+is called as a result from a request from JavaScript to invoke a
+method of this particular object. The only argument to this function
+is a string passed from JavaScript that this method should parse in
+order to determine which method of the native object should be
+executed. Now we implement these functions in echo_js.cpp. For the
+Echo example, we implement InvokeMethod function as follows:
string Echo::InvokeMethod(const string& command) {
@@ -96,20 +121,29 @@ Now we implement these functions in echo_js.cpp. For the Echo example, we implem
}
}
-Your native plugin must also implement the following callback functions:
+Your native plugin must also implement the following callback
+functions:
- `extern char* onGetObjList( void );`
- `extern JSExt* onCreateObject( const string& strClassName, const string& strObjId );`
-The `onGetObjList` function returns a comma separated list of classes supported by JNEXT. JNEXT uses this function to determine the set of classes that JNEXT can instantiate. In our Echo plugin, we have the following in `echo_js.cpp`:
+The `onGetObjList` function returns a comma separated list of classes
+supported by JNEXT. JNEXT uses this function to determine the set of
+classes that JNEXT can instantiate. In our Echo plugin, we have the
+following in `echo_js.cpp`:
char* onGetObjList() {
static char name[] = "Echo";
return name;
}
-The `onCreateObject ` function takes two parameters. The first parameter is the name of the class requested to be created from the JavaScript side. Valid names are those that are returned in `onGetObjList`. The second parameter is the unique object id for the class. This method returns a pointer to the created plugin object. In our Echo plugin, we have the following in `echo_js.cpp`:
+The `onCreateObject ` function takes two parameters. The first
+parameter is the name of the class requested to be created from the
+JavaScript side. Valid names are those that are returned in
+`onGetObjList`. The second parameter is the unique object id for the
+class. This method returns a pointer to the created plugin object. In
+our Echo plugin, we have the following in `echo_js.cpp`:
JSExt* onCreateObject(const string& className, const string& id) {
if (className == "Echo") {
@@ -122,11 +156,20 @@ The `onCreateObject ` function takes two parameters. The first parameter is the
The JavaScript portion of your plugin must contain the following files:
-- `client.js`: This is considered the client side and contains the API that a Cordova application can call. The API in `client.js` calls makes calls to `index.js`. The API in `client.js` also connects callback functions to the events that fire the callbacks.
+- `client.js`: This is considered the client side and contains the API
+ that a Cordova application can call. The API in `client.js` calls
+ makes calls to `index.js`. The API in `client.js` also connects
+ callback functions to the events that fire the callbacks.
-- `index.js`: Cordova loads `index.js` and makes it accessible through the cordova.exec bridge. The `client.js` file makes calls to the API in the `index.js` file, which in turn makes call to JNEXT to communicate with the native side.
+- `index.js`: Cordova loads `index.js` and makes it accessible through
+ the cordova.exec bridge. The `client.js` file makes calls to the API
+ in the `index.js` file, which in turn makes call to JNEXT to
+ communicate with the native side.
-The client and server side (`client.js` and `index.js`) interacts through the `Cordova.exec `function. So, in `client.js` you invoke the `exec` function and provide the necessary arguments. In the Echo plugin, we have the following in the `client.js` file:
+The client and server side (`client.js` and `index.js`) interacts
+through the `Cordova.exec `function. So, in `client.js` you invoke the
+`exec` function and provide the necessary arguments. In the Echo
+plugin, we have the following in the `client.js` file:
var service = "org.apache.cordova.blackberry.echo",
exec = cordova.require("cordova/exec");
@@ -137,17 +180,27 @@ The client and server side (`client.js` and `index.js`) interacts through the `C
}
};
-Now, `index.js` interacts with the native side using JNEXT. So you attach a constructor function named Echo to JNEXT. Within the constructor you perform the following key operations using the init function:
+Now, `index.js` interacts with the native side using JNEXT. So you
+attach a constructor function named Echo to JNEXT. Within the
+constructor you perform the following key operations using the init
+function:
-- Specify the required module exported by the native side. The name of the required module must match the name of a shared library file (.so file).
+- Specify the required module exported by the native side. The name of
+ the required module must match the name of a shared library file
+ (.so file).
-`JNEXT.require("libecho")`
+ JNEXT.require("libecho")
-- Create an object by using an acquired module and save the ID that's returned by the call.
-self.m_id = JNEXT.createObject("libecho.Echo");
-When your application calls the echo function in `client.js`, that call in turn calls the echo function in `index.js`, where the PluginResult object sends a response (data) back to `client.js`. Since the args argument passed into the functions was converted by JSON.stringfy() and encoded as a URIcomponent, you must call the following:
+- Create an object by using an acquired module and save the ID that's
+ returned by the call. self.m_id =
+ JNEXT.createObject("libecho.Echo"); When your application calls the
+ echo function in `client.js`, that call in turn calls the echo
+ function in `index.js`, where the PluginResult object sends a
+ response (data) back to `client.js`. Since the args argument passed
+ into the functions was converted by JSON.stringfy() and encoded as a
+ URIcomponent, you must call the following:
-`data = JSON.parse(decodeURIComponent(args.data));`
+ data = JSON.parse(decodeURIComponent(args.data));
You can now send the data back. Let’s put it all together:
@@ -167,8 +220,8 @@ You can now send the data back. Let’s put it all together:
You can place the artifacts of the plugin, which includes the
`plugin.xml` file, the source files (JavaScript, C++), and the binary
files (`.so`) within any directory structure, as long as you correctly
-specify the file locations in the `plugin.xml` file. A typical structure
-looks like this:
+specify the file locations in the `plugin.xml` file. A typical
+structure looks like this:
***your_project_directory*** (>plugin.xml)
http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/c96e9d30/docs/en/edge/guide/platforms/ios/plugin.md
----------------------------------------------------------------------
diff --git a/docs/en/edge/guide/platforms/ios/plugin.md b/docs/en/edge/guide/platforms/ios/plugin.md
index bb7a16b..021114d 100644
--- a/docs/en/edge/guide/platforms/ios/plugin.md
+++ b/docs/en/edge/guide/platforms/ios/plugin.md
@@ -75,9 +75,13 @@ the JavaScript.
## Writing an iOS Cordova Plugin
-We have JavaScript fire off a plugin request to the native side. We have the iOS Objective-C plugin mapped properly via the `config.xml` file. So what does the final iOS Objective-C Plugin class look like?
+We have JavaScript fire off a plugin request to the native side. We
+have the iOS Objective-C plugin mapped properly via the `config.xml`
+file. So what does the final iOS Objective-C Plugin class look like?
-What gets dispatched to the plugin via JavaScript's `exec` function gets passed into the corresponding Plugin class's `action` method. A plugin method has this signature:
+What gets dispatched to the plugin via JavaScript's `exec` function
+gets passed into the corresponding Plugin class's `action` method. A
+plugin method has this signature:
- (void)myMethod:(CDVInvokedUrlCommand*)command
{
@@ -100,7 +104,8 @@ What gets dispatched to the plugin via JavaScript's `exec` function gets passed
## iOS CDVPluginResult message types
-Using CDVPluginResult you can return a variety of result types back to your JavaScript callbacks, using class methods that look like:
+Using CDVPluginResult you can return a variety of result types back to
+your JavaScript callbacks, using class methods that look like:
+ (CDVPluginResult*)resultWithStatus:(CDVCommandStatus)statusOrdinal messageAs...
@@ -112,9 +117,18 @@ callback does not fire.
### Notes
- * `messageAsArrayBuffer` expects `NSData*` and converts to an `ArrayBuffer` for your JavaScript callback (and `ArrayBuffers` sent to a plugin from JavaScript are converted to `NSData*`).
- * `messageAsMultipart` expects an `NSArray*` containing any of the other supported types, and sends the whole array as the `arguments` to your JavaScript callback.
- * Quirk: this is not just syntactic sugar (though it is sweet). This way, all of the arguments are serialized or deserialized as necessary. E.g., it is safe to return `NSData*` as multipart, but not as `Array`/`Dictionary`.
+ * `messageAsArrayBuffer` expects `NSData*` and converts to an
+ `ArrayBuffer` for your JavaScript callback (and `ArrayBuffers` sent
+ to a plugin from JavaScript are converted to `NSData*`).
+
+ * `messageAsMultipart` expects an `NSArray*` containing any of the
+ other supported types, and sends the whole array as the `arguments`
+ to your JavaScript callback.
+
+ * Quirk: this is not just syntactic sugar (though it is sweet).
+ This way, all of the arguments are serialized or deserialized as
+ necessary. E.g., it is safe to return `NSData*` as multipart,
+ but not as `Array`/`Dictionary`.
## Echo Plugin iOS Plugin
@@ -124,8 +138,8 @@ We would add the following to the project's `config.xml` file:
<param name="ios-package" value="Echo" />
</feature>
-Then we would add the following files (`Echo.h` and `Echo.m`) to the Plugins directory inside our Cordova-iOS
-application directory:
+Then we would add the following files (`Echo.h` and `Echo.m`) to the
+Plugins folder inside our Cordova-iOS application folder:
/********* Echo.h Cordova Plugin Header *******/
@@ -201,9 +215,9 @@ call, you should use a background thread. For example:
See other methods that you can override in:
-* [CDVPlugin.h](https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVPlugin.h)
+- [CDVPlugin.h](https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVPlugin.h)
-* [CDVPlugin.m](https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVPlugin.m)
+- [CDVPlugin.m](https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVPlugin.m)
For example, you can hook into the `pause`, `resume`, app terminate and `handleOpenURL` events.
@@ -219,6 +233,9 @@ running in the iOS 6 Simulator.
## Common Pitfalls
-* Don't forget to add your plugin's mapping to config.xml. If you forget, an error is logged in the Xcode console.
+- Don't forget to add your plugin's mapping to config.xml. If you
+ forget, an error is logged in the Xcode console.
-* Don't forget to add any hosts you connect to in the whitelist, as described in Domain Whitelist Guide. If you forget, an error is logged in the Xcode console.
+- Don't forget to add any hosts you connect to in the whitelist, as
+ described in Domain Whitelist Guide. If you forget, an error is
+ logged in the Xcode console.
http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/c96e9d30/docs/en/edge/guide/platforms/wp8/plugin.md
----------------------------------------------------------------------
diff --git a/docs/en/edge/guide/platforms/wp8/plugin.md b/docs/en/edge/guide/platforms/wp8/plugin.md
index b530f8e..33ab84c 100644
--- a/docs/en/edge/guide/platforms/wp8/plugin.md
+++ b/docs/en/edge/guide/platforms/wp8/plugin.md
@@ -152,22 +152,29 @@ in case we have bad input. This is a pattern used throughout the Cordova C# code
## Plugin XML
-These are windows phone specific examples of using the plugin.xml file, refer to the Plugin Specification for more details
+These are windows phone specific examples of using the plugin.xml
+file, refer to the Plugin Specification for more details
### `<source-file>`
-On windows phone the `<source-file>` element is currently used to define all plugin resources (ie. .cs, .xaml, .xaml.cs, .dll, image assets etc).
+On windows phone the `<source-file>` element is currently used to
+define all plugin resources (ie. .cs, .xaml, .xaml.cs, .dll, image
+assets etc).
### `<config-file>`
-The `<config-file>` element defines what elements get put into a config file. For example to add a plugin to the platforms config.xml, you would do something like this :
+The `<config-file>` element defines what elements get put into a
+config file. For example to add a plugin to the platforms config.xml,
+you would do something like this :
<config-file target="config.xml" parent="/*">
<feature name="PluginName">
<param name="wp-package" value="PluginName"/>
</feature>
</config-file>
-If we wanted to add the contacts capability to the WMAppManifest.xml, it would look like this :
+
+If we wanted to add the contacts capability to the WMAppManifest.xml,
+it would look like this :
<config-file target="Properties/WMAppManifest.xml" parent="/Deployment/App/Capabilities">
<Capability Name="ID_CAP_CONTACTS" />
@@ -177,7 +184,7 @@ If we wanted to add the contacts capability to the WMAppManifest.xml, it would l
See other methods that you can override in:
-* [BaseCommand.cs](https://github.com/apache/cordova-wp7/blob/master/templates/standalone/cordovalib/Commands/BaseCommand.cs)
+- [BaseCommand.cs](https://github.com/apache/cordova-wp7/blob/master/templates/standalone/cordovalib/Commands/BaseCommand.cs)
For example, you can hook into the 'pause' and 'resume' application events.