Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
Summary:
Currently when doing a file upload, the Content-Type header gets set to whatever MIME type iOS computed for the file. The Content-Type header the developer provided never takes precedence.
For example, when uploading an image, iOS might determine that the MIME type is "image/jpeg" and so this would be the Content-Type of the HTTP request. But the developer might need the Content-Type to be "application/octet-stream". With this change, if the developer provides a Content-Type header, it will not be overriden.
There is only one exception to this rule which is for "multipart" requests. In this case, the developer's Content-Type header is always ignored. This is because the Content-Type header needs to contain the boundary string and that information is not available to the developer in JavaScript.
This change makes iOS's behavior more consistent with Android's.
**Test plan (required)**
In a small test app, verified that the developer's Content-Type header takes precedence when it's provided. Verif
Closes https://github.com/facebook/react-native/pull/9651
Differential Revision: D3820001
Pulled By: mkonicek
fbshipit-source-id: fdb8871f88a0d0db1ae59f75bb62b896fe69542d
Summary:
When bringing back `node-haste` to React Native, I left an `fdescribe` in a test that led to ~70 tests being skipped.
This re-enables these tests, and fixes test failures
Reviewed By: cpojer
Differential Revision: D3811225
fbshipit-source-id: 67a16f385759bb829f1f3f559862eab7e78f2097
Summary:
This adds cookie clearing support for iOS to match the existing support on Android. Helpful for resetting the app to a clean state (say, when logging a user out).
Closes https://github.com/facebook/react-native/pull/9264
Differential Revision: D3776492
Pulled By: javache
fbshipit-source-id: 59ae19ac09d3cf0d0e229cd9e8e30865e65ca96c
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
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:
Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
Reviewed By: fkgozali
Differential Revision: D3398105
fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
Summary:
Accessing the `responseText` property when `responseType` is not `''` or `'text'` should throw. Also, the property is read-only.
**Test Plan:** UIExplorer example, unit tests
Closes https://github.com/facebook/react-native/pull/7284
Differential Revision: D3366893
fbshipit-source-id: a4cf5ebabcd1e03d6e2dc9d51230982922746c11
Summary:
XMLHttpRequest was sending the request before registering any listeners, resulting in a warning from the native event emitter.
Since we weren't seeing widespread problems with XHR missing data, this was probably working OK in practice because the queuing of events meant that the listener would have been registered before the message was actually delivered.
Still, this was working more through luck than design. This diff fixes it by registering the listeners *before* sending the request.
Reviewed By: lexs
Differential Revision: D3371320
fbshipit-source-id: c688d4053a61f856eaacccd0106905edbefcc86a
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:
Further describe the methods available on NetInfo.
Question: How do I update the docs on the website?
Closes https://github.com/facebook/react-native/pull/7375
Differential Revision: D3303300
fbshipit-source-id: 4343d490f65e4e47b93f2c98a645cb675d2cf708
Summary:
The XMLHttpRequest jest tests were attempting to call a private method in XMLHttpRequestBase.js (denoted by an _ prefix).
JS doesn't actually have any language-level support for private methods, the use of _ prefix is just a convention. But to prevent casually calling private methods externally, we have a transform that mangles the names of prefixed methods so that that attempting to call them will fail.
Using a double _ bypasses this name-mangling mechanism, while still making it clear that the method is intended to be private.
Reviewed By: javache
Differential Revision: D3276261
fb-gh-sync-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
fbshipit-source-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
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:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closes https://github.com/facebook/react-native/pull/7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355
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:This prevents possible developer errors when using 'post' or 'put' instead of 'POST' and 'PUT'.
Fixes: https://github.com/facebook/react-native/issues/6855
**Test plan:**
Previously, a `method put must not have a request body` error would be thrown when the method was in lowercase and a request body was indeed included.
With this fix and the following code (note the method name in all lowercase), the request is properly completed.
```javascript
const url = 'http://myurl.com';
const request = new XMLHttpRequest();
request.open('put', url);
request.setRequestHeader("Content-type","application/json");
request.onload = function() {
console.log('onload');
};
request.onerror = function() {
console.log('error');
};
request.send(JSON.stringify({ something: 'here' }));
```
Closes https://github.com/facebook/react-native/pull/6956
Differential Revision: D3173467
Pulled By: davidaurelio
fb-gh-sync-id: add90e9f31cd4f548547a3f85267a782ae74a89c
fbshipit-source-id: add90e9f31cd4f548547a3f85267a782ae74a89c
Summary:Fixes #6679
This adds support for the missing response types to XMLHttpRequest.
Don?t ship this yet. This is completely untested. yolo and stuff.
Closes https://github.com/facebook/react-native/pull/6870
Reviewed By: bestander
Differential Revision: D3153628
Pulled By: davidaurelio
fb-gh-sync-id: 76feae3377bc24b931548a9ac1af07943b1048ac
fbshipit-source-id: 76feae3377bc24b931548a9ac1af07943b1048ac
Summary:After adding support for `XMLHttpRequest#response`, the `fetch` polyfill detects buffer support when debugging in Chrome and sets `responseType` to `'blob'`.
In that case, the response was always empty.
This change will construct a blob if `responseType` has been set to `'blob'` in order to avoid that problem
Reviewed By: steveluscher
Differential Revision: D3018884
fb-gh-sync-id: 4ade0413de67242c3565d95c2880d4a981ba2342
shipit-source-id: 4ade0413de67242c3565d95c2880d4a981ba2342
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:The ArrayBuffer support added in https://github.com/facebook/react-native/pull/6156 crashed on iOS7 as Uint8Array is unavailable.
This diff removes that feature. We can revisit it again once we drop support for iOS 7.
Reviewed By: javache
Differential Revision: D2999762
fb-gh-sync-id: b497eac92ca5a0865b308d2a08c9409fcce97156
shipit-source-id: b497eac92ca5a0865b308d2a08c9409fcce97156
Summary:Currently the XMLHttpRequest don't support any response types other than text. This PR will add responseType attribute as well response attribute.
This PR will partially solve the issue https://github.com/facebook/react-native/issues/6017
Closes https://github.com/facebook/react-native/pull/6156
Differential Revision: D2994267
Pulled By: nicklockwood
fb-gh-sync-id: 24642c48655930c8350112bac38e6ed4a42bd40d
shipit-source-id: 24642c48655930c8350112bac38e6ed4a42bd40d
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: This adds a persistent cookie store that shares cookies with WebView.
Add a `ForwardingCookieHandler` to OkHttp that uses the underlying Android webkit `CookieManager`.
Use a `LazyCookieHandler` to defer initialization of `CookieManager` as this will in turn trigger initialization of the Chromium stack in KitKat+ which takes some time. This was we will incur this cost on a background network thread instead of during startup.
Also add a `clearCookies()` method to the network module.
Add a cookies example to the XHR example. This example should also work for iOS (except for the clear cookies part). They are for now just scoped to Android.
Closes#2792.
public
Reviewed By: andreicoman11
Differential Revision: D2615550
fb-gh-sync-id: ff726a35f0fc3c7124d2f755448fe24c9d1caf21
Summary: public
Recent refactoring of `XMLHttpRequestBase` made use of `abortRequest` instead of the existing `cancelRequest` in iOS. This will simply alias `abortRequest` to `cancelRequest`.
Reviewed By: nicklockwood
Differential Revision: D2671189
fb-gh-sync-id: 6987d004e5a54973c330e19a1baba19ee41170f0
Summary: Hi,
I'm currently building an app that changes metadata, does some resizes, maybe watermarking ...etc. I want to use RCTImageStoreManager to store the original image in memory and allow me to command different modifications from javascript as it gives me more flexibility. As RCTImageEditingManager does for example.
But currently the RTCImageStoreManager uses UIImage to store the image, the problem is that UIImage losses metadata.
So i suggest we change it to NSData.
Additionally I added a method to remove an image from the store.
A related PR can be found here https://github.com/lwansbrough/react-native-camera/pull/100.
Closes https://github.com/facebook/react-native/pull/3290
Reviewed By: javache
Differential Revision: D2647271
Pulled By: nicklockwood
fb-gh-sync-id: e66353ae3005423beee72ec22189dcb117fc719f
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: Send part of the response body every 100 ms if the client has set onreadystatechange. This
is done by using the same events as the iOS code and removing the callback that Android previously
used.
Reconsolidate iOS and Android implementations.
Closes#3772
(The previous commit was reverted)
public
Reviewed By: astreet
Differential Revision: D2658153
fb-gh-sync-id: b1a32d22db7cc2995c673edd31f4bbaf16ca36cb
Summary: Send part of the response body every 100 ms if the client has set onreadystatechange. This
is done by using the same events as the iOS code and removing the callback that Android previously
used.
Reconsolidate iOS and Android implementations.
Closes#3772
public
Reviewed By: mkonicek
Differential Revision: D2647005
fb-gh-sync-id: d006e566867fa47d5f8dff71219cb390bcb8e15a
Summary: Hi,
While implementing my own `RCTURLRequestHandler` I came across retain cycles in `RCTNetworkTask` when used with `RCTFileRequestHandler` and `RCTDataRequestHandler`.
The `NSBlockOperation` used in `RCTFileRequestHandler` and `RCTDataRequestHandler` could never be dealloc'ed because of a retain cycle.
And then the second issue was that those blocks were also strongly capturing the passed delegate which in this case is the `RCTNetworkTask` itself and then since the task was storing the block as a `requestToken`, the task could never be dealloc'ed as well.
Here are my proposed fixes. Let me know what you think.
Closes https://github.com/facebook/react-native/pull/3884
Reviewed By: svcscm
Differential Revision: D2615353
Pulled By: nicklockwood
fb-gh-sync-id: a73cbecffbebea75aaeb23d39f04a0d87602926f
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: Right now `FormData` doesn't allow duplicate keys and uses the last value set for a duplicate key. I tested this in Chrome:
```
var formData = new FormData();
formData.append('key', 'value1');
formData.append('key', 'value2');
var request = new XMLHttpRequest();
request.open("POST", serverUrl);
request.send(formData);
```
and the request has both 'value1' and 'value2'.
I removed the duplicate key check in `FormData`. If people want to build appending or disallow duplicate keys, they can build either on top of this.
Closes https://github.com/facebook/react-native/pull/3556
Reviewed By: svcscm
Differential Revision: D2566999
Pulled By: nicklockwood
fb-gh-sync-id: 580e52e69376ebe9693e39a386cc540802b6d94f
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
This diff unifies the logic for detecting when images refer to XCAsset files into a single function (RCTXCAssetNameForURL) and uses it for both +[RCTConvert UIImage:] and RCTImageLoader.
I've also tightened the definition of XCAssets so that it only applies to images inside .car files, not any image inside the main bundle. This avoids using the +[UIImage imageNamed:] when not strictly necessary, which is desirable since that method is not thread-safe, and has undocumented caching behavior that is difficult to reason about.
Reviewed By: @javache
Differential Revision: D2526400
fb-gh-sync-id: 7199c2a44f1d55ff236d2c38a0a9368739b993d5
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
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
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`.
Pieter De Baets
Satyajit Sahoo
Douglas Lowder
Erik Arvidsson
Adam Comella
David Aurelio
Marc Horowitz
Ian MacLeod
Scott Wolchok
Janic Duplessis
Philipp von Weitershausen
Spencer Ahrens
Skotch Vail
Jeff Morrison
Nick Lockwood
Philipp von Weitershausen
Basil Hosmer
Konstantin Raev
Yao Bin Then
Griffin Smith
Christoph Pojer
grgmo
Dave Sibiski
Aleksei Androsov
Laurence Bortfeld
Sreejumon
Lasse Bang Mikkelsen
Connor McEwen
Alex Roman
Aleksei Androsov
Oleg Lokhvitsky
realaboo
Gabe Levi
Martin Konicek
Nathan Spaun
Huang Yu
Alexander Blom
Kevin Gozali
Matthieu Achard
Jean Regisser
Jesse Ruder
Christopher
Krzysztof Magiera
Alexsander Akers
Philipp von Weitershausen