Return boolean from handlePushNotification indicating if branch link being handled
willbattel opened this issue · 0 comments
Describe the feature
It would be helpful for us if handlePushNotification
returned a boolean: true
if it finds and handles a branch link, and false
if not. This would allow us to deep link based on other data in the push notification payload only when there is no branch link.
For notification payloads that include a branch link, we want to prevent the possibility of double-deep-linking. That is, if the payload includes other deep linking data we would normally use for routing, we want to ignore that data if there is a branch link because the branch link would its own routing data that takes precedence.
func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
let payload = response.notification.request.content.userInfo
// Let branch check for a link in the notification payload first
let branchHandled = Branch.getInstance().handlePushNotification(payload)
if !branchHandled {
// If no branch link, use other data in notification payload for deep-linking
handle(linkData: payload)
}
completionHandler()
}
For now we can just manually check for the "branch"
key in the payload, but this would be a better solution long-term.
I also have a question about the documentation. It says we should call handlePushNotification
in UIApplication.didReceiveRemoteNotifcation()
and UNUserNotificationCenter.didReceive()
, but it seems like the former could cause the app to deep-link while the user is using it when the device receives a push notification. This would be undesirable. We don't want the app to automatically route the user elsewhere if it is already active when the notification is received. Instead, the app should only route the deep link when the user responds to a notification (UNUserNotificationCenter.didReceive()
and UIApplication.didFinishLaunchingWithOptions
). I just wanted clarification on this since it seems like many developers would not want the suggested behavior, or maybe I'm misunderstanding.