Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

introduce property on RCTPushNotificationManager to hold local notification that launched the app #42628

Closed
wants to merge 1 commit into from
Closed

introduce property on RCTPushNotificationManager to hold local notification that launched the app #42628

wants to merge 1 commit into from

Conversation

philIip
Copy link
Contributor

@philIip philIip commented Jan 24, 2024

Summary:
Changelog: [Internal]

when you warm start an app from a push notification, the UIApplicationLaunchOptionsLocalNotificationKey in application:didFinishLaunchingWithOptions: will contain the notification metadata that warm started the app. however, UIApplicationLaunchOptionsLocalNotificationKey has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler: which is on UNUserNotificationCenterDelegate. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need UNUserNotificationCenterDelegate to be a top level object - usually the scope of the app delegate.

Differential Revision: D52897071

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 24, 2024
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 24, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold local notifi…
bbe9d46 
…cation that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

when you warm start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that warm started the app. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

@analysis-bot
Copy link

analysis-bot commented Jan 24, 2024 •
edited
Loading

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 17,066,846 +24
android hermes armeabi-v7a n/a --
android hermes x86 n/a --
android hermes x86_64 n/a --
android jsc arm64-v8a 20,450,434 -9
android jsc armeabi-v7a n/a --
android jsc x86 n/a --
android jsc x86_64 n/a --

Base commit: 751eae9
Branch: main

philIip added a commit to philIip/react-native that referenced this pull request Jan 25, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
d424a71 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 25, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
d4261ee 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 25, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
e0c51e4 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 25, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
d609f1e 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 25, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
c833e52 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 26, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
5a3c397 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Reviewed By: ingridwang

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 26, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
db38a0b 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Reviewed By: ingridwang

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

philIip added a commit to philIip/react-native that referenced this pull request Jan 26, 2024
@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
3a02bff 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Reviewed By: ingridwang

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

@philIip @facebook-github-bot
introduce property on RCTPushNotificationManager to hold notification…
6abc144 
… that launched the app (facebook#42628)

Summary:

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Reviewed By: ingridwang

Differential Revision: D52897071
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D52897071

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in c8ab44c.

@facebook-github-bot facebook-github-bot added the Merged This PR has been merged. label Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged This PR has been merged. p: Facebook Partner: Facebook Partner
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@philIip @facebook-github-bot @analysis-bot