Summary: While we shouldn't invoke `bridge.devMenu` in production, doing it will result into a crash.
1. `devMenu` internally calls `RCTBridgeModuleNameForClass([RCTDevMenu class])`
2. `RCTBridgeModuleNameForClass()` calls `moduleName`
3. In the release code `RCTDevMenu` doesn't export the `moduleName` class method.
Closes https://github.com/facebook/react-native/pull/2910
Reviewed By: svcscm
Differential Revision: D2550797
Pulled By: tadeuzagallo
fb-gh-sync-id: 5dfbf905e5a02d9fd3b52f8b3d6eefc4e3ff30b2
Summary: public
Benchmarking our startup path has shown we spend a lot of time decoding strings (iPhone 4S / iPhone 5):
* reading a 2MB JS bundle: 35ms / 15ms
* decoding is to an `NSString`: 186ms / 78ms
* transforming that to a `JSString`: 29ms / 10ms
Instead of going through an `NSString` transformation, we generate a null-terminated bundle (0.1ms / 0.05ms to copy the data) and use `JSStringCreateWithUTF8CString` (121ms / 53ms) to generate the string. That makes decoding 70% faster.
Reviewed By: javache
Differential Revision: D2541140
fb-gh-sync-id: 09a016b8edfd46a9b62682c76705564d2024e75e
Summary: @public
This diff implements inline image support for <Text> nodes. Images are specified using <Image> tags, however all properties of the image are currently ignored apart from the source (including width/height styles).
Images are loaded asyncronously, and will trigger a text re-layout when they have loaded.
Reviewed By: @javache
Differential Revision: D2507725
fb-gh-sync-id: 59d0696d00a1bc531915cc35242a16b2dec96e85
Summary: When you reload and create a new bridge, one of the things that happens during setup is that the RCTAccessibilityManager fires a notification. The old bridge would receive this notification from the new bridge's RCTAccessibilityManager, which we don't want, especially because the two are running on different shadow queues.
I believe this led to a gnarly crash in NSConcreteTextStorage because RCTMeasure in RCTShadowText.m was getting called for the old RCTText (getting destroyed) from a notification fired from the new shadow queue. The fix is for the UIManager to handle notifications only from its bridge's RCTAccessibilityManager. See #2001 for the kinds of crashes we were seeing.
Closes https://github.com/facebook/react-native/pull/3279
Reviewed By: @svcscm
Differential Revision: D2521652
Pulled By: @nicklockwood
fb-gh-sync-id: a4ffe3ef8304667727e573e2a2e8b716e1d2f3e1
Summary: This adds workarounds for the code that was preventing React from compiling when linked against an iOS App Extension target.
Some iOS APIs are unavailable to App Extensions, and Xcode's static analysis will catch attempts to use methods that have been flagged as unavailable.
React currently uses two APIs that are off limits to extensions: `[UIApplication sharedApplication]` and `[UIAlertView initWith ...]`.
This commit adds a helper function to `RCTUtils.[hm]` called `RCTRunningInAppExtension()`, which returns `YES` if, at runtime, it can be determined that we're running in an app extension (by checking whether the path to `[NSBundle mainBundle]` has the `"appex"` path extension).
It also adds a `RCTSharedApplication()` function, which will return `nil` if running in an App Extension. If running in an App, `RCTSharedApplication()` calls `sharedApplication` by calling `performSelector:` on the `UIApplication` class. This passes the static analysis check, and, in my opinion, obeys the "spirit of th
Closes https://github.com/facebook/react-native/pull/1895
Reviewed By: @svcscm
Differential Revision: D2224128
Pulled By: @nicklockwood
Summary: - Includes the error cookie with soft exceptions as well since they too can be updated (requires tiny Android change too)
- Passes the error cookie through instead of leaving it unused
Closes https://github.com/facebook/react-native/pull/2198
Reviewed By: @svcscm
Differential Revision: D2455391
Pulled By: @sahrens
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:
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:
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:
Add JSC profiler to the dev menu and rename the pre-existent one to systrace.
For now it just outputs to the console, but a better workflow is on the way.
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Summary:
Moved the view creation & property binding logic out of RCTUIManager into a separate RCTComponentData class - this follows the pattern used with the bridge.
I've also updated the property binding to use pre-allocated blocks for setting the values, which is more efficient than the previous system that re-contructed the selectors each time it was called. This should improve view update performance significantly.
Summary:
Dynamic Text Sizes for Text component.
Text gains new prop - allowFontScaling (false by default).
There is also AccessibilityManager module that allows you to tune multipliers per each content size category.
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 the ability to turn on and off the network activity indicator using:
```
StatusBarIOS.setNetworkActivityIndicatorVisible(true)
```
and
```
StatusBarIOS.setNetworkActivityIndicatorVisible(false)
```
Also added an example to the UIExplorer example app.
Fix#986
Closes https://github.com/facebook/react-native/pull/2079
Github Author: Mark Miyashita <negativetwelve@gmail.com>
Summary:
RCTNetworkImageView and RCTStaticImage had significant overlap in functionality, but each had a different subset of features and bugs.
This diff merges most of the functionality of RCTNetworkImageView into RCTStaticImage, eliminating some bugs in the former, such as constant redrawing when properties were changed.
I've also removed the onLoadAbort event for now (as it wasn't implemented), and renamed the other events to match the web specs for `<img>` and XHMLHttpRequest. The API is essentially what Adobe proposed here: http://blogs.adobe.com/webplatform/2012/01/13/html5-image-progress-events/
The following features have not yet been ported from RCTNetworkImageView:
- Background color compositing. It's not clear that this adds much value and it increases memory consumption, etc.
- Image request cancelling when images are removed from view. Again, it's not clear if this is a huge benefit, but if it is it should be combined with other optimisations, such as unloading offscreen images.
(Note that this only affects the open source fork. For now, internal apps will still use FBNetworkImageView for remote images.)
