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: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary:
Added a flag that checks if TurboModules are enabled, don't expose them to JS via the old module system.
All TurboModules needs to implement TurboModule interface.
Reviewed By: mdvacca
Differential Revision: D13648332
fbshipit-source-id: f22506fe029ac82d56075f5b6962ff2df2e7eaa4
Summary: ReadableNativeArray initializes the ReactBridge which loads a bunch of c++ classes. Let's avoid doing this on the UI thread.
Reviewed By: mdvacca
Differential Revision: D10108380
fbshipit-source-id: ab4520535288ce450a865952e996b716d571df7f
Summary: Back out D9614432 and partially revert D9623235 to unbreak OSS.
Reviewed By: hramos
Differential Revision: D9779548
fbshipit-source-id: 931c4987ed5acbae3790c42717662fed77599335
Summary: Reverting D9304307 and also adding CountEnum annotation to ReactMarkerConstants. This way we get the typesafety of the enum with the optimization of converting to int in production builds. More on the count: https://our.intern.facebook.com/intern/wiki/Android-java-transforms/the-count/
Reviewed By: achen1
Differential Revision: D9623235
fbshipit-source-id: ab992e7edb6cf999f5f122faee31075a63782411
Summary:
When circle is using Buck, it uses prebuilt native libraries. I added this dependency internally to avoid callers having to depend on it explicitly but it looks like that broken open-source.
Closes https://github.com/facebook/react-native/pull/14343
Differential Revision: D5191531
Pulled By: javache
fbshipit-source-id: 5397026daac085694b3320bf6d3e7b3f5d680691
Summary: This move lets us remove the dependency on okhttp3 from react/bridge. The classes I moved are all strictly related to dev support features and don't need to go into the core bridge module that gets shipped to production.
Reviewed By: AaaChiuuu
Differential Revision: D3698977
fbshipit-source-id: 6ba1517377061690cef289a544ec1622122cef85
Summary:
LazyReactPackage is an extension of ReactPackage that allows us to lazily construct native modules.
It's a separate class to avoid breaking existing packages both internally and in open source.
Reviewed By: astreet
Differential Revision: D3334258
fbshipit-source-id: e090e146adc4e8e156cae217689e2258ab9837aa
Summary:
Update to [OkHttp](https://github.com/square/okhttp) to [OkHttp3](https://publicobject.com/2015/12/12/com-squareup-okhttp3/)
We must also update:
- Fresco to 0.10.0
- okio to 1.8.0
**Motivation**
Reasons for upgrading:
* Issue #4021
* "We discovered that RN Android sometimes fails to connect to the latest stable version of NGINX when HTTP/2 is enabled. We aren't seeing errors with other HTTP clients so we think it's specific to RN and OkHttp. Square has fixed several HTTP/2 bugs over the past eight months." - ide
* OkHttp3 will be maintained & improved, but OkHttp2 will only receive [security fixes](https://publicobject.com/2016/02/11/okhttp-certificate-pinning-vulnerability/)
* Cleaner APIs - "Get and Set prefixes are avoided"
* Deprecated/Removed - HttpURLConnection & Apache HTTP
* React Native apps are currently being forced to bundle two versions of OkHttp (v2 & v3), if another library uses v3
* Improved WebSocket performance - [CHANGELOG.md](https://github.com/square/okhttp/blob/master
Closes https://github.com/facebook/react-native/pull/6113
Reviewed By: andreicoman11, lexs
Differential Revision: D3292375
Pulled By: bestander
fbshipit-source-id: 7c7043eaa2ea63f95854108b401c4066098d67f7
