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: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
NSMutableURLRequest appears to be running `[headerValue count]` on every value of the NSDictionary that `allHTTPHeaderFields` is set to, meaning that any `null` values passed to headers in an XHR throw an exception. This differs from the implementation of XHR in browsers, which just ignore any `null` values for headers.
PR doesn't currently include tests, happy to add those if this is something you'd consider merging
Closes https://github.com/facebook/react-native/pull/6903
Differential Revision: D3256727
fb-gh-sync-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
fbshipit-source-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
Summary:Currently React-Native does not have `ontimeout` and `onerror` handlers for [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest). This is an extension to [No timeout on XMLHttpRequest](https://github.com/facebook/react-native/issues/4648).
With addition to two handlers, both Android and iOS can now handle `ontimeout` if request times out and `onerror` when there is general network error.
**Test plan**
Code has been tested on both Android and iOS with [Charles](https://www.charlesproxy.com/) by setting a breakpoint on the request which fires `ontimeout` when the request waits beyond `timeout` time and `onerror` when there is network error.
**Usage**
JavaScript -
```
var request = new XMLHttpRequest();
function onLoad() {
console.log(request.status);
};
function onTimeout() {
console.log('Timeout');
};
function onError() {
console.log('General network error');
};
request.onload = onLoad;
request.ontimeout = onTimeout;
request.onerr
Closes https://github.com/facebook/react-native/pull/6841
Differential Revision: D3178859
Pulled By: lexs
fb-gh-sync-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
fbshipit-source-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:
Introduced in a major lazy loading refactoring: 060664fd3d.
This is especially an issue when aborting a long-lived HTTP connection used as a notification channel, as it will use 1 of the maximum 4 connections per host (default limit defined by iOS' NSURLSession).
Closes https://github.com/facebook/react-native/pull/5782
Reviewed By: svcscm
Differential Revision: D2907600
Pulled By: nicklockwood
fb-gh-sync-id: 8406a045904a7ddb61fe1539a0474ec27b5e9e37
Summary:
Opening this in a separate PR but the discussion can be viewed on #4832.
Basically, this is a native implementation and is a bit more elegant. The consensus on my previous PR was that it should be done natively rather than in JS.
There's now no maximum valid timeout value and a timeout of 0 will never time out.
ontimeout isn't implemented (yet) in this PR.
cc nicklockwood ide philikon
Closes https://github.com/facebook/react-native/pull/5038
Reviewed By: svcscm
Differential Revision: D2838743
Pulled By: nicklockwood
fb-gh-sync-id: 774f864ac35082bf522f7665f4311bd3affbe82c
Summary:
An HTTP request may be redirected to another URL, sometimes we need to know the URL where the response comes from.
If the server is in control, we can add an HTTP header X-Request-URL for the redirect URL. However there will be cases that 3rd party services are used.
This PR retrieves the response URL from native networking module and passes to it XMLHttpRequest. The fetch API built on XMLHttpRequest also benefits from this feature.
Closes https://github.com/facebook/react-native/pull/4981
Reviewed By: svcscm
Differential Revision: D2811392
Pulled By: lexs
fb-gh-sync-id: 3ec356fb92f8011b6a243d6879172877a3dc498a
Summary:
public
Attempting to load an undefined URL via XMLHttpRequest produced a confusing error deep within the network layer. This diff improves the networking stack to catch such errors earlier, and also adds a helpful error in the JS layer.
Fixes https://github.com/facebook/react-native/issues/4558
Reviewed By: javache
Differential Revision: D2811080
fb-gh-sync-id: 1837427e1080a0308f2c4f9a8a42bce2e041fb48
Summary:
public
This diff replaces the RegEx module method parser with a handwritten recursive descent parser that's faster and easier to maintain.
The new parser is ~8 times faster when tested on the UIManager.managerChildren() method, and uses ~1/10 as much RAM.
The new parser also supports lightweight generics, and is more tolerant of white space.
(This means that you now can – and should – use types like `NSArray<NSString *> *` for your exported properties and method arguments, instead of `NSStringArray`).
Reviewed By: jspahrsummers
Differential Revision: D2736636
fb-gh-sync-id: f6a11431935fa8acc8ac36f3471032ec9a1c8490
Summary:
public
When uploading images, RCTHTTPFormDataHelper was sometimes accessed on the wrong thread.
Reviewed By: helouree
Differential Revision: D2709186
fb-gh-sync-id: d0a14926927d1d41f602f78a9f6892dfbdfc6ff9
Summary: public
The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.
This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.
The rules are now as follows:
* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.
These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.
I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:
Out of the 65 modules included in UIExplorer:
* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand
Reviewed By: jspahrsummers
Differential Revision: D2677695
fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
Summary: public
Removed redundant calls to [RCTNetwork canHandleRequest] in release mode when loading images, and improved perf for handler lookups when running in debug mode.
Reviewed By: tadeuzagallo
Differential Revision: D2663307
fb-gh-sync-id: 13285154c1c3773b32dba7894d86d14992e2fd7d
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: public
Added RCTDataRequestHandler, which is responsible for loading data URLs. This moves the logic for data URL handling out of RCTImageDownloader (no longer needed) and into the RCTNetwork library, where it makes more sense.
This also means that it is now possible to load data URLs via XHR, and use them for purposes other than just images.
Reviewed By: javache
Differential Revision: D2540964
fb-gh-sync-id: 4f0418bd6b9186f047cc8297276bb970795af104
Summary: public
There was a race condition issue in RCTDownLoadTask whereby the request handler would sometimes call one of the delegate methods before setup was complete, causing an error to be logged because the request token had not been set, and causing te request to fail because the class was not yet set up.
This diff fixes that issue by adding an explicit `start` method to RCTDownloadTask, and changing the setup order to allow for the request to call back immediately without this being treated as an error.
Reviewed By: tadeuzagallo
Differential Revision: D2553628
fb-gh-sync-id: 5ca4e791574a632ccbf2e873e28ac88bffdf851d
Summary: @public
We previously discovered that using an NSURLSessionDataTask to load local files is noticably less efficient than using regular filesystem methods.
This diff adds RCTFileRequestHandler as a replacement for RCTHTTPRequestHandler when loading local files. This reduces loading time when loading local files via XMLHttpRequest, as well as improving the performance for some image load requests.
Reviewed By: @javache
Differential Revision: D2531710
fb-gh-sync-id: 259714baac131784de494d24939f42ad52bff41a
Summary: @public
RCTNetworking currently relies on network responses to include an accurate text encoding, otherwise it is unable to convert the response data to text unless it's encoded as UTF8.
See: https://github.com/facebook/react-native/issues/1780#issuecomment-139334294 for details.
This diff makes use of a new feature in iOS8 to detect the encoding of the text authomatically
Reviewed By: @sahrens
Differential Revision: D2443446
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:
Added Gzip function to RCTUtils. This uses dlopen to load the zlib library at runtime so there's no need to link it into your project.
The main reason for this feature is to support gzipping of HTTP request bodies. Now, if you add 'Content-Encoding:gzip' to your request headers when using XMLHttpRequest, your request body will be automatically gzipped on the native side before sending.
(Note: Gzip decoding of *response* bodies is handled automatically by iOS, and was already available).
Summary:
As discussed with @nicklockwood in the issue https://github.com/facebook/react-native/issues/1780, the error should be changed to a warning to not break fetch() to send a POST to a remote API without wanting to parse the reply. E.g. google sends back an empty 1x1px gif when POSTing something to google analytics.
Closes https://github.com/facebook/react-native/pull/1860
Github Author: "philipp.krone" <kronep@googlemail.com>
Scott Wolchok
Philipp von Weitershausen
Skotch Vail
Nick Lockwood
Konstantin Raev
Griffin Smith
grgmo
Lasse Bang Mikkelsen
Alex Roman
realaboo
Philipp von Weitershausen
philipp.krone