URL Scheme and openURL, URLSchemeopenURL
URL Schemes
URL Schemes is a mechanism provided by Apple to jump to a system application or to another application. Data can also be transferred between applications.
Set a URL Schemes: select the App project-> Info-> URL Types to add multiple.
In Info. plist, it is as follows:
The code for opening an App is as follows:
1 NSURL *url = [NSURL URLWithString:@"testapp://"];2 [[UIApplication sharedApplication] openURL:url];
If the two applications have the same URL Schemes, the URL Schemes of the later installed application overwrites the URL Schemes of the earlier installed application.
Open in safari
Registered URL Schemes applications can also be opened in safari. This can be used to verify whether the application has set the desired URL Schemes.
Method: Enter testapp in the address bar of safari.://
, Enter.
CanOpenURL
canOpenURL
Method to Determine whether the url can be opened, and then useopenURL
Method to open the URL. This provides a better user experience.
1 if ([[UIApplication sharedApplication] canOpenURL:url]) {2 [[UIApplication sharedApplication] openURL:url];3 }
When iOS9 is used, Apple has enhanced its permissions. It can only be used if the URL Schemes White List is added to the info. plist file.canOpenURL:
Method to Determine whether the url can be opened. The maximum number of white lists is 50.
Add the whitelist here (the items added after FacebookSDK is connected ):
Corresponding Info. plist:
Use URL Schems to pass data
In addition to opening an APP, URL Schemes can also be used to transmit a small amount of data between two apps.
1 - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url NS_DEPRECATED_IOS(2_0, 9_0, "Please use application:openURL:options:") __TVOS_PROHIBITED;2 3 - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(nullable NSString *)sourceApplication annotation:(id)annotation NS_DEPRECATED_IOS(4_2, 9_0, "Please use application:openURL:options:") __TVOS_PROHIBITED;4 5 - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString*, id> *)options NS_AVAILABLE_IOS(9_0); // no equiv. notification. return NO if the application can't open for some reason
The url can be written as follows: testapp: // www.abc.com/abc? Title = hello & content = helloworld, the url of the above three methods will receive the following parameter information, so as to realize data transmission between apps.
The following are the differences between the Three callbacks:
- The three callback functions are basically the same. They are executed when someone else opens an application through URL Schemes.
Differences:
- A callback was introduced at iOS2.0, with only Parameters
url
.
- B is released at iOS4.2. The parameters include:
url
sourceApplication
annotation
.
- C callback was introduced when iOS9.0 was used. The parameters include:
url
options
.options
The following keys are available:// Keys for application:openURL:options:UIKIT_EXTERN NSString *const UIApplicationOpenURLOptionsSourceApplicationKey NS_AVAILABLE_IOS(9_0); // value is an NSString containing the bundle ID of the originating applicationUIKIT_EXTERN NSString *const UIApplicationOpenURLOptionsAnnotationKey NS_AVAILABLE_IOS(9_0); // value is a property-list typed object corresponding to what the originating application passed in UIDocumentInteractionController's annotation propertyUIKIT_EXTERN NSString *const UIApplicationOpenURLOptionsOpenInPlaceKey NS_AVAILABLE_IOS(9_0); // value is a bool NSNumber, set to YES if the file needs to be copied before use
- These Callbacks have priority values. C> B>. That is to say, if all three Callbacks are implemented, the program will only execute the C callback. Other Callbacks are not executed. (Of course, only B callback is executed under iOS9 ).
Finally, when multiple sdks are connected, the openurl method may be rewritten between sdks, which may cause A to overwrite B and B's openurl callback will no longer be called.
For example, if the project is connected to shareSDK and facebookSDK, it is found that the logon callback of facebookSDK is not always available.
To verify this, you can open a breakpoint at the callback, for example:
If it cannot be broken, most of them will be killed by others. If there is no similar AppController in the search project, this function is also implemented to see how other sdks are killed, or make a trade-off, or make effort to be compatible.
Organized from (http://www.jianshu.com/p/0811ccd6a65d), with some experience of yourself.