Summary: Make sure that `importKeys` doesn't choke on null `map_`, since ReadableNativeMap can have a null backing `map_`.
Reviewed By: mdvacca
Differential Revision: D15360094
fbshipit-source-id: b507bdd93c247153aa34e4f62ac6f93349c1faf5
Summary: The existing implementation of JSCallInvoker holds a reference to Instance (aka the bridge). This diff makes JSCallInvoker an abstract base class that's extended by BridgeJSCallInvoker, which is what's returned by CatalystInstance to initialize TurboModules. This will allow us to add another class that derives from JSCallInvoker that doesn't rely on the bridge.
Reviewed By: shergin
Differential Revision: D15252375
fbshipit-source-id: 75eee2ca149235a63e2a2cd8cdd361b163d1d1ab
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary:
libreactnativejni does not need to link against libjsc directly:
that library is only needed by libjscexecutor.
Reviewed By: mhorowitz
Differential Revision: D15017942
fbshipit-source-id: fb545c9127221dab28434321fe9c116fe72f7507
Summary: Adding JNativeRunnable to exported headers in react/jni/BUCK so I can use it outside of CatalystInstance.
Reviewed By: axe-fb
Differential Revision: D14817655
fbshipit-source-id: 15aa794e50f273778da337956c887c235a5aec3d
Summary: Removes useArrayNativeAccessor and everything needed to support it, similar to D14486283
Reviewed By: mdvacca
Differential Revision: D14487244
fbshipit-source-id: 7cfa91f7cf322c648c82be5951f3622cd6468961
Summary:
This was quite a rabit hole of remove deps -> delete dead code -> repeat.
Waaay simpler now with less duplicate lookups, redundant type verification, and extra function calls.
Reviewed By: mdvacca
Differential Revision: D14486283
fbshipit-source-id: 035db30181755d046a1ae99760468b954b2449df
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
For most cases, people saw this error when they are running a debug version. So they should check metro server first. However, they were misled to search for "bundle" keywords and finally they executed "react-native bundle" command and got an app that can never reload.
Pull Request resolved: https://github.com/facebook/react-native/pull/17055
Differential Revision: D13421737
Pulled By: cpojer
fbshipit-source-id: 8e108df06b7d416a74c33581457f3213b28306c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/22231
- Use clang instead of the deprecated gcc
- Use libc++ instead of the deprecated gnustl
- Updated gradle and android plugin version
- Fixed missing arch in local-cli template
- `clean` task should now always succeed
- `clean` task deletes build artifacts
- No need to specify buildToolsVersion. It's derived.
- Elvis operator for more readable code
Pull Request resolved: https://github.com/facebook/react-native/pull/22263
Reviewed By: hramos
Differential Revision: D13004499
Pulled By: DanielZlotin
fbshipit-source-id: da54bb744cedb4c6f3bda590f8c25d0ad64086ef
Summary: In TurboModules, we need to call into WritableArray and ReadableArray interfaces, not their implementations. By adding these interfaces, we can invoke the corresponding Java classes directly.
Reviewed By: fkgozali
Differential Revision: D6981870
fbshipit-source-id: 12b12b204a7d38b24363452ab574d88b827c907f
Summary: In ReactNative, Native Modules usually use `ReadableMap` interface to take in arguments to methods, not `ReadableNativeMap`. Adding this interface defination to C++, so that with TurboModules, we could use it with `getMethod` definations.
Reviewed By: fkgozali
Differential Revision: D6721049
fbshipit-source-id: cb6e82d618338e54199c7dd066a846e71e742bc6
Summary: Remove `force_static=true` from cxxreact:bridge, add dependencies to targets that were pulling them in from a statically linked cxxreact:bridge.
Reviewed By: mhorowitz
Differential Revision: D12914861
fbshipit-source-id: ff335b70e80d014538a8d5dc8c0bb7b095e7940e
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary:
This diff includes a few changes:
1. Move the headers inside `jsiexecutor` into `jsiexecutor/jsireact`. As far as I'm aware, the Android ndk build system isn't flexible enough to support header namespaces, so we can't just expose the headers inside the `jsiexecutor` directory under the `jsireact` namespace. Therefore, I moved the headers to `jsiexecutor/jsireact`, and added `jsiexecutor` to the header search path. This was the easiest way to simulate `jsireact` namespace.
2. Setup the Android.mk files to get RNTester compiling and running.
3. Introduce a `jscexecutor` module to make `JSCExecutor.java` execute without throwing.
**Note:** Moving the header files inside `jsiexecutor` probably breaks the iOS builds and internal builds. I'll fix those in subsequent diffs on this stack.
Reviewed By: shergin
Differential Revision: D9995429
fbshipit-source-id: 418a4ee91f585842c5e317af2f300227a51e9ba8
Summary:
Removing entire files will be the next diff
@public
Reviewed By: fkgozali
Differential Revision: D9328239
fbshipit-source-id: 083847d3b841a3c7bfa751a82e8cc16bd112bace
Summary:
This removes the dependency on JSCExecutor. Everything goes
through JSI now.
Reviewed By: RSNara
Differential Revision: D9328240
fbshipit-source-id: c9c085fec1ebd5d0f4679cd70b89cc263ca33ac4
Summary:
If a folly::dynamic contains a double when a Java method is
declared to take an int, getInt() will be called, and a C++ exception
will be thrown. This change uses similar logic to
NativeReadableMap.getInt() to convert a folly::dynamic double to a
jint. This will still throw an exception if the JS value cannot be
represented as a jint without loss.
Reviewed By: fromcelticpark
Differential Revision: D10209492
fbshipit-source-id: fd96416200c6b283ce5c8f8fa4c227ceb8f43054
Summary:
Update several files to use the proper copyright header:
```
// Copyright (c) Facebook, Inc. and its affiliates.
//
// This source code is licensed under the MIT license found in the
// LICENSE file in the root directory of this source tree.
```
In the case of Xcode project files, I used the shortform version, `Copyright (c) Facebook, Inc. and its affiliates.`
Reviewed By: axe-fb
Differential Revision: D10114529
fbshipit-source-id: a1f2d5a46d04797c1cf281ea9ab80d3a2caa6fb4
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:
release method of local_ref and global_ref doesn't call deallocator, in fact, it leaves the caller responsible for deletion of the reference, while otherwise the reference is released on scope left.
Fixes#18292.
Pull Request resolved: https://github.com/facebook/react-native/pull/20913
Differential Revision: D9616237
Pulled By: hramos
fbshipit-source-id: 021aa3e4f039e6b7a98da3e4224c1ee49d5a4921
Summary:
Converting from double to int16_t is undefined behavior if the value
doesn't fit in int16_t.
Reviewed By: tmikov
Differential Revision: D8925246
fbshipit-source-id: 4cf57631686a4ce05546f8d30a46e3f9def3aee2
Summary:
Cleanup clang compiler warnings.
The last version delete some variables that still used in code.
Fix the problem and try to launch again.
Reviewed By: hershi
Differential Revision: D8704442
fbshipit-source-id: 8bd37fc9f2b27104fe15c4c8b8323e2bfd8c1060
Summary:
According to [ndk release notes](https://github.com/android-ndk/ndk/wiki/Changelog-r14-beta1#ndk-build) flag APP_ALLOW_MISSING_DEPS should be set to true in order to fix ndk-build tool.
If it builds it will work. On older ndk flag is ignored.
[ANDROID] [MINOR] [Application.mk] - build with android-ndk-14+ supported
Closes https://github.com/facebook/react-native/pull/18814
Differential Revision: D8643513
Pulled By: hramos
fbshipit-source-id: d96f8c039a754b9b95839f0a0bd98fcfdaf39bd4
Summary:
Adds `loadScriptFromDeltaBundle` / `jniLoadScriptFromDeltaBundle` methods to `CatalystInstanceImpl`.
These methods allow to run JS coming from a native delta client as RAM bundles, to leverage the RAM bundle mechanism for development / reload scenarios.
Reviewed By: fromcelticpark
Differential Revision: D7845140
fbshipit-source-id: b79b340f36c28939a31eb63a3c463d0792a208f7
Summary:
Adds hybrid JNI wrapper class that can hold a native delta client.
This class allows Java code in the `devsupport` package to hold onto a native delta client across reloads.
It also takes care of passing `okhttp` response objects to native code, where we build a `std::string` to hold JSON messages coming from Metro, and parse them with `folly::parseJson`.
In a follow-up, we will switch to a streaming-friendly binary format that will make allocating memory for the whole message unnecessary.
Reviewed By: fromcelticpark
Differential Revision: D7845138
fbshipit-source-id: 7a29b30645331addf843097dd0d05c03b3143991
Summary:
Adds C++ delta client that keeps modules in memory, and can be used as a RAM bundle.
For now, this client expects a `folly::dynamic` object as payload for patches, i.e. the JSON response retrieved from Metro needs to be parsed with `folly::parseJson` by the caller.
In the future, we will replace JSON with a streaming friendly binary format.
Reviewed By: fromcelticpark
Differential Revision: D7845136
fbshipit-source-id: f003f98a2607c8354c427a7e60e01e19e20295b1
Joshua Gross
Emily Janzer
Ramanpreet Nara
Will Holen
Spencer Ahrens
Yedidya Feldblum
Jonathan Kim
Matt Hargett
Sunny Luo
Ram N
Daniel Zlotin
David Vacca
Chris Tolliday
Tim Yung
Marc Horowitz
Héctor Ramos
Sergei Dryganets
Alex Dvornikov
Dulmandakh
Simon Jensen
Yuanda Tang
Taras Tsugrii
Oleksandr Sokolov
Dmitry Zakharov
David Aurelio
Riley Dulin
Michael Lee