react-native-macos/Libraries/LinkingIOS/RCTLinkingManager.mm

198 строки
6.7 KiB
Plaintext
Исходник Обычный вид История

/*
* Copyright (c) Facebook, Inc. and its affiliates.
2015-03-26 04:59:42 +03:00
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
2015-03-26 04:59:42 +03:00
*/
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
#import <React/RCTLinkingManager.h>
2015-03-26 04:59:42 +03:00
#import <FBReactNativeSpec/FBReactNativeSpec.h>
#import <React/RCTBridge.h>
#import <React/RCTUtils.h>
#import <React/RCTLog.h>
2015-03-26 04:59:42 +03:00
#import "RCTLinkingPlugins.h"
static NSString *const kOpenURLNotification = @"RCTOpenURLNotification";
static void postNotificationWithURL(NSURL *URL, id sender)
{
NSDictionary<NSString *, id> *payload = @{@"url": URL.absoluteString};
[[NSNotificationCenter defaultCenter] postNotificationName:kOpenURLNotification
object:sender
userInfo:payload];
}
@interface RCTLinkingManager() <NativeLinkingManagerSpec>
@end
2015-03-26 04:59:42 +03:00
@implementation RCTLinkingManager
2015-04-08 18:52:48 +03:00
RCT_EXPORT_MODULE()
- (dispatch_queue_t)methodQueue
{
return dispatch_get_main_queue();
}
- (void)startObserving
2015-03-26 04:59:42 +03:00
{
Refactored module access to allow for lazy loading Summary: public The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed. This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead. The rules are now as follows: * Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created * Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread. * All other modules will be initialized lazily when a method is first called on them. These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily. I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results: Out of the 65 modules included in UIExplorer: * 16 are initialized on the main thread when the bridge is created * A further 8 are initialized when the config is exported to JS * The remaining 41 will be initialized lazily on-demand Reviewed By: jspahrsummers Differential Revision: D2677695 fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
2015-11-25 14:09:00 +03:00
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(handleOpenURLNotification:)
name:kOpenURLNotification
Refactored module access to allow for lazy loading Summary: public The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed. This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead. The rules are now as follows: * Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created * Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread. * All other modules will be initialized lazily when a method is first called on them. These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily. I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results: Out of the 65 modules included in UIExplorer: * 16 are initialized on the main thread when the bridge is created * A further 8 are initialized when the config is exported to JS * The remaining 41 will be initialized lazily on-demand Reviewed By: jspahrsummers Differential Revision: D2677695 fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
2015-11-25 14:09:00 +03:00
object:nil];
}
- (void)stopObserving
Refactored module access to allow for lazy loading Summary: public The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed. This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead. The rules are now as follows: * Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created * Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread. * All other modules will be initialized lazily when a method is first called on them. These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily. I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results: Out of the 65 modules included in UIExplorer: * 16 are initialized on the main thread when the bridge is created * A further 8 are initialized when the config is exported to JS * The remaining 41 will be initialized lazily on-demand Reviewed By: jspahrsummers Differential Revision: D2677695 fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
2015-11-25 14:09:00 +03:00
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
2015-03-26 04:59:42 +03:00
}
- (NSArray<NSString *> *)supportedEvents
2015-03-26 04:59:42 +03:00
{
return @[@"url"];
2015-03-26 04:59:42 +03:00
}
+ (BOOL)application:(UIApplication *)app
openURL:(NSURL *)URL
options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options
{
postNotificationWithURL(URL, self);
return YES;
}
// Corresponding api deprecated in iOS 9
2015-03-26 04:59:42 +03:00
+ (BOOL)application:(UIApplication *)application
openURL:(NSURL *)URL
2015-03-26 04:59:42 +03:00
sourceApplication:(NSString *)sourceApplication
annotation:(id)annotation
{
postNotificationWithURL(URL, self);
2015-03-26 04:59:42 +03:00
return YES;
}
+ (BOOL)application:(UIApplication *)application
continueUserActivity:(NSUserActivity *)userActivity
restorationHandler:
#if defined(__IPHONE_OS_VERSION_MAX_ALLOWED) && (__IPHONE_OS_VERSION_MAX_ALLOWED >= 12000) /* __IPHONE_12_0 */
(nonnull void (^)(NSArray<id<UIUserActivityRestoring>> *_Nullable))restorationHandler {
#else
(nonnull void (^)(NSArray *_Nullable))restorationHandler {
#endif
if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) {
NSDictionary *payload = @{@"url": userActivity.webpageURL.absoluteString};
[[NSNotificationCenter defaultCenter] postNotificationName:kOpenURLNotification
object:self
userInfo:payload];
}
return YES;
}
2015-03-26 04:59:42 +03:00
- (void)handleOpenURLNotification:(NSNotification *)notification
{
[self sendEventWithName:@"url" body:notification.userInfo];
2015-03-26 04:59:42 +03:00
}
RCT_EXPORT_METHOD(openURL:(NSURL *)URL
resolve:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject)
2015-03-26 04:59:42 +03:00
{
[RCTSharedApplication() openURL:URL options:@{} completionHandler:^(BOOL success) {
if (success) {
resolve(@YES);
} else {
#if TARGET_OS_SIMULATOR
// Simulator-specific code
if([URL.absoluteString hasPrefix:@"tel:"]){
RCTLogWarn(@"Unable to open the Phone app in the simulator for telephone URLs. URL: %@", URL);
resolve(@NO);
} else {
reject(RCTErrorUnspecified, [NSString stringWithFormat:@"Unable to open URL: %@", URL], nil);
}
#else
// Device-specific code
reject(RCTErrorUnspecified, [NSString stringWithFormat:@"Unable to open URL: %@", URL], nil);
#endif
}
}];
2015-03-26 04:59:42 +03:00
}
RCT_EXPORT_METHOD(canOpenURL:(NSURL *)URL
resolve:(RCTPromiseResolveBlock)resolve
reject:(__unused RCTPromiseRejectBlock)reject)
2015-03-26 04:59:42 +03:00
{
if (RCTRunningInAppExtension()) {
// Technically Today widgets can open urls, but supporting that would require
// a reference to the NSExtensionContext
resolve(@NO);
return;
}
// This can be expensive, so we deliberately don't call on main thread
BOOL canOpen = [RCTSharedApplication() canOpenURL:URL];
NSString *scheme = [URL scheme];
if (canOpen) {
resolve(@YES);
} else if (![[scheme lowercaseString] hasPrefix:@"http"] && ![[scheme lowercaseString] hasPrefix:@"https"]) {
// On iOS 9 and above canOpenURL returns NO without a helpful error.
// Check if a custom scheme is being used, and if it exists in LSApplicationQueriesSchemes
NSArray *querySchemes = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"LSApplicationQueriesSchemes"];
if (querySchemes != nil && ([querySchemes containsObject:scheme] || [querySchemes containsObject:[scheme lowercaseString]])) {
resolve(@NO);
} else {
reject(RCTErrorUnspecified, [NSString stringWithFormat:@"Unable to open URL: %@. Add %@ to LSApplicationQueriesSchemes in your Info.plist.", URL, scheme], nil);
}
} else {
resolve(@NO);
}
2015-03-26 04:59:42 +03:00
}
RCT_EXPORT_METHOD(getInitialURL:(RCTPromiseResolveBlock)resolve
reject:(__unused RCTPromiseRejectBlock)reject)
{
NSURL *initialURL = nil;
if (self.bridge.launchOptions[UIApplicationLaunchOptionsURLKey]) {
initialURL = self.bridge.launchOptions[UIApplicationLaunchOptionsURLKey];
} else {
NSDictionary *userActivityDictionary =
self.bridge.launchOptions[UIApplicationLaunchOptionsUserActivityDictionaryKey];
if ([userActivityDictionary[UIApplicationLaunchOptionsUserActivityTypeKey] isEqual:NSUserActivityTypeBrowsingWeb]) {
initialURL = ((NSUserActivity *)userActivityDictionary[@"UIApplicationLaunchOptionsUserActivityKey"]).webpageURL;
}
}
resolve(RCTNullIfNil(initialURL.absoluteString));
}
- Add openSettings method to Linking module (#23965) Summary: This will create a cross-platform and safe way to programmatically open the app's settings into the iOS /Android Settings app. Right now it's possible to open the app's settings, but _**only for iOS**_ via `Linking.openURL("app-settings:")` To do the same for Android, you need to either create NodeModule or install a dependency such as [react-native-open-settings](https://github.com/lunarmayor/react-native-open-settings). Why this new method is useful: since Android 6, app permissions work similar to iOS. It's granular and it's requested in the app runtime. https://developer.android.com/guide/topics/permissions/overview#runtime_requests_android_60_and_higher > If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the user isn't notified of any app permissions at install time. Your app must ask the user to grant the dangerous permissions at runtime. When your app requests permission, the user sees a system dialog telling the user which permission group your app is trying to access. The dialog includes a Deny and Allow button. Thus, if the user checks the **"Never ask again box"** and taps **"Deny"**, for some specific permission, the only way to change the permission is going to the Android Setting app. And that's where this new method becomes useful. It'll allow our apps to programmatically send the the user to settings app. Also, `openSettings()` doesn't receive a parameter to redirect to specific subsections of the Settings app because there's no public API to do it on iOS ([there's a way to have, via private API, but it causes the app to get rejected.](https://github.com/mauron85/cordova-plugin-background-geolocation/issues/394)) Create `Linking.openSettings()` for iOS and Android; [General] [add ] - Add openSetting method to Linking module Pull Request resolved: https://github.com/facebook/react-native/pull/23965 Differential Revision: D14502910 Pulled By: cpojer fbshipit-source-id: d27d62282b9df499845c78d983d3b6936c36ea39
2019-03-18 18:03:05 +03:00
RCT_EXPORT_METHOD(openSettings:(RCTPromiseResolveBlock)resolve
reject:(__unused RCTPromiseRejectBlock)reject)
{
NSURL *url = [NSURL URLWithString:UIApplicationOpenSettingsURLString];
[RCTSharedApplication() openURL:url options:@{} completionHandler:^(BOOL success) {
if (success) {
resolve(nil);
} else {
reject(RCTErrorUnspecified, @"Unable to open app settings", nil);
}
}];
- Add openSettings method to Linking module (#23965) Summary: This will create a cross-platform and safe way to programmatically open the app's settings into the iOS /Android Settings app. Right now it's possible to open the app's settings, but _**only for iOS**_ via `Linking.openURL("app-settings:")` To do the same for Android, you need to either create NodeModule or install a dependency such as [react-native-open-settings](https://github.com/lunarmayor/react-native-open-settings). Why this new method is useful: since Android 6, app permissions work similar to iOS. It's granular and it's requested in the app runtime. https://developer.android.com/guide/topics/permissions/overview#runtime_requests_android_60_and_higher > If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the user isn't notified of any app permissions at install time. Your app must ask the user to grant the dangerous permissions at runtime. When your app requests permission, the user sees a system dialog telling the user which permission group your app is trying to access. The dialog includes a Deny and Allow button. Thus, if the user checks the **"Never ask again box"** and taps **"Deny"**, for some specific permission, the only way to change the permission is going to the Android Setting app. And that's where this new method becomes useful. It'll allow our apps to programmatically send the the user to settings app. Also, `openSettings()` doesn't receive a parameter to redirect to specific subsections of the Settings app because there's no public API to do it on iOS ([there's a way to have, via private API, but it causes the app to get rejected.](https://github.com/mauron85/cordova-plugin-background-geolocation/issues/394)) Create `Linking.openSettings()` for iOS and Android; [General] [add ] - Add openSetting method to Linking module Pull Request resolved: https://github.com/facebook/react-native/pull/23965 Differential Revision: D14502910 Pulled By: cpojer fbshipit-source-id: d27d62282b9df499845c78d983d3b6936c36ea39
2019-03-18 18:03:05 +03:00
}
RCT_EXPORT_METHOD(sendIntent:(NSString *)action
extras:(NSArray *_Nullable)extras
resolve:(RCTPromiseResolveBlock)resolve
reject:(RCTPromiseRejectBlock)reject)
{
RCTLogError(@"Not implemented: %@", NSStringFromSelector(_cmd));
}
Part 2: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams Summary: ## Summary Please check out D21035209. ## Changes - Codemod all ObjC NativeModule `getTurboModuleWithJsInvoker:nativeInvoker:perfLogger` methods to `getTurboModule:(const ObjCTurboModule::Args)` ## Script ``` var withSpaces = (...args) => args.join('\s*') var regexString = withSpaces( '-', '\(', 'std::shared_ptr', '<', '(?<turboModuleClass>(facebook::react::|react::|::|)TurboModule)', '>', '\)', 'getTurboModuleWithJsInvoker', ':', '\(', 'std::shared_ptr', '<', '(?<fbNamespace>(facebook::react::|react::|::|))CallInvoker', '>', '\)', '(?<jsInvokerInstance>[A-Za-z0-9]+)', 'nativeInvoker', ':', '\(', 'std::shared_ptr', '<', '(facebook::react::|react::|::|)CallInvoker', '>', '\)', '(?<nativeInvokerInstance>[A-Za-z0-9]+)', 'perfLogger', ':', '\(', 'id', '<', 'RCTTurboModulePerformanceLogger', '>', '\)', '(?<perfLoggerInstance>[A-Za-z0-9]+)', '{', 'return', 'std::make_shared', '<', '(?<specName>(facebook::react::|react::|::|)Native[%A-Za-z0-9]+SpecJSI)', '>', '\(', 'self', ',', '\k<jsInvokerInstance>', ',', '\k<nativeInvokerInstance>', ',', '\k<perfLoggerInstance>', '\)', ';', '}', ) var replaceString = `- (std::shared_ptr<$<turboModuleClass>>) getTurboModule:(const $<fbNamespace>ObjCTurboModule::InitParams &)params { return std::make_shared<$<specName>>(params); }` const exec = require('../lib/exec'); const abspath = require('../lib/abspath'); const relpath = require('../lib/relpath'); const readFile = (filename) => require('fs').readFileSync(filename, 'utf8'); const writeFile = (filename, content) => require('fs').writeFileSync(filename, content); function main() { const tmFiles = exec('cd ~/fbsource && xbgs -n 10000 -l getTurboModuleWithJsInvoker:').split('\n').filter(Boolean); tmFiles .filter((filename) => !filename.includes('microsoft-fork-of-react-native')) .map(abspath) .forEach((filename) => { const source = readFile(filename); const newSource = source.replace(new RegExp(regexString, 'g'), replaceString); if (source == newSource) { console.log(relpath(filename)); } writeFile(filename, newSource); }); } if (!module.parent) { main(); } ``` ## Re-generating diff ``` > hg revert -r .^ --all > node index.js # run script ``` Changelog: [iOS][Changed] - Make all ObjC NativeModules create TurboModules using ObjCTurboModule::Args Reviewed By: PeteTheHeat Differential Revision: D21036265 fbshipit-source-id: 404bcc548d1775ef23d793527606d02fe384a0a2
2020-04-17 03:23:39 +03:00
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params
{
return std::make_shared<facebook::react::NativeLinkingManagerSpecJSI>(params);
}
2015-03-26 04:59:42 +03:00
@end
Class RCTLinkingManagerCls(void) {
return RCTLinkingManager.class;
}