Summary:
👋 Hello! Thanks for react-native, it’s a great project.
I was digging into the Android implementation in _ReactAndroid_ and noticed a couple typos in the documentation. I went through and tried to fix all the typos I could find using [aspell](http://aspell.net).
Not applicable: these changes are only to comments, and CI should be skipped.
[ANDROID][ENHANCEMENT][*] - Correct comment and docblock typos
Closes https://github.com/facebook/react-native/pull/17049
Differential Revision: D6472182
Pulled By: shergin
fbshipit-source-id: 7e62cab118609596b483d1cf16c3abf651d6753b
Summary: It's now unnecessary to declare which JS modules you want to expose on your package. To upgrade, remove all overrides of `createJSModules` and keeping calling your JS modules as before.
Reviewed By: AaaChiuuu
Differential Revision: D5229259
fbshipit-source-id: 1160826c951433722f1fe0421c1200883ba1a348
Summary: View tags are currently used for end-to-end test IDs. We'd like to overload the tag field with other information such as nativeID (for native refs) and transitionID (for shared element transitions) in the future. Added a key for testID's tag
Reviewed By: AaaChiuuu
Differential Revision: D4833045
fbshipit-source-id: c2f9371c9a3dbb2411e114f4f096f723ac3132c0
Summary: View tags are currently used for end-to-end test IDs. We'd like to overload the tag field with other information such as nativeID (for native refs) and transitionID (for shared element transitions) in the future. Added a key for testID's tag
Reviewed By: AaaChiuuu
Differential Revision: D4770368
fbshipit-source-id: b76c53a20520aac1b25d435b6d5eb809e8833675
Summary: Initializing natives modules on the UI thread blocks the JS thread if the UI thread is busy.
Reviewed By: yungsters
Differential Revision: D4611211
fbshipit-source-id: cd4fb9cb5e52a478b6692b784cfd9e3bf34c0d34
Summary:
At times, ReactPackage needs to get information from the ReactInstanceManager, e.g. to get the DevSupportManager for debugging purpose. This allows passing down the instance manager to create the native modules, in addition to just ReactApplicationContext. It is then up to the Package to use it or not.
To use this, you must make your package class extends ReactInstancePackage, instead of just implementing ReactPackage interface.
Reviewed By: mmmulani
Differential Revision: D4641997
fbshipit-source-id: 497c4408a7d2b773c49f08bff7c1bf8f9d372edb
Summary:
Android API 15 still have 1.5~2.0% distribution (refer: [Dashboard - Android Developer](https://developer.android.com/ndk/guides/standalone_toolchain.html#creating_the_toolchain)).
React Native is a good tec but many companies cannot endure loose their consumer. [Choreographer](https://developer.android.com/reference/android/view/Choreographer.html) triggered UI operation is the only reason that React Native Android sdk use minSdkVersion 16, so we can use a backward solution **only in API 15**: [Handler](https://developer.android.com/reference/android/os/Handler.html).
In this PR, the biggest change is :
- Make core operation of ReactChoreographer to an interface: ReactUIDriver;
- Impl ReactUIDriver by Handler => UIDriverHandlerImpl, refactor ReactChoreographer to UIDriverChoreographerImpl;
- Let UIDriverFactory to choose which one impl would be in use. (Only use handler in api 15).
Closes https://github.com/facebook/react-native/pull/12396
Reviewed By: AaaChiuuu
Differential Revision: D4588399
Pulled By: astreet
fbshipit-source-id: 76408e53664314dd926e6a553cde6bafbd37779e
Summary:
cc astreet
The goal of this PR is to enable the buck module `uimanager` to depend on `modules/core` without introducing any dependency cycles.
PR #11008 relies on this PR. PR #11008 needs `uimanager` to depend on `modules/core` so that `uimanager` can fire events using `RCTDeviceEventEmitter` which is in `modules/core`.
This PR moved a number of classes and interfaces:
- `com.facebook.react.modules.debug.DeveloperSettings` -> `com.facebook.react.modules.debug.interfaces.DeveloperSettings`
- `com.facebook.react.devsupport.DevOptionHandler` -> `com.facebook.react.devsupport.interfaces.DevOptionHandler `
- `com.facebook.react.devsupport.DevSupportManager` -> `com.facebook.react.devsupport.interfaces.DevSupportManager`
- `com.facebook.react.devsupport.DevServerHelper.PackagerStatusCallback` -> `com.facebook.react.devsupport.interfaces.PackagerStatusCallback`
- The class `com.facebook.react.devsupport.StackTraceHelper.StackFrame` was renamed to `StackFram
Closes https://github.com/facebook/react-native/pull/12329
Differential Revision: D4551160
Pulled By: astreet
fbshipit-source-id: 3a78443c4f30469b13ddfbdcc9bbef6af9e8381a
Summary:
"com.facebook.react.ReactPackage" is imported twice so fixed it to once.
Closes https://github.com/facebook/react-native/pull/11165
Differential Revision: D4236961
Pulled By: mkonicek
fbshipit-source-id: 84765dd9f8731b978972959f3825bf3c9c0684e3
Summary: Utilizes the build time annotation processor ReactModuleSpecProcessor that creates ReactModuleInfos for modules annotated with ReactModule and listed in the ReactModuleList annotation of LazyReactPackages. This way we don't have to instantiate the native modules to get the name, canOverrideExistingModule, and supportsWebWorkers values of the native modules. In the NativeModuleRegistry, we either store these ReactModuleInfos inside of a ModuleHolder or if we can't get the ReactModuleInfo for a specific module we instantiate that module to get the values (as we previously did) to store in a LegacyModuleInfo.
Reviewed By: astreet
Differential Revision: D3796561
fbshipit-source-id: f8fb9b4993f59b51ce595eb2f2c3425129b28ce5
Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
Summary:
This should revert back to using old bridge by default until we fix gradle script to build new bridge for OSS correctly
Closes https://github.com/facebook/react-native/pull/8539
Differential Revision: D3514263
Pulled By: bestander
fbshipit-source-id: db9e0232b9bde27206814212dedc487c366e3511
Summary:
Currently, DevTools only work under ios (although this is undocumented!),
because the JavaScriptEngine initialization process skips setupDevTools() on
android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using
Nuclide's inspector.
For reference, the relevant issue on react-devtools.
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: bestander
Differential Revision: D3492788
Pulled By: andreicoman11
fbshipit-source-id: 1eda9196d7125da19a8d7baaab22b61b744ca629
Summary:
Currently, DevTools only work under ios (although this is undocumented!), because the JavaScriptEngine initialization process skips setupDevTools() on android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using Nuclide's inspector.
For reference, [the relevant issue on react-devtools](https://github.com/facebook/react-devtools/issues/229).
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: javache
Differential Revision: D3443980
Pulled By: bestander
fbshipit-source-id: ce0f7dd62ae0f7dfe6654380821660f8660318a6
Summary:
Currently, DevTools only work under ios (although this is undocumented!), because the JavaScriptEngine initialization process skips setupDevTools() on android.
DevTools work fine with Android, as tested on 0.26, 0.27, and 0.28 using Nuclide's inspector.
For reference, [the relevant issue on react-devtools](https://github.com/facebook/react-devtools/issues/229).
Closes https://github.com/facebook/react-native/pull/8095
Reviewed By: javache
Differential Revision: D3443980
Pulled By: andreicoman11
fbshipit-source-id: 3d7b2e83cf4158a1228d2e21510509ab63411a5d