Summary: public
There were some old markers that are now automatically inject and now are no longer necessary (+ one that was missing an end call :( ))
Reviewed By: javache
Differential Revision: D2625901
fb-gh-sync-id: 4c4c9d6b4e8e2b4bdb9c64fde01000b0ca2e9f47
Summary: public
Add RCTFatal for reporting fatal runtime conditions. This centralizes failure handling to one function and allows you to customize how they should be handled. RCTFatal will be logged to the console and as a redbox and will also be triggered by fatal exceptions coming from RCTExceptionsManager.
Note that there is no RCTLogFatal, since just logging the fatal condition does not allow us to handle it consistently.
Reviewed By: nicklockwood
Differential Revision: D2615490
fb-gh-sync-id: 7d8e134419e10a8fb549297054ad955db3f6bee0
Summary: I was getting the following error when running `testAsyncStorageTest`
```
uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (NSError)'
```
nicklockwood pointed out that it might be because we're attempting to send a `NSError *` over the bridge at some point. So I went looking for cases where that might happen and found this instance.
public
Reviewed By: jingc
Differential Revision: D2619240
fb-gh-sync-id: dc26ec268f976fec44f2804831398d3b01ab6115
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
The UIManager had a lock around the enqueued ui blocks, but now all the operations
should happen on the shadow thread, so I added assertions to it and removed the
locks.
Reviewed By: nicklockwood
Differential Revision: D2605760
fb-gh-sync-id: e1bc649f759502e7e9fd059932e0cba38dba05bf
Summary: There is no point in dispatching to main thread if there is nothing to do there.
This place gets called basically any time a repeating js timer fires, which doesn't imply UI changes (although usually that's why people setup timers).
Combined with previous diffs that makes us not generate empty blocks (nil instead), this could be minor perf win in some rare cases.
This also changes semantic of `reactBridgeDidFinishTransaction` call a bit. Previously it was done no matter if UI has changed or not.
I think it should be safe, since seems like callees really care only about views being laid out.
Depends on D2571166. (not strictly speaking)
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2571188
fb-gh-sync-id: 02d52e4615475072c3c27226e67c431a667ec990
Summary: Same as in previous diffs. Gets us into a better place to know if we really have UI updates and it's marginally more efficient.
Depends on D2571143. (not really)
public
Reviewed By: nicklockwood
Differential Revision: D2571166
fb-gh-sync-id: e8f34521ec2e12156a49f1cd655e92df1db34fca
Summary: Previously `_bridgeTransactionListeners` were informed about `reactBridgeDidFinishTransaction` inside of one of the UI blocks.
That seems pretty arbitrary, doesn't really mean a "transaction" is really over (assuming transaction means all UI updates) and even when that block does nothing we still need to call these listeners, since there could be other UI blocks generated somewhere else!
So I've moved this call to a place that seemed better (=after all UI blocks are done), since all listeners are interested in knowing when layout has happened.
public
Reviewed By: nicklockwood
Differential Revision: D2571122
fb-gh-sync-id: 62be03ebc4353d6f6318c9765079b87b07483be2
Summary: public
Kill `RCTPerfStats` and introduce the new `RCTPerfMonitor`, including memory
usage, JSC heap size, number of RN views in screen, FPS (both on UI and JS threads)
and more to come.
It removes all the previous traces that were previous spread across the bridge
and the dev menu and moves everything to be more contained, so the whole thing
can be safely striped in production.
Reviewed By: nicklockwood
Differential Revision: D2575158
fb-gh-sync-id: 6a6d0c4422adbddeeefddd32ec3409a7095ff2a9
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.)
Summary:
These are the changes needed for full interop with the (as yet unreleased) new
version of React Devtools.
- the on-device inspector is minimized when devtools is open
- devtools highlight -> device and device touch -> devtools select works
- editing react native styles :)
Summary:
Dynamic Text Sizes for Text component.
Text gains new prop - allowFontScaling (true by default).
There is also AccessibilityManager module that allows you to tune multipliers per each content size category, but predefined multipliers are there.
This could potentially break some apps so please test carefully.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
Summary:
This adds the Keyboard animation type for when you want to animate UI based on the keyboard appearing/disappearing.
Closes https://github.com/facebook/react-native/pull/1366
Github Author: Stanislav Vishnevskiy <vishnevskiy@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Started from here - https://github.com/facebook/react-native/issues/1120. Most functionality for annotations were missing so I started implementing and somehow got caught up until the entire thing was done.
![screen shot 2015-05-12 at 10 07 43 pm](https://cloud.githubusercontent.com/assets/688326/7588677/8479a7a4-f8f9-11e4-99a4-1dc3c7691810.png)
2 new events:
- callout presses (left / right)
- annotation presses
6 new properties for annotations:
- hasLeftCallout
- hasRightCallout
- onLeftCalloutPress
- onRightCalloutPress
- animateDrop
- id
1 new property for MapView
- onAnnotationPress
---
Now the important thing is, that I implemented all of this the way "I would do it". I am not sure this is the 'reacty' way so please let me know my mistakes 😄
The problem is that there is no real way to identify annotations which makes it difficult to distinguish which one got clicked. The idea is to pass a `id` and whether it has callouts the entire way with the annotation. I had to
Closes https://github.com/facebook/react-native/pull/1247
Github Author: David Mohl <me@dave.cx>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Remove layout-only views. Works by checking properties against a list of known properties that only affect layout. The `RCTShadowView` hierarchy still has a 1:1 correlation with the JS nodes.
This works by adjusting the tags and indices in `manageChildren`. For example, if JS told us to insert tag 1 at index 0 and tag 1 is layout-only with children whose tags are 2 and 3, we adjust it so we insert tags 2 and 3 at indices 0 and 1. This keeps changes out of `RCTView` and `RCTScrollView`. In order to simplify this logic, view moves are now processed as view removals followed by additions. A move from index 0 to 1 is recorded as a removal of view at indices 0 and 1 and an insertion of tags 1 and 2 at indices 0 and 1. Of course, the remaining indices have to be offset to take account for this.
The `collapsible` attribute is a bit of a hack to force `RCTScrollView` to always have one child. This was easier than rethinking out the logic there, but we could change this later.
@public
Test Plan: There are tests in `RCTUIManagerTests.m` that test the tag- and index-manipulation logic works. There are various scenarios including add-only, remove-only, and move. In addition, two scenario tests verify that the optimization works by checking the number of views and shadow views after various situations happen.
Summary:
@public
The info about bridge modules (such as id, name, queue, methods...) was spread
across arrays & dictionaries on the bridge, move it into a specific class.
It also removes a lot of information that was statically cached, and now have
the same lifecycle of the bridge.
Also moved RCTModuleMethod, RCTFrameUpdate and RCTBatchedBridge into it's own
files, for organization sake.
NOTE: This diff seems huge, but most of it was just moving code :)
Test Plan:
Tested UIExplorer & UIExplorer tests, Catalyst, MAdMan and Groups. Everything
looks fine.
Summary:
@public
Add marker to show JavaScript download duration + flow arrows to show the origin
of the UI blocks being flushed.
Also fixed the condition on `RCTPerfStats`, UI and JS graphs were being created
at startup time, now they're just created on the first time they're shown.
Test Plan:
The markers:
{F22577660}
To check the FPS graph, enable it on the DevMenu, and it should appear initially
empty, instead of previously filled as before.
Summary:
@public
This removes the last piece of data that was still stored on the DATA section,
`RCT_IMPORT_METHOD`. JS calls now dynamically populate a lookup table simultaneously
on JS and Native, instead of creating a mapping at load time.
Test Plan: Everything still runs, tests are green.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
`-[RCTJavaScriptExecutor executeBlockOnJavaScriptQueue:]` would always `dispatch_async`
for the WebView and WebSocket executors, what caused for any frame aligned dispatch.
Test Plan:
Test the `Timers, TimerMixin` example on UIExplorer, `requestAnimationFrame` was
taking ~33.3ms when debugging, now takes ~16.6ms as expected.
Summary:
@public
setFrame:forRootView: wasn't triggering a batch update, which is required to trigger text update. This meant text wasn't re-displayed after a rotate, only after a touch.
I also found a bug that meant we weren't caching textStorage as much as we could be. Fixed that too.
Test Plan:
* Test <Text> example in UIExplorer and ensure it lays out on rotate.
* Test <Timers> example and verify text is still updating
* Products shouldn't be affected as they have separate text implementation
Summary:
@public
This probably needs more thought - might want to differentiate between console.error and reportError.
Test Plan: console.error and reportError no longer redbox. invariant and RCTLogError still do.
Summary:
@public
There have been multiple instances of confusion about whether a redbox means the
developer did something they shouldn't but things will keep working, or if
something went horribly wrong and the app will crash in prod. This diff
introduces an orange background color to the redbox for `console.error` and
`RCTLogError` to indicate that something bad happened, but that the app will
continue working.
Test Plan:
see orange error for geo permissions:
{F22541375}