iOS Plugin Development Guide
In iOS WebView development, Cordova is often used as an enhanced version of the WebView. For example of this part, you can refer to the author’s iOSBoilerplate, and check the instructions in reame. md. You can also run it directly after git clone and enter the relevant page according to the instructions.
Installation
Introducing Cordova involves three steps:
(1) Add dependencies to your Podfile
You can use the pod search Cordova command to search for available versions of Cordova. I used version 4.0.1:
Pod 'Cordova', '~> 4.0.1' # Support for Cordova WebView containersCopy the code
Then use the pod install command to download it.
(2) Add config.xml
Config.xml is the main configuration file, and in iOS it needs to be placed in the /AppName/config.xml style. An example of the author’s config.xml file is as follows:
iOSBoilerplate
Cordova Demo in iOS Boilerplate
Chevalier
Copy the code
(3) Add WWW folder
When importing a WWW folder into XCode, do not select Copy but File Reference. The final folder should be blue instead of yellow as shown below.
Network Configuration
cordova-5-ios-9-security-policy-changes
Sometimes, some network requests are banned during iOS configuration. You can perform the following steps to rectify the fault.
(1) Check whether the network request whitelist is set in config. XML. To be clear, cordova-plugin-whitelist is not available on iOS.
Copy the code
(2) After iOS 9, non-HTTPS requests are not allowed to be sent by default, so we need to modify the configuration to allow HTTP requests.
NSAppTransportSecurity NSAllowsArbitraryLoads Copy the code
(3) Check Content Security Policy
Content Security policies are generally used to control the Content of web pages, but they are visible in the browser if they prevent you from accessing the web.
Copy the code
Plugins
Config
Any plug-in first needs to be registered in config.xml:
Copy the code
There are no initializers specified for the plug-in. Instead, use the plug-in pluginInitialize to start the logical methods for it. The plugin requires long-running requests, such as media replay, listeners, and internal states to keep background activities onReset method to clean up these activities. UIWebView positions to a new page or refreshes and reloads JavaScript while the method is running.
JS Modules
For details about the JS configuration, please refer to the official JS Modules section. Here we won’t go into details, just show the basic usage:
window.echo = function(str, callback) {
cordova.exec(callback, function(err) {
callback('Nothing to echo.');
}, "CordovaPluginsBridge", "echo", [str]);
};Copy the code
Call:
window.echo("echome", function(echoValue) {
alert(echoValue == "echome"); // should alert true.
});Copy the code
Note that calls to Cordova are usually placed in $(document).ready() of jQuery.
IOS native methods
JavaScript calls trigger plug-in requests to the native side, and the corresponding iOS target C plug-in maps correctly in the config.xml file, but in the end what does the iOS target C plug-in class look like? Either the exec function sent to the plug-in with JavaScript is passed to the action method of the corresponding plug-in class. The plug-in’s methods have this signature:
- (void)myMethod:(CDVInvokedUrlCommand*)command { CDVPluginResult* pluginResult = nil; NSString* myarg = [command.arguments objectAtIndex:0]; if (myarg ! = nil) { pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK]; } else { pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_ERROR messageAsString:@"Arg was null"]; } [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId]; }Copy the code
IOS CDVPluginResult Message type
You can use CDVPluginResult to return multiple types of JavaScript callback functions for the result, using class methods that follow this pattern:
+ (CDVPluginResult*)resultWithStatus:(CDVCommandStatus)statusOrdinal messageAs...
Copy the code
You can create the String, Int, Double, Bool, Array, Dictionary, ArrayBuffer, and Multipart types. You can also leave off any parameters to send status, or return an error, or even choose not to send any plug-in results, in which case neither dialing back the fire.
Note the following complex return values:
-
MessageAsArrayBuffer expects NSData* and will be converted to ArrayBuffer in JavaScript back file. Similarly, any ArrayBuffer JavaScript sent to a plug-in will be converted to NSData*.
-
MessageAsMultipart expects that NSArray* contains any other support types and will send the entire array as arguments to your JavaScript callback. This way, all parameters in serialization or deserialization are as necessary so it is safe to return NSData* as multiple parts, but not Array /Dictionary.
Asynchronous execution
If some of the code takes a long time to execute, it can be executed in a background process.
- (void)myPluginMethod:(CDVInvokedUrlCommand*)command { // Check command.arguments here. [self.commandDelegate runInBackground:^{ NSString* payload = nil; // Some blocking logic... CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK messageAsString:payload]; // The sendPluginResult method is thread-safe. [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId]; }]; }Copy the code