Summary:
Fixes an issue introduced in https://github.com/facebook/react-native/pull/15894 that can cause events to be dispatched out of order.
Also reverted `viewTag` moved to optional property as it didn't actually work and makes code more complex.
[iOS] [Fixed] - Fix event ordering when combining coalescable and non-coalescable events
Pull Request resolved: https://github.com/facebook/react-native/pull/24693
Differential Revision: D15279513
Pulled By: shergin
fbshipit-source-id: 3c64aba6d644ea9564572e6de8330b59b51cf4a9
Summary:
When trying to load image using method "RCTImageFromLocalAssetURL", if URL's path in file system representation return null (in my case, imageUrl is base64 format returned from server so it's always null) then method "stringWithUTF8String" will raise an exception.
[iOS] [Fixed] - Fix exception when attempt to load image from file system
Pull Request resolved: https://github.com/facebook/react-native/pull/24457
Differential Revision: D15123680
Pulled By: shergin
fbshipit-source-id: bc34b3d7c79a8f9157729c4cf0486507c3c15ddf
Summary: The changes made in D14811733 introduced a regression in React Native's open source iOS tests.
Reviewed By: fkgozali
Differential Revision: D14895096
fbshipit-source-id: 4307b094e3bc94e9f703b0271a95a9b318bcd49a
Summary:
Currently, `RCTLocalAssetImageLoader` only support directory of `Library` and `App bundle`, actually, we need to support other directories like `tmp` or `Documents`. Otherwise, the local image load in `tmp` or `Documents` would be handled by `NSURLSession`, we don't need that.
<img width="405" alt="image" src="https://user-images.githubusercontent.com/5061845/54188126-0ba66100-44ea-11e9-9a7b-0f721100e9be.png">
[iOS] [Fixed] - Enhance search of directories when load local asset image
Pull Request resolved: https://github.com/facebook/react-native/pull/23857
Differential Revision: D14894136
Pulled By: shergin
fbshipit-source-id: 26361cd952a423467be9af9a84a80100d868776b
Summary:
The root cause comes down to the fact that historically `-DFOO=0` and `-DFOO=1` patterns have been used when it comes to preprocessor definitions and various engineers use `#ifdef FOO` and `#if FOO` interchangeably. That results in an incorrect pattern because the real evaluation is following:
- `FOO` not defined: `#if FOO` = `FALSE`, `#ifdef FOO` = `FALSE`.
- `-DFOO=0`: `#if FOO` = `FALSE`, `#ifdef FOO` = `TRUE`.
- `-DFOO=1`: `#if FOO` = `TRUE`, `#ifdef FOO` = `TRUE`.
Reviewed By: aditya7fb
Differential Revision: D14811733
fbshipit-source-id: a7fedc56ab0ce8eedcb48bda783739a4c1eecf81
Summary:
Xcode 10.2 forbids creating categories for swift class that uses `+load` method. In react-native categories like this are used to register swift classes as modules (macro `RCT_EXTERN_MODULE`) This PR changes it to use `__attribute__((constructor))` instead of objc `+load` method.
I introduced new macro for this purpose, `RCT_EXPORT_MODULE_NO_LOAD`, it expands in something like:
```
void RCTRegisterModule(Class);
+ (NSString *)moduleName {
return @"jsNameFoo";
}
__attribute__((constructor)) static void initialize_ObjcClassFoo{
RCTRegisterModule([ObjcClassFoo class]);
}
```
Functions marked with `__attribute__((constructor))` are run before main and after all `+load` methods, so it seems like correct thing to do.
Fixes https://github.com/facebook/react-native/issues/24139
Doc about loading order https://developer.apple.com/documentation/objectivec/nsobject/1418815-load?language=objc
[iOS] [Fixed] - Fix runtime crash in xcode 10.2 when using RCT_EXTERN_MODULE for swift classes.
Pull Request resolved: https://github.com/facebook/react-native/pull/24155
Reviewed By: javache
Differential Revision: D14668235
Pulled By: shergin
fbshipit-source-id: 0c19e69ce2a68327387809773848d4ecd36d7461
Summary:
This makes the RCTEvent protocol more generic to make it easier to use the event coalescing feature for type of events other than components. This does a few other improvements that will be useful in follow up PRs.
- Add `RCTComponentEvent` which is used instead of deprecated `[sendInputEventWithName:body:]` and remove that method completely (was only used at 2 places).
- Make `coalescingKey` optional for events that return NO from `canCoalesce`.
- Make `viewTag` optional for events that are not related to views.
- Fast path for events that return NO from `canCoalesce`.
- Add a missing test for event coalescing with different view tags.
Ended up making only one PR for all this since the changes are related and hard to separate.
**Migration**
Use a custom RCTEvent subclass with `[sendEvent:]` (preferred way to allow type safe events) or `RCTComponentEvent`.
**Test plan**
- Ran RCTEventDispatcher unit tests
- Tested manually in RNTester
Changelog:
[iOS] [Changed] - Remove deprecated RCTEvent method, sendInputEventWithName:body:
Pull Request resolved: https://github.com/facebook/react-native/pull/15894
Reviewed By: shergin
Differential Revision: D13726194
Pulled By: hramos
fbshipit-source-id: 11f63a99e08f46ec6b4f16f8d9949cdbf5c3fe13
Summary:
With our current infra, we support automatic conversion of method arguments using `RCTConvert`.
```
RCT_EXPORT_METHOD(foo:(RCTSound*) sound)
{
//...
}
```
```
interface RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict;
end
implementation RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict
{
//...
}
end
```
```
export interface Spec extends TurboModule {
+foo: (dict: Object) => void,
}
```
With this setup, when we call the foo method on the TurboModule in JS, we'd first convert `dict` from a JS Object to an `NSDictionary`. Then, because the `foo` method has an argument of type`RCTSound*`, and because `RCTConvert` has a method called `RCTSound`, before we invoke the `foo` NativeModule native method, we first convert the `NSDictionary` to `RCTSound` using `[RCTConvert RCTSound:obj]`. Essentially, if an argument type of a TurboModule method is neither a primitive type nor a struct (i.e: is an identifier), and it corresponds to a selector on `RCTConvert`, we call `[RCTConvert argumentType:obj]` to convert `obj` to the type `argumentType` before passing in `obj` as an argument to the NativeModule method call.
**Note:** I originally planned on using `NSMethodSignature` to get the argument types. Unfortunately, while the Objective C Runtime lets us know that the type is an identifier, it doesn't inform us which identifier it is. In other words, at runtime, we can't determine whether identifier represents `RCTSound *` or some other Objective C class. I figure this also the reason why the old code relies on the `RCT_EXPORT_METHOD` macros to implement this very same feature: https://git.io/fjJsC. It uses `NSMethodSignature` to switch on the argument type, and then uses the `RCTMethodInfo` struct to parse the argument type name, from which it constructs the RCTConvert selector.
One caveat of the current solution is that it won't work work unless we decorate our TurboModule methods with `RCT_EXPORT_METHOD`.
Reviewed By: fkgozali
Differential Revision: D14582661
fbshipit-source-id: 3c7dfb2059f031dba7495f12cbdf406b14f0b5b4
Summary:
The `RCTBridge` contains numerous definitions of notification names, which we can observe in order to get insights into the React Native performance.
The Android implementation is a little different, such that you can listen for any of the [following](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactMarkerConstants.java) marker constants, simply by including the following code:
```java
ReactMarker.addListener(new ReactMarker.MarkerListener() {
Override
public void logMarker(ReactMarkerConstants name, Nullable String tag, int instanceKey) {
Log.d("ReactNativeEvent", "name: "+ name.name() + " tag: " + tag);
}
});
```
This will allow you to perform the necessary processing, calculations as required.
---
This PR enables observing for the module setup event (`RCTDidSetupModuleNotification`) by including the respective module's name & setup time in milliseconds.
[iOS] [Added] - Gain insights on the module setup times by observing `RCTDidSetupModuleNotification`. The `userInfo` dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey ` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23859
Differential Revision: D14579066
Pulled By: PeteTheHeat
fbshipit-source-id: 52645127c3fc6aa5bd73e3bd471fccd79cb05c14
Summary:
We need to remove adding png file extension when path has not extension. Two reasons:
1. `imageWithContentsOfFile` or other `UIKit` methods can load png image correctly, even if path has not `png` file extension.
2. Sometimes, people may have file that actually not have file extension, it's the designated behavior for user. Like #23844 .
CC. sahrens cpojer .
[iOS] [Fixed] - Remove explicitly add png file extension when load local image
Pull Request resolved: https://github.com/facebook/react-native/pull/23864
Reviewed By: shergin
Differential Revision: D14425373
Pulled By: hramos
fbshipit-source-id: 3cc06c9a3d68cadf652c1de742f3cce26258c874
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
Summary:
We currently rely on the Paper UIManager calling `uiManagerWillPerformMounting` to flush the animated operations queue, which includes starting and stopping animations. This mostly works right now because Fabric always starts after Paper, but sometimes Paper doesn't fire `uiManagerWillPerformMounting` for a while, which can delay an animation starting.
To fix this, I force a flush of the queues on the UIThread whenever start or stop is called. This should be safe because the order of animation operations is still preserved, and start/stop are (almost?) always called in dedicated event handler loops, so any other updates like changing the way nodes are attached should already have been processed from a previous JS execution loop.
Reviewed By: JoshuaGross
Differential Revision: D14313502
fbshipit-source-id: 2a2b0c614fd1a591bd04b6b3fafcc09ff6c9d6e7
Summary:
Between invalidating a bridge and suspending its JS thread, native modules may have their methods called.
Only warn when a native module has been invalidated, which happens right before its JS thread is suspended.
Avoid initializing a native module's instance if its bridge is invalidated.
/cc fkgozali f945212447 (commitcomment-32467567)
[iOS] [Fixed] - Properly validate JS->native method calls
Pull Request resolved: https://github.com/facebook/react-native/pull/23658
Differential Revision: D14287594
Pulled By: fkgozali
fbshipit-source-id: 89dd1906a0c55f3f48ba4ff220aac0cddf2eb822
Summary:
We have parse code to try to support exported method parameter annotated `__unused` and `nullable`, but actually, seems we don't support it entirely, for example, we parse `__unused` firstly, then we parse `nullable`, actually, this case not exist, because `nullable` macro must appear right after `(`, before `__unused`, so we can't parse success, leads to error signature and crash.
[iOS] [Fixed] - Fixed method invoke when both nullable and __unused exist
Pull Request resolved: https://github.com/facebook/react-native/pull/23726
Differential Revision: D14298563
Pulled By: cpojer
fbshipit-source-id: 934e1d384a5d67b7bbf117fd2dec51f50979c979
Summary:
We need to check `body[@"target"]` wether equal to `nil`, if it is, return to prevent crash.
[iOS] [Fixed] - Fixed crash if event doesn't have body parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/23711
Differential Revision: D14298543
Pulled By: cpojer
fbshipit-source-id: d5e8cd69438f323ae102e61618c0371a01bee347
Summary:
For the `NullabilityPostfix`, we can use `_Nullable` or `__nullable`. Please see https://developer.apple.com/swift/blog/?id=25 , and we also use it in our code.
[iOS] [Added] - Added support of __nullable and __nonnull for module exported method signature
Pull Request resolved: https://github.com/facebook/react-native/pull/23731
Differential Revision: D14298483
Pulled By: cpojer
fbshipit-source-id: 4dd3188f51be3808ea2b97ce19aa7a85ea1f4a9e
Summary:
We already only support `iOS9+`, so we can remove all compatible codes now.
[iOS] [Fixed] - Remove compatible system code for iOS8 and before
Pull Request resolved: https://github.com/facebook/react-native/pull/23656
Differential Revision: D14224986
Pulled By: hramos
fbshipit-source-id: cac9ffe6788dd3eaf4f4f5f2b219f325ba78e85f
Summary:
When an image source is parsed via `RCTImageFromLocalAssetURL` there seem to be certain situations in which `imageName` is empty from `RCTBundlePathForURL`. Any call to `UIImage imageNamed` with a an empty parameter will throw an exception:
```
CUICatalog: Invalid asset name supplied: '(null)'
```
In my case, the asset URL was pointing to an image in the application sandbox rather than the `NSBundle`. In this case `UIImage imageNamed` was throwing before the call to `NSData dataWithContentsOfURL` below could correctly resolve the image.
This change simply skips the call to `UIImage imageNamed` if no `imageName` value is set.
Pull Request resolved: https://github.com/facebook/react-native/pull/20120
Differential Revision: D14163101
Pulled By: cpojer
fbshipit-source-id: ceec95c02bf21b739962ef5618947a5726ba0473
Summary:
Add an option to dev menu to change packager location on the fly on iOS (similar to Dev Settings in Android)
Pull Request resolved: https://github.com/facebook/react-native/pull/21970
Differential Revision: D14162776
Pulled By: cpojer
fbshipit-source-id: 3cca4f4fbd8c599bd5342ba1ae64905a03270d48
Summary:
As part of #22609, this fixes yet more warnings.
- Adding more __unused to params.
- Refactors `isPackagerRunning` to use NSURLSession.
- Turns off suspicious comma warnings
[iOS] [Fixed] - Xcode Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23565
Differential Revision: D14161151
Pulled By: cpojer
fbshipit-source-id: 339874711eca718fc6151e84737ccc975225d736
Summary:
This PR reduces the number of warnings in React from 68 to 18. Mostly by marking unused variables. RNTester's warnings are more than halved.
[iOS] [Fixed] - Xcode warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23553
Differential Revision: D14151339
Pulled By: hramos
fbshipit-source-id: 8255330bf910a69a4c03051d91d7b0de3fadf2d1
Summary:
There's a very old issue with reload logic: invalidation and resetting up of the bridge could be racing. In this case, we hit a redbox when:
* Chrome debugger is enabled in previous app run, then we launch the app again
* The bridge starts, then immediately reloads itself to connect to Chrome
* On the 2nd setup, the logic to update the green loading bar, with the % indicator for loading off metro, failed to find the DevLoadingView module instance because the bridge is in the middle of invalidating
See https://github.com/facebook/react-native/issues/23235
To test:
Using react-native init from github, do the steps in https://github.com/facebook/react-native/issues/23235, no more redbox. Note that the loading indicator % won't be proper still, but at least it doesn't crash/redbox.
Reviewed By: JoshuaGross
Differential Revision: D14110814
fbshipit-source-id: 835061e50acc6968bffbcc2ddfbe8da79a100df9
Summary:
React native is missing a keyboard type for iOS so I included support for it. So it can be used in react native app
https://developer.apple.com/documentation/uikit/uikeyboardtype/uikeyboardtypeasciicapablenumberpad
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/20597
Differential Revision: D14103498
Pulled By: cpojer
fbshipit-source-id: b0aa17f3e527734c6e90eadc73c96db4dd002698
Summary:
Regression, fix image load from `~/Library` not respect scale factor.
Fixes#22383 , the bug comes from [Clean up some URL path handling](998197f444).
[iOS] [Fixed] - Fix image wrong scale factor when load image from file system
Pull Request resolved: https://github.com/facebook/react-native/pull/23446
Differential Revision: D14099614
Pulled By: cpojer
fbshipit-source-id: eb2267b195a05eb70cdc4671536a4c1d47fb03e2
Summary:
A common util from RN to gate on testing code is `Platform.isTesting()`
Unfortunately, this util does not account for ServerSnapshotTests, since they don't use apple's XCTest infra.
Reviewed By: sahrens
Differential Revision: D13981728
fbshipit-source-id: bf902a04f5d7fcb98a06816f5c2c9b082e7d14b8
Summary:
TurboModules depend on a getConstants method. Existing ObjectiveC modules do not have this method. Therefore, I moved the contents of `constantsToExport` to `getConstants` and then had `constantsToExports` call `getConstants`.
facebook
Since all NativeModules will eventually need to be migrated to the TurboModule system, I didn't restrict this to just the NativeModules in Marketplace.
```
const fs = require('fs');
if (process.argv.length < 3) {
throw new Error('Expected a file containing a list of native modules as the third param');
}
function read(filename) {
return fs.readFileSync(filename, 'utf8');
}
const nativeModuleFilenames = read(process.argv[2]).split('\n').filter(Boolean);
nativeModuleFilenames.forEach((fileName) => {
if (fileName.endsWith('.h')) {
return;
}
const absPath = `${process.env.HOME}/${fileName}`;
const fileSource = read(absPath);
if (/(\n|^)-\s*\((.+)\)getConstants/.test(fileSource)) {
return;
}
const constantsToExportRegex = /(\n|^)-\s*\((.+)\)constantsToExport/;
const result = constantsToExportRegex.exec(fileSource);
if (result == null) {
throw new Error(`Didn't find a constantsToExport function inside NativeModule ${fileName}`);
}
const returnType = result[2];
const newFileSource = fileSource.replace(
constantsToExportRegex,
'$1- ($2)constantsToExport\n' +
'{\n' +
` return ${returnType.includes('ModuleConstants') ? '($2)' : ''}[self getConstants];\n` +
'}\n' +
'\n' +
'- ($2)getConstants'
);
fs.writeFileSync(absPath, newFileSource);
});
```
```
> xbgs -l ')constantsToExport'
```
Reviewed By: fkgozali
Differential Revision: D13951197
fbshipit-source-id: 394a319d42aff466c56a3d748e17c335307a8f47
Summary:
NativeModules are instantiated by the bridge. If they choose, they can capture the bridge instance that instantiated them. From within the NativeModule, the bridge can then be used to lookup other NativeModules. TurboModules have no way to do such a lookup.
Both NativeModules and TurboModules need to be able to query for one another. Therefore, we have four cases:
1. NativeModule accesses NativeModule.
2. NativeModule accesses TurboModule.
3. TurboModule accesses NativeModule.
4. TurboModule accesses TurboModule.
In summary, this solution extends the bridge to support querying TurboModules. It also introduces a `RCTTurboModuleLookupDelegate` protocol, which, implemented by `RCTTurboModuleManager`, supports querying TurboModules:
```
protocol RCTTurboModuleLookupDelegate <NSObject>
- (id)moduleForName:(NSString *)moduleName;
- (id)moduleForName:(NSString *)moduleName warnOnLookupFailure:(BOOL)warnOnLookupFailure;
- (BOOL)moduleIsInitialized:(NSString *)moduleName
end
```
If TurboModules want to query other TurboModules, then they need to implement this protocol and synthesize `turboModuleLookupDelegate`:
```
protocol RCTTurboModuleWithLookupCapabilities
property (nonatomic, weak) id<RCTTurboModuleLookupDelegate> turboModuleLookupDelegate;
end
```
NativeModules will continue to use `RCTBridge` to access other NativeModules. Nothing needs to change.
When we attach the bridge to `RCTTurboModuleManager`, we also attach `RCTTurboModuleManager` to the bridge as a `RCTTurboModuleLookupDelegate`. This allows the bridge to query TurboModules, which enables our NativeModules to transparently (i.e: without any NativeModule code modification) query TurboModules.
In an ideal world, all modules would be TurboModules. Until then, we're going to require that TurboModules use the bridge to query for NativeModules or TurboModules.
`RCTTurboModuleManager` keeps a map of all TurboModules that we instantiated. We simply search in this map and return the TurboModule.
This setup allows us to switch NativeModules to TurboModules without compromising their ability to use the bridge to search for other NativeModules (and TurboModules). When we write new TurboModules, we can have them use `RCTTurboModuleLookupDelegate` to do access other TurboModules. Eventually, after we migrate all NativeModules to TurboModules, we can migrate all old callsites to use `RCTTurboModuleLookupDelegate`.
Reviewed By: fkgozali
Differential Revision: D13553186
fbshipit-source-id: 4d0488eef081332c8b70782e1337eccf10717dae
Summary:
For better modularity, each module conforming to RCTTurboModule should provide a getter for the specific TurboModule instance for itself. This is a bit more extra work for devs, but simplify tooling and allow better modularity vs having a central function that provides the correct instance based on name.
Note: Android may or may not follow this new pattern -- TBD.
Reviewed By: RSNara
Differential Revision: D13882073
fbshipit-source-id: 6d5f82af67278c39c43c4f7970995690d4a82a98
Summary:
Xcode 9 has compiler settings that are more strict. This can occur if someone updates there project to use the default settings.
This patch declares the default type instead of allowing the compiler to determine it. Instead of () we now say (void) in a block call.
Motivation
It was just trying to get my project totally empty of warnings, and it has no side effects. If there are side effects, then we should fix the type and not go with empty to represent void.
Test Plan
Update project settings in Xcode. This code doesn't have any known side effects since the compiler assumes the type is void when not declared.
Release Notes
[DOCS] - Fixed potential compiler build issue on Xcode 9 after updating settings in project.
Pull Request resolved: https://github.com/facebook/react-native/pull/17872
Differential Revision: D6981435
Pulled By: hramos
fbshipit-source-id: 508ecea0f8874dc16a25f1dee6255481b309f8c2
Summary:
Motivation:
----------
As developers want to handle multiple actions on Siri Remote input when using TVEventHandler, it is crucial to differentiate 'swap' and 'tap' events.
Changelog:
----------
[tvOS] [Changed] - 'up', 'down', 'left' and 'right' events are now connected with tapping on edges of remote. New events 'swipeUp', 'swipeDown', 'swipeLeft' and 'swipeRight' added to detect swipes.
Pull Request resolved: https://github.com/facebook/react-native/pull/22916
Differential Revision: D13682705
Pulled By: hramos
fbshipit-source-id: 233ad1cecc04ca4ced75cd00e7fcb65d224ed3ca
Summary:
On iOS platform, RN retains launchOptions dictionary after bridge reload which can lead to unexpected consequences to a developer. The app will receive the same value for `Linking.getInitialURL` during initial launch and during bridge reload. Here's an example from our application. We use deeplinks via custom URL scheme so a user can open the app via link. Also, we reload the bridge when a user signs out. So if a user opens the app via URL, logs out, and a second user logs into the app, the app will behave as though the second user launched the app via the same deeplink. Because reload destroys the JS engine, there's nowhere for our app to remember that it already handled the deeplink activation.
On iOS Linking.getInitialURL() gets URL from the _launchOptions dictionary, so by setting it to nil we prevent retention of initialURL after reload.
This change makes iOS's behavior consistent with Android's. On Android, the launch URL is stored on the `Intent` and reloading the app involves creating a new `Intent`. Consequently, the launch URL is dropped as desired during the reload process.
Pull Request resolved: https://github.com/facebook/react-native/pull/22659
Differential Revision: D13564251
Pulled By: cpojer
fbshipit-source-id: 4c6d81f1775eb3c41b100582436f1c0f1ee6dc36
Summary:
`RCTSurfaceHostingProxyRootView` surfaces are still automatically started right after the initialization to match `RCTRootView` interface, but `RCTSurfaceHostingView` must be started explicitly now. Also fixed some internal stuff so start and register are clear and distinct.
Background / initial motivation:
One tricky bit - we render the template as part of init`ing the rootView, so we don't know what the surfaceId will be before hand to register the UITemplate. Two possible solutions:
1) Require start be called explicitly after initializing the rootView, and setup the context in between.
2) Do something like "setUITemplateConfigForNextSurface" before creating the rootView, and have some hook when the surfaceId is assigned that associates the surfaceId with that "next" UITemplate stuff before.
(1) seems a lot cleaner, but it requires ever user of rootView to explicitly call start on it - how do you feel about that? Seems like we could also use that start call to decide if the initial render should be synchronous or not? start vs. startSync?
Reviewed By: mdvacca
Differential Revision: D13372914
fbshipit-source-id: 6db297870610e6c231f8a78c0dd74d584cb64910
Summary:
So, it does not start itself automatically right after instantiation.
(Classic RCTSurface still kinda start itself automatically but only because start/stop concept is not implemented for this yet.)
Reviewed By: sahrens
Differential Revision: D13461294
fbshipit-source-id: 05430688f69a0d9bf75d03e6d25f02ccd5d3176a
Summary: Some logic to check for surface stage should've done bitwise `&` operation instead of equality check, because we do bitwise `|` whenever we "set stage".
Reviewed By: shergin
Differential Revision: D13459156
fbshipit-source-id: 94e2f5279fb1a31060beb7d6195953b25ce603c9
Summary:
Adds two additional UIBarStyles to RCTConvert
- [x] UIBarStyleBlackOpaque
- [x] UIBarStyleBlackTranslucent
Does not affect any tests or current usage of this conversion.
Pull Request resolved: https://github.com/facebook/react-native/pull/20102
Differential Revision: D13421942
Pulled By: hramos
fbshipit-source-id: 1e609eca0fdea2b56b9f6ac87e759c661bdee12b
Summary:
Fixes#22530
As described in the issue, the previous behavior for the `RCTFatal` macro was to truncate the `reason` on the resulting `NSException` to 75 characters. This would ensure the reason would fit on a single line, but resulted in issues debugging errors that occurred in the wild, as many crash logging tools (like Sentry) discard the `name` value of the exception and use the `reason` as their primary identifier. At 75 characters, useful information like the location of the error would usually be truncated.
- [x] This extends the truncation threshold to 175 characters, which should be short enough to prevent full-screen-takeover length errors, but long enough to provide useful context to the error.
- [x] This adds a `userInfo` value to the resulting `NSException`. It copies over the `userInfo` from the `NSError` passed to the macro, and adds an "untruncated message" value that contains the untruncated version of the `NSException`'s reason.
[iOS] [Changed] - RCTFatalExceptions now include more information in their reason and a userInfo.
<!--
CATEGORY may be:
- [General]
- [iOS]
- [Android]
TYPE may be:
- [Added] for new features.
- [Changed] for changes in existing functionality.
- [Deprecated] for soon-to-be removed features.
- [Removed] for now removed features.
- [Fixed] for any bug fixes.
- [Security] in case of vulnerabilities.
For more detail, see https://keepachangelog.com/en/1.0.0/#how
MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.
EXAMPLES:
[General] [Added] - Add snapToOffsets prop to ScrollView component
[General] [Fixed] - Fix various issues in snapToInterval on ScrollView component
[iOS] [Fixed] - Fix crash in RCTImagePicker
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/22532
Differential Revision: D13373469
Pulled By: cpojer
fbshipit-source-id: ac140d14ce76e1664869437c2c178bdd65ab6e0e
Summary:
This may be controversial.
Right now, RelayPrefetcher is initialized [here](https://fburl.com/p01iunr1), after bridge is initialized. I want to create a FBRelayPrefetcherModule instance eagerly (diff 3 in stack), and then pass that into the bridge module registry. This way, native side gets to use RelayPrefetcher before bridge is init, and JS still accesses the same instance of FBRelayPrefetcherModule.
The only other option is drastically change bridge init, to allow passing in some eagerly initialized instances.
Reviewed By: shergin
Differential Revision: D13164277
fbshipit-source-id: b45111cd68d78820e61e4fca7e54a7e8df32a3f0
Summary:
Update reference to property in code comment in `RCTBridgeModule`. There is no such thing as `requiresMainThreadSetup` in the codebase. Its called `requiresMainQueueSetup` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22328
Differential Revision: D13115352
Pulled By: shergin
fbshipit-source-id: 511d627388b51029821c4b1ddf4caac30e573040
