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 33573511f0.
- 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
Summary:
These helper functions will be used by the ObjC generated code for support on commands.
This is an example of what that code might look like and how these functions will be used.
```
- (void)handleCommand:(NSString const *)commandName args:(NSArray const *)args
{
if ([commandName isEqualToString:@"scrollTo"]) {
if ([args count] != 2) {
RCTLogError(
@"%@ command %@ received %d arguments, expected %d.", @"ScrollView", @"scrollTo", (int)[args count], 2);
return;
}
NSObject *arg0 = args[0];
if (!RCTValidateTypeOfViewCommandArgument(arg0, [NSNumber class], @"number", @"ScrollView", @"scrollTo", @"1st")) {
return;
}
int x = [(NSNumber *)arg0 intValue];
NSObject *arg1 = args[1];
if (!RCTValidateTypeOfViewCommandArgument(arg1, [NSNumber class], @"number", @"ScrollView", @"scrollTo", @"2nd")) {
return;
}
int y = [(NSNumber *)arg1 intValue];
[self scrollTo:x y:y];
} else if ([commandName isEqualToString:@"scrollToEnd"]) {
if ([args count] != 0) {
RCTLogError(
@"%@ command %@ received %d arguments, expected %d.", @"ScrollView", @"scrollToEnd", (int)[args count], 0);
return;
}
[self scrollToEnd];
}
}
```
Reviewed By: JoshuaGross
Differential Revision: D16474117
fbshipit-source-id: 2bb9f01d7c97cc59e9373b7759021c65980fcc0e
Summary: We no longer want to access RCTImageLoader from the bridge category. Instead, let's use the `moduleForClass` API.
Reviewed By: shergin
Differential Revision: D16389113
fbshipit-source-id: c638f4b9851698afc53aaaa2b302d21cc19f76e7
Summary:
Adding viewIsDescendantOf back again, more context 9ae7f0c7da
This method might no not be implemented in Fabric
Reviewed By: fkgozali
Differential Revision: D16186406
fbshipit-source-id: 9cd4c9e20c01713d4e8608a54c6f54082067e27f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25416
Use CocoaPods-based RNTesterPods workspace to run iOS unit tests and integration tests.
This is necessary as new iOS projects now use CocoaPods by default. CocoaPods also powers the new package auto-linking feature.
In order to provide test coverage for this new default configuration, our iOS tests are being migrated to use a CocoaPods-managed RNTester workspace. This applies to both Circle CI, and Sandcastle.
Changelog:
[iOS] [Changed] - Use RNTesterPods for iOS Tests
Reviewed By: fkgozali
Differential Revision: D16052466
fbshipit-source-id: 724b0c51008882d3c06a9074693fe23e74abe86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25416
Use CocoaPods-based RNTesterPods workspace to run iOS unit tests and integration tests.
This is necessary as new iOS projects now use CocoaPods by default. CocoaPods also powers the new package auto-linking feature.
In order to provide test coverage for this new default configuration, our iOS tests are being migrated to use a CocoaPods-managed RNTester workspace. This applies to both Circle CI, and Sandcastle.
Reviewed By: fkgozali
Differential Revision: D15958209
fbshipit-source-id: b51fb907812cb2d4d78cce445d39bc253ae5acf8
Summary:
Fix Issue https://github.com/facebook/react-native/issues/24820
It's caused by `_labelsForTags` and `RCTPLTag` being out of sync, the crash might only be one of the issues that this bug was causing.
## Changelog
[iOS] [Fixed] - fix crash on performance logger
Pull Request resolved: https://github.com/facebook/react-native/pull/24821
Differential Revision: D15407291
Pulled By: PeteTheHeat
fbshipit-source-id: c8d2a047fceb9cec981c48fe5181d1b4cbf0976c
Summary:
The `testBundleURL` test was disabled in open source recently due to issues running it successfully in Facebook's internal CI. We're now skipping `RCTBundleURLProviderTests` tests internally, so it's safe to re-enable now and ensure it runs in Circle CI.
Changelog:
[iOS] [Changed] - Re-enable testBundleURL unit test.
Reviewed By: cpojer
Differential Revision: D15140192
fbshipit-source-id: 5f6a91f3ce8cea245be31dff3ffb86768deab0be
Summary:
This test was disabled in e106112202 to allow unit tests to run on Facebook's internal CI. The change was reverted in 1f6de88230 because another internal test was broken when it found that mainBundleURL() was not getting called.
In this commit, I've commented out the actual piece of code that would cause unit tests to fail in Facebook's internal CI, without removing the call to mainBundleURL(). The localhostBundleURL() method is called elsewhere in the file, so commenting it out here should not cause any issues.
Changelog:
[iOS] [Changed] - Disable testBundleURL test.
Reviewed By: cpojer
Differential Revision: D15049238
fbshipit-source-id: da3a393922f2190b423980cac5ab54df5e7e3e41
Summary:
Bumps to Xcode 10.2.0 and uses the iOS 12.2 simulator when running tests.
The `testBundleURL` test is temporarily disabled to allow the iOS unit tests to run successfully in the internal Facebook CI system.
Changelog:
[iOS] [Changed] - iOS tests: Bump Xcode to 10.2.0, iOS to 12.2.
Reviewed By: TheSavior
Differential Revision: D14962710
fbshipit-source-id: 769cfb90aacce33903ab6e8dbcc5b5727deacf41
Summary:
`[RCTBridge setUp]` and `[RCTBridge invalidate]` execute asynchronously and concurrently. Therefore, it's not safe to call one method after the other, as we do in `[RCTBridge reload]`.
In this test, we create a bridge, and immediately reload it. Initializing the bridge causes the JS bundle to execute. Invalidating the bridge causes the jsThread to be terminated. If circumstances are correct, we could end up trying to executing the JS bundle after the jsThread has been terminated, which can lead to these assertions being triggered:
1. `RCTAssert(_jsThread, @"This method must not be called before the JS thread is created");` in `ensureOnJavaScriptThread:`.
2. `RCTAssert(_jsMessageThread != nullptr, @"Cannot invoke completion without jsMessageThread");` in `enqueueApplicationScript:url:onComplete:`.
```
- (void)testUnderlyingBridgeIsDeallocated
{
RCTBridge *bridge;
__weak id batchedBridge;
autoreleasepool {
bridge = [[RCTBridge alloc] initWithBundleURL:_bundleURL moduleProvider:nil launchOptions:nil];
batchedBridge = bridge.batchedBridge;
XCTAssertTrue([batchedBridge isValid], @"RCTBridge impl should be valid");
[bridge reload];
}
RCT_RUN_RUNLOOP_WHILE(batchedBridge != nil)
XCTAssertNotNil(bridge, @"RCTBridge should not have been deallocated");
XCTAssertNil(batchedBridge, @"RCTBridge impl should have been deallocated");
// Wait to complete the test until the new bridge impl is also deallocated
autoreleasepool {
batchedBridge = bridge.batchedBridge;
[bridge invalidate];
bridge = nil;
}
RCT_RUN_RUNLOOP_WHILE(batchedBridge != nil);
XCTAssertNil(batchedBridge);
}
```
To verify that this race is real, patch: P62410422. This adds an artificial delay in the `[RCTCxxBridge start]` method, which makes it so that the bridge is invalidated and the js thread is destroyed before we start executing the jsBundle.
I think a proper solution to this problem would require some bit of restructuring of `[RCTCxxBridge invalidate]` and `[RCTCxxBridge start]` to either:
1. Force `[RCTCxxBridge invalidate]` to wait for `[RCTCxxBridge start]` to complete and vice versa.
2. Make it safe to interleave execution of `[RCTCxxBridge start]` and `[RCTCxxBridge invalidate]`.
I tried the first approach using two semaphores: `_startSem(1)` and `_invalidateSem(0)`. When you start executing the code inside `[RCTCxxBridge start]`, you `semWait(_startSem)`. When you stop executing the code inside `[RCTCxxBridge start]` (which could happen in another thread at some later point in time), you `semSignal(_invalidateSem)`. Likewise, when you start executing `[RCTCxxBridge invalidate]`, you `semWait(_invalidateSem)` and when you stop executing the code inside `[RCTCxxBridge invalidate]` you `semSignal(_startSem)`. This way, invalidates always wait for starts to finish, and starts always wait for invalidates to finish. But considering all the concurrency involved in these methods, this is hard to get right.
The second approach seems possible. You could keep locks for the shared data, and create critical sections whever you want to access that data. I didn't actually try to implement this approach though.
Given that we're going to elminate the Bridge anyway, and that this race condition practically only occurs when you reload imediately after initializing the bridge (which can only really be done programmatically), I think it's fine to just disable the test for now. One other thing I considered was making the current thread sleep for some time after we created the bridge in the test. The reason why I'm hesitant to implement this approach is that it would slow down the execution of the test suite and still wouldn't guarantee that we don't hit this race condition. Ultimately, our infra might end up disabling these tests again.
Reviewed By: shergin
Differential Revision: D14909121
fbshipit-source-id: d7d441c3e2f0ad59182c8c7e23740be4ac4cf83c
Summary: Just a little more rigorous
Reviewed By: shergin
Differential Revision: D14790912
fbshipit-source-id: 0a4c9b6ea68466efb060c9c90572ff8987fdbd26
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:
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:
Not super clean, but not terrible.
Unfortunately this still relies on the old Paper UIManager calling delegate methods to flush the operations queues. This will work for Marketplace You since Paper will be active, but we need to fix this, along with Animated Events which don't work at all yet.
Random aside: it seems like taps are less responsive in fabric vs. paper, at least on iOS. There is a sporadic delay between the touches event coming in nativly to the JS callback invoking the native module function to start the animation - this will need some debugging.
Reviewed By: shergin
Differential Revision: D14143331
fbshipit-source-id: 63a17eaafa1217d77a532a2716d9f886a96fae59
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:
Fixes lots of ESLint warnings. Many of them where in PR #20877 by janicduplessis which requested to split the linting fixes from configuration and package changes.
I solved only the issues that I was most certain about but I would love to get hands on all of them with a little bit of input.
Pull Request resolved: https://github.com/facebook/react-native/pull/22062
Differential Revision: D12889447
Pulled By: TheSavior
fbshipit-source-id: 35f7a08104a5b859c860afdde4af2b32c0685c50
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: Moving target deployment to iOS 9.0+ from now on, removing customization for iOS 8.
Reviewed By: shergin
Differential Revision: D8053439
fbshipit-source-id: 292c58f15c6e6caf8b28d15c1521812d6ed675c5
Summary:
`RCTFontTests` test in RNTester is broken if the target deployment is <= OS 8.2. This is because RCTFont.mm overrides the OS-defined values, but the override is only visible to RCTFont.mm internals. As the result, when the Unit test tries to create UIFont of the "same" weight, it got a different font - most likely due to internal floating rounding errors.
To mitigate, code that wants to test out internals of RCTFont should import RCTFontConstantsOverride.h
Reviewed By: mmmulani
Differential Revision: D7900954
fbshipit-source-id: e5814ef059a8afdfb5205ca1af46c41b3cfd4318
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
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:
This PR adds support for Animated tracking to Animated Native Driver implementation on Android and iOS.
Animated tracking allows for animation to be started with a "dynamic" end value. Instead of passing a fixed number as end value we can pass a reference to another Animated.Value. Then when that value changes, the animation will be reconfigured to drive the animation to the new destination point. What is important is that animation will keep its state in the process of updating "toValue". That is if it is a spring animation and the end value changes while the previous animation still hasn't settled the new animation will start from the current position and will inherit current velocity. This makes end value transitions very smooth.
Animated tracking is available in JS implementation of Animated library but not in the native implementation. Therefore until now, it wasn't possible to utilize native driver when using animated tracking. Offloading animation from JS thread turns out to be crucial for gesture driven animations. This PR is a step forward towards feature parity between JS and native implementations of Animated.
Here is a link to example video that shows how tracking can be used to implement chat heads effect: https://twitter.com/kzzzf/status/958362032650244101
In addition this PR fixes an issue with frames animation driver on Android that because of rounding issues was taking one extra frame to start. Because of that change I had to update a number of Android unit tests that were relying on that behavior and running that one additional animation step prior to performing checks.
As a part of this PR I'm adding three unit tests for each of the platforms that verifies most important aspects of this implementation. Please refer to the code and look at the test cases top level comments to learn what they do.
I'm also adding a section to "Native Animated Example" screen in RNTester app that provides a test case for tracking. In the example we have blue square that fallows the red line drawn on screen. Line uses Animated.Value for it's position while square is connected via tracking spring animation to that value. So it is ought to follow the line. When user taps in the area surrounding the button new position for the red line is selected at random and the value updates. Then we can watch blue screen animate to that position.
You can also refer to this video that I use to demonstrate how tracking can be linked with native gesture events using react-native-gesture-handler lib: https://twitter.com/kzzzf/status/958362032650244101
[GENERAL][FEATURE][Native Animated] - Added support for animated tracking to native driver. Now you can use `useNativeDriver` flag with animations that track other Animated.Values
Closes https://github.com/facebook/react-native/pull/17896
Differential Revision: D6974170
Pulled By: hramos
fbshipit-source-id: 50e918b36ee10f80c1deb866c955661d4cc2619b
Summary:
This is reimagining of interoperability layer between Yoga and ShadowViews (at least in Yoga -> RN part).
Goals:
* Make it clear and easy.
* Make clear separation between "what layout what", now parent always layout children, noone layout itself.
* Make possible to interleave Yoga layout with custom imperative layout (may be used in SafeAreaView, Text, Modal, InputAccessoryView and so on).
Reviewed By: mmmulani
Differential Revision: D6863654
fbshipit-source-id: 5a6a933874f121d46f744aab99a31ae42ddd4a1b
Summary:
I've talked to several major community users, and they're all ok with deleting this
code. There's several doc fixes which will make it easier for third
party developers which should land about the same time this will.
Also buried along with it is RCTJSCExecutor.
Reviewed By: javache
Differential Revision: D6880781
fbshipit-source-id: b4cb1143def6fd23a96290e478fa728adbedacd3
Summary:
This PR is a followup to https://github.com/facebook/react-native/pull/11417 and should be merged after that one is merged.
1. Add support for creating blobs from strings, not just other blobs
1. Add the `File` constructor which is a superset of `Blob`
1. Add the `FileReader` API which can be used to read blobs as strings or data url (base64)
1. Add support for uploading and downloading blobs via `XMLHttpRequest` and `fetch`
1. Add ability to download local files on Android so you can do `fetch(uri).then(res => res.blob())` to get a blob for a local file (iOS already supported this)
1. Clone the repo https://github.com/expo/react-native-blob-test
1. Change the `package.json` and update `react-native` dependency to point to this branch, then run `npm install`
1. Run the `server.js` file with `node server.js`
1. Open the `index.common.js` file and replace `localhost` with your computer's IP address
1. Start the packager with `yarn start` and run the app on your device
If everything went well, all tests should pass, and you should see a screen like this:
!
Pull to rerun all tests or tap on specific test to re-run it
[GENERAL] [FEATURE] [Blob] - Implement blob support for XMLHttpRequest
Closes https://github.com/facebook/react-native/pull/11573
Reviewed By: shergin
Differential Revision: D6082054
Pulled By: hramos
fbshipit-source-id: cc9c174fdefdfaf6e5d9fd7b300120a01a50e8c1
Summary:
As I was working on mimicking iOS animations for my ongoing work with `react-navigation`, one task I had was to match the "push from right" animation that is common in UINavigationController.
I was able to grab the exact animation values for this animation with some LLDB magic, and found that the screen is animated using a `CASpringAnimation` with the parameters:
- stiffness: 1000
- damping: 500
- mass: 3
After spending a considerable amount of time attempting to replicate the spring created with these values by CASpringAnimation by specifying values for tension and friction in the current `Animated.spring` implementation, I was unable to come up with mathematically equivalent values that could replicate the spring _exactly_.
After doing some research, I ended up disassembling the QuartzCore framework, reading the assembly, and determined that Apple's implementation of `CASpringAnimation` does not use an integrated, numerical animation model as we do in Animated.spring, but instead solved for the closed form of the equations that govern damped harmonic oscillation (the differential equations themselves are [here](https://en.wikipedia.org/wiki/Harmonic_oscillator#Damped_harmonic_oscillator), and a paper describing the math to arrive at the closed-form solution to the second-order ODE that describes the DHO is [here](http://planetmath.org/sites/default/files/texpdf/39745.pdf)).
Though we can get the currently implemented RK4 integration close by tweaking some values, it is, the current model is at it's core, an approximation. It seemed that if I wanted to implement the `CASpringAnimation` behavior _exactly_, I needed to implement the analytical model (as is implemented in `CASpringAnimation`) in `Animated`.
We add three new optional parameters to `Animated.spring` (to both the JS and native implementations):
- `stiffness`, a value describing the spring's stiffness coefficient
- `damping`, a value defining how the spring's motion should be damped due to the forces of friction (technically called the _viscous damping coefficient_).
- `mass`, a value describing the mass of the object attached to the end of the simulated spring
Just like if a developer were to specify `bounciness`/`speed` and `tension`/`friction` in the same config, specifying any of these new parameters while also specifying the aforementioned config values will cause an error to be thrown.
~Defaults for `Animated.spring` across all three implementations (JS/iOS/Android) stay the same, so this is intended to be *a non-breaking change*.~
~If `stiffness`, `damping`, or `mass` are provided in the config, we switch to animating the spring with the new damped harmonic oscillator model (`DHO` as described in the code).~
We replace the old RK4 integration implementation with our new analytic implementation. Tension/friction nicely correspond directly to stiffness/damping with the mass of the spring locked at 1. This is intended to be *a non-breaking change*, but there may be very slight differences in people's springs (maybe not even noticeable to the naked eye), given the fact that this implementation is more accurate.
The DHO animation algorithm will calculate the _position_ of the spring at time _t_ explicitly and in an analytical fashion, and use this calculation to update the animation's value. It will also analytically calculate the velocity at time _t_, so as to allow animated value tracking to continue to work as expected.
Also, docs have been updated to cover the new configuration options (and also I added docs for Animated configuration options that were missing, such as `restDisplacementThreshold`, etc).
Run tests. Run "Animated Gratuitous App" and "NativeAnimation" example in RNTester.
Closes https://github.com/facebook/react-native/pull/15322
Differential Revision: D5794791
Pulled By: hramos
fbshipit-source-id: 58ed9e134a097e321c85c417a142576f6a8952f8
Summary:
We have to have a way to track ownership of shadow view.
Previous solution with traversing the hierarchy to figure out the root view does not actually work in some cases when the view is temporary detached from hierarchy.
This is also how it work on Andorid.
Reviewed By: mmmulani
Differential Revision: D5686112
fbshipit-source-id: a23a10e8c29c7572ac69403289db136c9d5176a9
Summary:
This shows progress for the download of the JS bundle (different from the packager transform progress that we show already). This is useful especially when loading the JS bundle from a remote source or when developing on device (on simulator + localhost it pretty much just downloads instantly). This will be nice for the expo client since all bundles are loaded over the network and can take several seconds to load.
This depends on https://github.com/facebook/metro-bundler/pull/28 to work but won't crash or anything without it, it just won't show the progress percentage.
**Test plan**
Tested that bundle download progress is shown properly in RNTester on both localhost + simulator and on real device with network conditionner to simulate a slow loading bundle.
Tested that it doesn't cause issues if the packager doesn't send the Content-Length header.
Closes https://github.com/facebook/react-native/pull/15066
Differential Revision: D5449073
Pulled By: shergin
fbshipit-source-id: 43a8fb559393bbdc04f77916500e21898695bac5
Summary:
Follow up to #11973 to add support to Animated.loop with useNativeDriver on iOS.
**Test plan**
Test with new UIExplorer example
Run unit tests
Closes https://github.com/facebook/react-native/pull/13359
Differential Revision: D4960754
Pulled By: javache
fbshipit-source-id: caa840281f1b060df7a2b1c50405fcae1e1b0de6
Andres Suarez
James Treanor
Eli White
Min ho Kim
Peter Argany
David Vacca
Héctor Ramos
Daryl Johnas Sison
Kyle Fang
Diego Sanchez
Ramanpreet Nara
Spencer Ahrens
Janic Duplessis
ericlewis
Håvard Fossli
Alex Dvornikov
Ignacio Olaciregui
Marc Horowitz
Kevin Gozali
Rubén Norte
Sophie Alpert
Krzysztof Magiera
Valentin Shergin
Satyajit Sahoo
Yujie Liu
Gustavo Gard
Aditya Kumar
Adam Miskiewicz
Janic Duplessis
Pieter De Baets
