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
Summary:
This diff implements highlighting of tapped text subranges for the iOS `<Text>` component, styled to match how iOS webkit views highlight links (translucent grey overlay with rounded corners).
Highlighting is enabled by default for any `<Text>` component which has an onPress handler. To disable the highlight, add `suppressHighlighting={true}` to the component props.
Summary:
Add local notifications to the push library.
```
var PushNotificationIOS = React.PushNotificationIOS;
PushNotificationIOS.requestPermissions();
var notification = {
"fireDate": Date.now() + 10000,
"alertBody":"Whats up pumpkin"
};
PushNotificationIOS.scheduleLocalNotification(notification);
//lock screen or move away from app
```
Apple has another api for pushing immediately instead of scheduling, like when your background delegate has been called with some new data (bluetooth, location, etc)
```
var PushNotificationIOS = React.PushNotificationIOS;
PushNotificationIOS.requestPermissions();
var notification = {
"alertBody":"Whats up pumpkin"
};
PushNotificationIOS.presentLocalNotification(notification);
//lock screen or move away from app
```
Closed https://github.com/facebook/react-native/pull/843 looks related:
See https://developer.apple.com/library/ios/documentation/iPhone/Reference/UILocalNotification_Class/ for much more available in
Closes https://github.com/facebook/react-native/pull/1616
Github Author: Jacob Rosenthal <jakerosenthal@gmail.com>
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
This is the first of a few diffs that change the way the executors are handled
by the bridge.
For they are just promoted to modules, so they are automatically loaded by the bridge.
Test Plan:
Tested on UIExplorer, Catalyst and MAdMan.
Tested all the 3 executors, everything looks fine.
Summary:
In order to add Push support to the Parse JS SDK in React Native, we need a way to receive the APNS device token from the JS context. This adds another event to PushNotificationIOS, so that code can respond to a successful registration.
Additionally, I've updated the `requestPermissions` call to accept an optional map of parameters. This way, developers can request a subset of user notification types.
Closes https://github.com/facebook/react-native/pull/1304
Github Author: Andrew Imm <andrewi@fb.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.