Summary:
This fixes the following problem on iPad (happens when trying to show the devmenu ActionSheet):
> Terminating app due to uncaught exception 'NSGenericException', reason: 'Your application has presented a UIAlertController () of style UIAlertControllerStyleActionSheet. The modalPresentationStyle of a UIAlertController with this style is UIModalPresentationPopover. You must provide location information for this popover through the alert controller's popoverPresentationController. You must provide either a sourceView and sourceRect or a barButtonItem. If this information is not known when you present the alert controller, you may provide it in the UIPopoverPresentationControllerDelegate method -prepareForPopoverPresentation.'
I see 2 ways of fixing the issue: falling back to Alert (always displayed in the center) or adding a fake view somewhere on the screen to display the ActionSheet.
Reviewed By: mmmulani
Differential Revision: D3989672
fbshipit-source-id: 59fabc50ec1aac3ae6ddd7ecf4d8e8e5b9586dba
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
- Being able to call these from JS is really useful in envs where action sheets are not available (eg: App Extensions). I made the functions act as explicit toggles, this way it's easy to set the wanted behavior.
**Test plan (required)**
- I tested the functions manually.
Closes https://github.com/facebook/react-native/pull/9242
Differential Revision: D3749568
fbshipit-source-id: 2cea1d609dc792aec73d4bcf1eae07575725b4b7
Summary:
At the moment, posting RCTReloadNotification in any circumstance causes all RCTBridge instances to reload. This change scopes the notification to the bridge for which it was intended.
Closes https://github.com/facebook/react-native/pull/8762
Differential Revision: D3831914
fbshipit-source-id: ff29574f574ecd1a403057ddd0458dea38f0136e
Summary:
When call `[RCTDevMenu invalidate]`, it will cancel updateTask. But in fact, after the `[updateTask cancel]`, the updateTask's completionHandler will call `checkForUpdates` again, so it will create a new updateTask.
Closes https://github.com/facebook/react-native/pull/6165
Differential Revision: D3669576
Pulled By: javache
fbshipit-source-id: 443924b7f4be1716797fc5690e90d962cf31b923
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:* Add ability to configure the app that should open when starting debugging
axemclion discussed this feature with tadeuzagallo and martinbigio on: https://github.com/facebook/react-native/issues/5051
Closes https://github.com/facebook/react-native/pull/5683
Reviewed By: martinbigio
Differential Revision: D2971497
Pulled By: mkonicek
fb-gh-sync-id: 91c3ce68feed989658124bb96cb61d03dd032599
fbshipit-source-id: 91c3ce68feed989658124bb96cb61d03dd032599
Summary:The packager url for the persistent connection relied on a port
in the bundleURL, so we need to insert a sensible default. Otherwise,
issues occur: https://github.com/facebook/react-native/issues/6581
Reviewed By: bestander
Differential Revision: D3113034
fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
Summary: The module initialization process is complex and full of race conditions. This diff adds a set of unit tests that verify that modules setup happens in the correct order, and enforces all the various conditions for main/background init.
Reviewed By: javache
Differential Revision: D2994145
fb-gh-sync-id: 92ea84508cdeeb280ff0fb9e9b2dffa8dbc37e66
shipit-source-id: 92ea84508cdeeb280ff0fb9e9b2dffa8dbc37e66
Summary:The `RCTDevMenu.hotLoadingAvailable` check always returned YES if `bridge.bundleURL` was nil. This caused the `setHotLoadingEnabled:` method to repeatedly reload the bridge, resulting in the following tests failing:
`- [RCTBridgeTests testHookRegistration];`
`- [RCTBridgeTests testCallNativeMethod];`
Also, the `RUN_RUNLOOP_WHILE()` macro did not actually assert when timing out, and the logic in `- [RCTBridgeTests tearDown];` was broken in such a way that tests would always take 5 seconds to run (and then timeout silently). This adds an assertion, and removes the broken nil check for `jsExecutor`.
Reviewed By: majak
Differential Revision: D2988885
fb-gh-sync-id: 91307585ac8acb0181f0cddeeddf6cb4b198e4fe
shipit-source-id: 91307585ac8acb0181f0cddeeddf6cb4b198e4fe
Summary:
public
Although the feature itself is gated, once the user is on the experiment we want to make sure hot loading starts disabled up until the feature is enabled through the dev menu.
Reviewed By: javache
Differential Revision: D2850070
fb-gh-sync-id: 66e69e152806d3bb01985afe20827e3b9cffeb41
Summary:
public
By doing this we fix 2 problems:
1. We use the same url, both the first time the simulator starts with Hot Loading disabled (no `hot` attribute), and after HL has been enabled and then disabled ('hot=false'). By doing so, the packager will rebuild more than one bundle as file changes. We could have ignored this attribute on the packager but I'd rather not contaminate the server with it and instead make the clients send only 2 types of URLs.
2. The code on `RCTBatchedBridge.m` that decides whether or not to enable HMR does so by looking at presence of the query string parameter `hot`. If the parameter is present, even when it's false, it will try to enable HL, which is wrong.
Reviewed By: nicklockwood
Differential Revision: D2807512
fb-gh-sync-id: 728b680c2383c328d8967d34c10e7a6288e455ac
Summary:
public
A lot of the core modules have to use private methods in the bridge, specially
since the `RCTBatchedBridge` interface is never exposed. That was leading to a
lot of different private bridge categories spread across different modules,
which makes harder to identify which modules are affected by private API changes.
Replace all the categories with a single private header.
Reviewed By: nicklockwood
Differential Revision: D2757564
fb-gh-sync-id: 793158b9082d542b74a6094ed0db4d5dc3a88f78
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: public
The WebView executor has no benefits compared to the JSC executor (slower, no extra debugging tools...),
and it's pretty hacky (since it injects the code in a script tag we have to check for tags in the comments and etc...).
Reviewed By: nicklockwood, javache
Differential Revision: D2636465
fb-gh-sync-id: 0d0f8a59e2c12fe7905b02060b3938c894d2802b
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
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: 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:
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.
Pieter De Baets
Alex Kotliarskyi
Marc Horowitz
Douglas Lowder
Hugo Dozois
Ben Roth
Scott Wolchok
wenzhao.yin
Skotch Vail
Martin Konicek
Nick Lockwood
Konstantin Raev
Digeff
Walter Luh
Alexey Lang
Martín Bigio
Tadeu Zagallo
Natthu Bharambe
Patrik Tomas Chamelo
Yusef Napora
