Summary:
The CameraRoll-related APIs were mixed in with the Image classes due to legacy coupling issues. Now that the APIs have been decoupled, it makes more sense for the CameraRoll classes to live in a separate library.
This will be a breaking change for apps using the CameraRoll or related APIs. Fix is to add the RCTCameraRoll lib to your project.
Summary:
There was some recent changes to the Makefile, but the open source
build phase script wasn't update. Update it to copy the files to
the right location.
Summary:
1. When the server starts up, it only gives itself 30 second to live before receiving any connections/jobs
2. There is a startup cost with starting the server and handshaking
3. The server dies before the client has a chance to connect to it
Solution:
1. While the server should die pretty fast after it's done it's work, we should have a longer timeout for starting it
2. I also added accompanying server logs with client connection errors
Summary:
We don't currently support platform extensions in asset modules.
This adds supports for it:
```
require('./a.png');
```
Will require 'a.ios.png' if it exists and 'a.png' if it doesn't.
Summary:
GIF images are currently loaded as a CAKeyframeAnimation, however returning this animation directly from RCTImageLoader was dangerous, as any code that expected a UIImage would crash.
This diff changes RCTGIFImageLoader to return a UIImage of the first frame, with the keyframe animation attached as an associated object. This way, code that is not expecting an animation will still work correctly.
Summary:
I'd like this ability as this has a tendency to get in the way of some of the more complex UI pieces I have. Disabling RCT_DEV entirely is too much for me.
Closes https://github.com/facebook/react-native/pull/2451
Github Author: Tj <tfallon@mail.depaul.edu>
Summary:
Previously the bridge sometimes never fired RCTJavaScriptDidLoadNotification or RCTJavaScriptDidFailToLoadNotification if there was an error (for example, if the source code loaded but we couldn't inject the JSON config). This diff moves the error handling into a method called `stopLoadingWithError` that the bridge can call whenever there is an error.
Also if the script failed to load, the BatchedBridge still called `executeSourceCode`. With this diff the `_loading` flag is set to NO when the script fails to load, and `executeSourceCode` returns immediately when `_loading` is false. This way the bridge does not try to execute JS when there is a loading error.
Closes https://github.com/facebook/react-native/pull/2520
Github Author: James Ide <ide@jameside.com>
Summary:
Saw an issue with a build because of an ENONT error: https://fb.facebook.com/groups/716936458354972/permalink/923628747685741/
My hypothesis:
1. We issue a ping to the socket (in SocketInterface/index.js) a decides if the available socket is alive
2. We see that it's alive but by the time we actually connect to it the server would've died
Solution:
1. The server shouldn't die as long as there are clients connected to it (currently it only stay alive as long as there are jobs)
2. The "ping" should only disconnect once the client is connected
3. Finally, have a better error message than ENOENT
Summary:
We currently wait until after views have been updated on the main thread before sending layout events. This means that any code that relies on those events to update the UI will lag the atual layout by at least one frame.
This changes the RCTUIManager to send the event immediately after layout has occured on the shadow thread. This noticably improves the respinsiveness of the layout example in UIExplorer, which now updates the dimension labels immediately instead of waiting until after the layout animation has completed.
Summary:
Sourcemap urls were generated as just the pathname (no options) which meant that they generated source for the wrong bundle.
Even worse, there exists a race condition when multiple request to the same bundle has different types of paltform arguments (in this case one could be 'ios' and the other is undefined). The fix will this will come later as it's more involved -- will need to refactor the dependency resolver to have a per-request state.
Summary:
The previous version of stacktrace-parser 0.1.2 had an line in its package.json file that required Node <= 2.x. That line was removed, so it no longer warns on io.js 3.x or Node 4.x.
Similarly, ws 0.8.0 was published with support for the new V8, so it compiles with io.js 3.x and therefore should work with Node 4.x.
Updated the Travis file as well to run on io.js 3.x.
Fixes#2258, #2455
Closes https://github.com/facebook/react-native/pull/2398
Github Author: James Ide <ide@jameside.com>
Summary:
The makefile for the JSCLegacyProfiler was really messy, clean it up a bit,
remove duplicate code, and make targets be actual files rather than dummy targets
so it can actually cache things instead of re-downloading everything every time.
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
Supports `onLayout` for Touchable*` by piping onLayout
through to the native component inside since only native components support
it by default.