Summary: @public
Migrate scripts to open source and add new route on the packager
to directly convert profiler outputs to a devtools compatible format.
Reviewed By: @jspahrsummers
Differential Revision: D2425740
Summary:
Occasionally people create RCTBridgeModule subclasses or base classes that are not intended to be accessed from JS, and so they don't export them. This was previously flagged as an error by the system. I've now downgraded this error to a warning at startup, and deferred the redbox error until the module is directly accessed by native or JS code.
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
When the profile is initialized, it automatically hooks into every method of
the bridge modules, that was causing `+initialize` to be called twice.
Also add a popup to notify the user that the profile has been created.
Test Plan:
Run the UIExplorer, start the profiler, try to rage shake to open the dev menu
again. It should now work, and show an alertview with some information once the
profile is stopped.
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
Add `RCT_DEV`-only profiling hooks to every method in every bridge modules to
add a little bit more detail to the timeline profile.
Test Plan: {F22522834}
Summary:
@public
Right now the profiler shows how long the executor took on JS but doesn't show
how long each of the batched calls took, this adds a *very* high level view of JS
execution (still doesn't show properly calls dispatched with setImmediate)
Also added a global property on JS to avoid trips to Native when profiling is
disabled.
Test Plan:
Run the Profiler on any app
{F22491690}
Summary:
@public
Add `RCTAssertThread` to `RCTAssert.h` for convenience when checking the current/queue,
it accepts either a `NSString *`, `NSThread *` or `dispatch_queue_t` as the object to be checked
Also add a check to `-[RCTUIManager addUIBlock:]` - There was a discussion on github (https://github.com/facebook/react-native/issues/1365)
due to the weird behavior caused by calling it from a different thread/queue (it might be added after `batchDidComplete` has been called
and will just be dispatched on the next call from JS to objc)
Test Plan:
Change `-[RCTAnimationExperimentalManager methodQueue]` to return `dispatch_get_main_queue()` and run the 2048 example,
it should dispatch with a helpful message (screenshot on the comments)
