Summary:
This diff adds nuance to timer creation. Imagine the following bit of JS:
```
setTimeout(() => {
console.log("Timeout")
}, 0);
setImmediate(() => {
setNine("Immediate");
});
```
In classic RN, `setTimeout` will be called async by the bridge, immediate is implemented in JS, so the ordering of logs will be:
1. Immediate
2. Timeout
In bridgeless RN `setTimeout` is called sync, so the ordering of the logs is:
1. Timeout
2. Immediate
In order to preserve ordering, this diff adds a timer creation method which doesn't immediately invoke it, but waits one frame to do so.
This PR does the same thing for android, and explains the reasoning for preserving behaviour (some products may rely on this behaviour) https://github.com/facebook/react-native/commit/f054928124a2308b2bd450acf8bb754a92ccb16a
Reviewed By: ejanzer
Differential Revision: D17535639
fbshipit-source-id: 3f734c420a6a95be2ee10e8d6ac48adc79ef1c96
Summary:
Instead of relying on the bridge to do module setup, allow for regular initialization.
Instead of relying on the bridge to execute timers, allow for a delegate to do the work.
Reviewed By: RSNara
Differential Revision: D17375924
fbshipit-source-id: 83adabf8c962a5d90a4ea623618903cd9fb79a99
Summary:
Fix a bug where `CACurrentMediaTime` was being used to calculate the elapsed frame time, even though it's not comparable to `NSDate.timeIntervalSince1970` time.
## Changelog
[iOS] [Fixed] - callIdleCallbacks deadline calculation
Pull Request resolved: https://github.com/facebook/react-native/pull/26114
Test Plan: None
Differential Revision: D17314125
Pulled By: cpojer
fbshipit-source-id: 5061a3954371df2134f0c77dc260228668abe747
Summary:
Related #23674, in that PR, we imported background timer support, but it's not sufficient, I think the reason that works is because it enable the `Background Modes` and do some background tasks, for the users who don't enable it, timer would pause immediately before goes into background.
To fix it, we can mark a background task when goes into background, it can keep app active for minutes, try best to support timing when in background.
cc. cpojer .
## Changelog
[iOS] [Fixed] - Timing: Fixes timer when app get into background
Pull Request resolved: https://github.com/facebook/react-native/pull/24649
Differential Revision: D15554451
Pulled By: cpojer
fbshipit-source-id: a33f7afe6b63d1a4fefcb7098459aee0c09145da
Summary:
This PR is a follow-up to #21211 by request of hramos to incorporate some additional crash fixes / synchronization edge cases found in our production testing. What follows is largely a copy of the original PR description from #21211 - see that PR for original discussion thread as well as context on why this replacement PR was needed.
This PR is a minimalistic change to RCTTiming that causes it to switch exclusively to NSTimer (i.e., the 'sleep timer') in order to continue triggering timers when the app has moved to the background.
Many people have expressed a desire for background timer support on iOS. (See #1282, #167, and #16493). In our app — a podcast/audio player — we use background timers to ensure that we never lose track of the user's playback position, should the app crash or be terminated by the OS.
The RCTTimer module uses a RN-managed CADisplayLink if the next requested timer is less than a second away; otherwise, it switches to an NSTimer (which is refers to as a 'sleep timer' in source). The RN-managed CADisplayLink is always disabled when the app goes to the background (and thus cannot be used); however, the NSTimer will still issue its callbacks in the background.
This PR adds a flag to track whether the app is in the background, and if so, all timers are routed through NSTimer until the app returns to the foreground. vishnevskiy at Discord opened a similar PR (#16493) that implements a drop-in for CADisplayLink which falls back to NSTimer, but I decided to incorporate the background-NSTimer logic directly into RCTTimer, since NSTimer is already in use.
It's worth noting that the background NSTimer may not fire as often as requested — it may give the appearance of lagging depending upon your app's priority in the background. For our audio app, NSTimer fires exactly on schedule if there's an open AVAudioSession and audio is playing; if audio is not playing, it fires about half as often as requested, which is still adequate for networking polling and other tasks.
It's worth noting that background timers only function as long as an app is actually running in the background. Apple offers a variety of Background Modes (which can be toggled in the Capabilities section of the target inspector in Xcode), and the app will need to be legitimately using one of these modes in order for this change to provide any value — otherwise it will be terminated within a couple of seconds of moving to the background.
The good thing about this change is that for apps that do perform essential computation in support of their Background Mode, they can now use `setTimeout` and `setInterval` without problem — whereas in the past, neither would ever trigger their callback until the app returns to the foreground.
Pull Request resolved: https://github.com/facebook/react-native/pull/23674
Differential Revision: D14621326
Pulled By: shergin
fbshipit-source-id: c76e060ad2c662c140d7d2f4fb5aaa7094032515
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
As per javache comments in #8734.
Also removes now useless feature detection check.
**Test plan**
Tested that rIC still works in UIExplorer example.
Closes https://github.com/facebook/react-native/pull/8795
Differential Revision: D3572566
Pulled By: javache
fbshipit-source-id: 261d13d8b03898313f8b4184d634c70f81a61b62
Summary:
iOS follow up to #8569. This currently depends on the Android PR since it contains the JS implementation, only review the last commit. Just putting this out here for visibility, don't merge this before the Android PR.
**Test plan**
Tested by running a background task that burns all remaining idle time (see UIExplorer example).
Tested that native only calls into JS when there are pending idle callbacks.
Tested that timers are executed before idle callback.
Closes https://github.com/facebook/react-native/pull/8734
Differential Revision: D3560818
fbshipit-source-id: a28d3092377a7fd4331647148d40fe69e4198c7e
Summary:
By default we run the the JS display link, even if there are no modules listening. Given that most listeners will be lazily constructed, let's make it paused by default.
Since RCTTiming almost never unpauses due to some long-lived timers, implement a sleep timer that pauses the displaylink but uses an NSTimer to wake up in time.
Reviewed By: mhorowitz
Differential Revision: D3235044
fbshipit-source-id: 4a340fea552ada1bd8bc0d83b596a7df6f992387
Summary:This commit modifies the jsSchedulingOverhead warning to only fire if the JS clock is more than 5 seconds ahead of the native clock. This fixes the issue in #1598 for the common case when there's only a minor difference between the two clocks, while still keeping a sanity check if they're extremely off.
cc nicklockwood tadeuzagallo
Closes https://github.com/facebook/react-native/pull/5731
Differential Revision: D3014985
Pulled By: tadeuzagallo
fb-gh-sync-id: bf57e48b7d97ad02d2aefb6e5aac845824a6fdb0
shipit-source-id: bf57e48b7d97ad02d2aefb6e5aac845824a6fdb0
Summary:
public
A lot of the core modules have to use private methods in the bridge, specially
since the `RCTBatchedBridge` interface is never exposed. That was leading to a
lot of different private bridge categories spread across different modules,
which makes harder to identify which modules are affected by private API changes.
Replace all the categories with a single private header.
Reviewed By: nicklockwood
Differential Revision: D2757564
fb-gh-sync-id: 793158b9082d542b74a6094ed0db4d5dc3a88f78
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary:
The bridge implementation on React Android does not currently support boxed numeric/boolean types (the equivalent of NSNumber arguments on iOS), nor does Java support Objective-C's nil messaging system that transparently casts nil to zero, false, etc for primitive types.
To avoid platform incompatibilities, we now treat all primitive arguments as non-nullable rather than silently converting NSNull -> nil -> 0/false.
We also now enforce that NSNumber * objects must be explicitly marked as `nonnull` (this restriction may be lifted in future if/when Android supports boxed numbers).
Other object types are still assumed to be nullable unless specifically annotated with `nonnull`.
Summary:
@public
This removes the last piece of data that was still stored on the DATA section,
`RCT_IMPORT_METHOD`. JS calls now dynamically populate a lookup table simultaneously
on JS and Native, instead of creating a mapping at load time.
Test Plan: Everything still runs, tests are green.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
`-[RCTJavaScriptExecutor executeBlockOnJavaScriptQueue:]` would always `dispatch_async`
for the WebView and WebSocket executors, what caused for any frame aligned dispatch.
Test Plan:
Test the `Timers, TimerMixin` example on UIExplorer, `requestAnimationFrame` was
taking ~33.3ms when debugging, now takes ~16.6ms as expected.
Summary:
@public
`RCTDispatchEvent` and `RCTTiming` weren't being paused when there wasn't any
work left to be done.
Test Plan:
Run the timers example - check everything still works as expected
Test the ListView paging example - check scroll events are still fired as expected
Launch UIExplorer, let it idle, and put a break point on `-[RCTBridge dispatchBlock:moduleID:]`,
it should never fire.
Peter Argany
Alec Larson
Alex Cohen
zhongwuzw
cojo
Héctor Ramos
Sophie Alpert
Pieter De Baets
makee
Janic Duplessis
Kyle Corbitt
Tadeu Zagallo
Nick Lockwood
Alexey Lang
Alex Akers