Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary:
This PR seeks to improve the documentation of PushNotificationIOS.
The method didReceiveRemoteNotification without a fetch completion handler is deprecated by Apple and they [discourage using it](https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623117-application) in favor of the [version with the handler](https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623013-application).
Reasons for this change:
1. Our docs say that this method is required for remote notifications, but it's not. (It's one of possibilities with a recommendation not to use it.)
2. The method is deprecated by Apple and people shouldn't use it.
3. If you use the deprecated method, in 99% of the cases it will behave in a different way from what you'd expect. In particular, you won't get remote notifications when your app is in the background.
As there's no benefit (as far as I know) of using the method, I don't think we should even mention it to the users.
This is a re-opened PR that was mis
Closes https://github.com/facebook/react-native/pull/11109
Differential Revision: D4232800
Pulled By: javache
fbshipit-source-id: d3b509db41a549aa7fbc41753c648085df43d8ee
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary:
If we are using the same handler for different events, e.g. both `notification` and `localNotification` use `_onNotification()` handler, the former listener stored in `_notifHandlers` would be overridden by the latter so it's impossible to remove the `notification` listener when we call `removeEventListener`.
This PR stores the listeners by using `pushNotificationEventName` (notification, localNotification, register or registrationError) as the key.
Use the same handler for `notification` and `localNotification`, both listeners will be removed when calling `removeEventListener`.
Closes https://github.com/facebook/react-native/pull/10776
Differential Revision: D4168722
Pulled By: hramos
fbshipit-source-id: d68581428d2acde314f7b5333feafe1ec7807159
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
This just cleans up the work done in #7219 by adamterlson based on grabbou's feedback
Closes https://github.com/facebook/react-native/pull/10337
Differential Revision: D4001540
Pulled By: javache
fbshipit-source-id: c73b5fef912fa71d1d988dae41094c9c46dc610b
Summary:
This is an updated version of #2336 and #7694.
---
This adds a `registrationError` event that is emitted by `PushNotificationIOS` whenever an application receives a registration error from APNS (APNS service failure, running on simulator, etc). This event fires to the exclusion of the `register` event (and vice versa).
**How to use**
Add the following to your `AppDelegate.m`:
```obj-c
- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error
{
[RCTPushNotificationManager didFailToRegisterForRemoteNotificationsWithError:error];
}
```
And register an event handler for the event:
```js
PushNotificationIOS.addEventListener('registrationError', function({ message, code }) {
// Complete your registration process in error.
});
```
**Test plan**
Added support for this event (and `register`) to UIExplorer as a proof of concept. Navigating to the push notifications example on a simulator is an easy way to reproduce this e
Closes https://github.com/facebook/react-native/pull/9650
Differential Revision: D3822142
Pulled By: javache
fbshipit-source-id: a15ed8941b74dc3eed2c44c658deccbcaf39ce3d
Summary:
The docs heavily implied that this method returned a notification object or null directly, like popInitialNotification used to do. In fact, it returns a promise. This change clarifies this.
Note that:
- This is purely a comment change, so no testing required.
- I've adhered to the 80 character line limit, and can't think of any other style rules you might have that could apply here.
Closes https://github.com/facebook/react-native/pull/9052
Differential Revision: D3662807
Pulled By: javache
fbshipit-source-id: 7a2573e03d7704b2d62a3499d350506ae73e8d77
Summary:
It seems it's a common problem people trying to register for push notifications in their simulator, and not understanding why the "register" event never works.
I've wasted a few hours myself on this issue.
This commit simply logs any failures with push registration, preventing confusion.
Closes https://github.com/facebook/react-native/pull/8046
Differential Revision: D3454922
Pulled By: javache
fbshipit-source-id: a96896d97d97cfe1bd319e6490750838dfaad3cd
Summary:
Currently if an RN app is started in response to a remote notification, that notification's data is available on startup via `PushNotificationIOS.popInitialNotification()`. However, if the app is started in response to a "local" notification, that information is never passed in. This PR modifies the `popInitialNotification` behavior so it will return the notification used to launch the app, no matter if it was local or remote.
I've tested this change in my app and ensured that when the app is woken up with a `localNotification` it's passed in to `PushNotificationIOS.popInitialNotification`. I've also tested that the `localNotification` event continues working as before.
Closes https://github.com/facebook/react-native/pull/7765
Differential Revision: D3417267
Pulled By: nicklockwood
fbshipit-source-id: 0b5b432e9a75dda7d3c50289a3bf0f1c1ffcf061
Summary:
The documentation currently list a few but not all of the steps required. This changes completes that list of required project changes.
This addresses #5612
Closes https://github.com/facebook/react-native/pull/7985
Differential Revision: D3414576
Pulled By: nicklockwood
fbshipit-source-id: 2c7ea6598ee4cd8b6945d9bb229bed5b592a68f6
Summary:
_(This is a remake of #6907, which I botched pretty good with a rebase.)_
This returns an `Array` of Local Notifications that have been scheduled to be delivered.
Available attributes on return Notification object (if set in the local notification itself):
`alertAction`
`alertBody`
`applicationIconBadgeNumber`
`category`
`fireDate`
`soundName`
`userInfo`
More could be added to this but I just matched what was available in the `Object` passed to `presentLocalNotification` and `scheduleLocalNotification`.
**Motivation**
I needed to determine the number and other details about local notifications that were already scheduled. There is an API for this in iOS but one hadn't been built yet for React Native.
I created the Obj-C method and updated the documentation in `PushNotificationIOS.js` as well.
**Usage:**
```js
PushNotificationIOS.getScheduledLocalNotifications( (notifications) => {
console.log(notifications);
});
```
**Sample Output:**
```js
[
Object {
aler
Closes https://github.com/facebook/react-native/pull/7937
Differential Revision: D3392476
Pulled By: javache
fbshipit-source-id: d83f419bfcfbdaf9b955724dcf5cfe26834895fb
Summary:
**Motivation**
Today it's hard to build a good flow around requesting permissions if we don't know when the user rejects the push notification permission.
With this PR I wrap `PushNotificationIOS#requestPermission` in a promise. The promise will return with the updated permissions when the user accepts, rejects or has previously rejected the permission.
An example flow of how an app should handle push notifications with the change proposed:
1) Show user an explanation of push notification permissions with a button to enable,
2) User presses the enable push notifications button,
3) If the user accepts -> take them into the app,
4) if the user rejects -> explain how to enable permission in the settings app.
5) My app will now store some state about how it has asked permissions for push notifications so that the next time the user is taken through this flow they will go straight to step 4.
Without this change we could listen to the `register` event that PushNotificationIOS fires on the success sc
Closes https://github.com/facebook/react-native/pull/7900
Differential Revision: D3387424
Pulled By: nicklockwood
fbshipit-source-id: e27df41e83216e4e2a14d1e42c6b26e72236f48c
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:
Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
Reviewed By: javache
Differential Revision: D3258232
fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
Summary:
Added support for setting an optional badge icon number and alert action when using local notifications.
Closes https://github.com/facebook/react-native/pull/2931
Differential Revision: D3212448
Pulled By: mkonicek
fb-gh-sync-id: 063efcdd259b2a43f39812f57a71e8489ab33653
fbshipit-source-id: 063efcdd259b2a43f39812f57a71e8489ab33653
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Hello!
As described in #3288, the `PushNotificationsIOS` `register` callback fires twice. See that issue for discussion.
There wasn't any feedback on a proposed PR, so this is the first effort. This change does make the register callback act as expected on my device. I can make any changes necessary.
Thanks!
Closes https://github.com/facebook/react-native/pull/6111
Differential Revision: D2970806
Pulled By: nicklockwood
fb-gh-sync-id: a8d0b53210f85cc24b4befdb0e90af46512fa4fb
shipit-source-id: a8d0b53210f85cc24b4befdb0e90af46512fa4fb
Summary:In order to use iOS notification actions with local notifications, we need to be able to specify a category string. This PR adds a category property to the `details` object used to create a local notification.
I also added support for the `alertAction` property, which is used to control the "slide to {alertAction}" text beneath the notification.
Finally, I added the doc for `userInfo` to `presentLocalNotification` (previously was only documented for `scheduleLocalNotification`.
**Test plan (required)**
I implemented the example from the [react-native-ios-notification-actions README](https://github.com/holmesal/react-native-ios-notification-actions), and created a couple of actions and grouped them under a category with identifier `something_happened`.
Prior to the changes in this PR, the shown local notification would not contain any actions.
With the changes in this PR, the shown local notification contains the specified actions.
Like so:
.
The consequence of this is that failing to require('Set') before using it won't error during testing on a modern OS, but will fail on older OS versions. This diff makes the Map and Set polyfills available globally to all RN apps to avoid that problem.
Reviewed By: davidaurelio
Differential Revision: D2833997
fb-gh-sync-id: 713d8b69f6a1bce2472a1b2e6b84f69d75f30289
Summary:
Current version wasn't triggering any sound when a local notification was fired. I added the possibility to provide a custom sound and fallback to the default iOS sound if not provided.
Closes https://github.com/facebook/react-native/pull/4836
Reviewed By: svcscm
Differential Revision: D2807381
Pulled By: bestander
fb-gh-sync-id: c25e8f3c30a0714a5d9558c0c1fe344d0e93321e
Summary:
Including RCTPushNotificationManager is required for local notifications, which don't require a Push Notifications entitlement on your provisioning profile. However, if you don't have the entitlement, the app store warns you when you push an app build that contains `application:didRegisterForRemoteNotificationsWithDeviceToken:`, even if it isn't being called. This renames the methods so they have different names from the ones on UIApplication so the app store doesn't warn about them.
Closes https://github.com/facebook/react-native/pull/4897
Reviewed By: spicyj
Differential Revision: D2780533
Pulled By: nicklockwood
fb-gh-sync-id: 1a688f1ebd3cc9f86ba340ce453fdbfb46949839
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: I was just implementing push notifications for my iOS app and was very confused why the `register` event wasn't working.
[Eventually I ran across this tutorial](https://medium.com/@DannyvanderJagt/how-to-use-push-notifications-in-react-native-41e8b14aadae) that explained that I needed to update my AppDelegate to make that event work.
I've updated the documentation to include that note within the actual file.
Closes https://github.com/facebook/react-native/pull/3390
Reviewed By: @svcscm
Differential Revision: D2537853
Pulled By: @javache
fb-gh-sync-id: 1e8860173c38f6b2d7f9d273019f201e4cc9c0f2
Summary: **Problem**
Using push notifications in IOS 8 will throw this error:
`registerForRemoteNotificationTypes: is not supported in iOS 8.0 and later.`
The problem is that the check is running on compile instead of runtime.
**Solution**
If have changed the compile if statement to a runtime if statement. The fix is tested on: IOS 7.1 and 8.* and everything is working now.
This solution is also discussed in: https://github.com/facebook/react-native/issues/1613 and it was part of https://github.com/facebook/react-native/pull/1979. (is being separated to keep things moving)
Please let me know what you think.Closes https://github.com/facebook/react-native/pull/2332
Reviewed By: @svcscm
Differential Revision: D2490987
Pulled By: @ericvicenti
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
Pieter De Baets
Damien Varron
Wojciech Ogrodowczyk
ianlin
npomfret
Konstantin Raev
Jonathan Stanton
dlowder-salesforce
Connor McEwen
Ian MacLeod
ExplodingCabbage
Chace Liang
Daniel Braun
Kyle Corbitt
Kevin Smith
Joshua Pinter
Nick Lockwood
alvaromb
Robin Breuker
David Aurelio
Jacob Turner
Alonso Holmes
slycoder
pecheriere
Noah Jorgenson
Michelle Todd
Justas Brazauskas
Adam Terlson
Harry Wolff
Danny van der Jagt
Magnus Bergman
Yusef Napora
Jeff Morrison
