Skip to content

Scheduled notifications by the recipient's time zone do not work #8172

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.

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

Closed
MintSet opened this issue Jun 1, 2021 · 0 comments · Fixed by #8203
Closed

Scheduled notifications by the recipient's time zone do not work #8172

MintSet opened this issue Jun 1, 2021 · 0 comments · Fixed by #8203
Assignees

Comments

@MintSet
Copy link

MintSet commented Jun 1, 2021

[REQUIRED] Step 1: Describe your environment

  • Xcode version: 12.5
  • Firebase SDK version: 7.11.0
  • Installation method: CocoaPods
  • Firebase Component: Messaging

[REQUIRED] Step 2: Describe the problem

While using Firebase Cloud Messaging, it turned out that notifications sent on a schedule according to the recipient's time zone were not displayed on the device. Test notifications that are sent for a specific fcm token are working. The documentation does not describe how you can test notifications on a schedule, so I had to come up with my own way.
We created a unique Analytic User Property for push notifications only to certain devices. We also added userInfo logging to the methods -application:didReceiveRemoteNotification:fetchCompletionHandler:, -userNotificationCenter: didReceiveNotificationResponse:withCompletionHandler: и - userNotificationCenter:willPresentNotification:withCompletionHandler:.

First, not all devices received notifications: 2 out of 10 tested devices, notifications reached. All tested devices have iOS10+.

Secondly, those devices that received the notification were not shown it.

Thirdly, we found confirmation of the guess that the notification sent by the recipient's time zone comes in the form of a silent notification, based on which a local notification with a delay is created.

Due to logging, we got a userInfo that we could debug with. In our case, it looked like this:

{
    "aps": {
        "content-available": 1
    },
    "custom_url": "<url in string representation>",
    "gcm.message_id": "0000000000000000",
    "gcm.n.e": 1,
    "gcm.notification.badge": 1,
    "gcm.notification.body": "<custom message>",
    "gcm.notification.sound": "default",
    "gcm.notification.sound2": "default",
    "gcms": "gcm.gmsproc.cm",
    "google.c.a.c_id": 0000000000000000000,
    "google.c.a.c_l": "<name of notification>",
    "google.c.a.e": 1,
    "google.c.a.tc": 1,
    "google.c.a.ts": 0000000000,
    "google.c.a.udt": 1,
    "google.c.cm.lt_end": "2021-06-02 14:00:00",
    "google.c.cm.lt_start": "2021-05-28 16:55:00",
    "google.c.sender.id": 000000000000
}

When debugging, I found that the local notification is not added to the UNUserNotificationCenter. When calling the method -addNotificationRequest:withCompletionHandler: (FIRMessagingContextManagerService.m:186) in completion an error occurs:
Adding notification request failed with error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 55 named com.apple.usernotifications.usernotificationservice" UserInfo={NSDebugDescription=connection to service on pid 55 named com.apple.usernotifications.usernotificationservice}

It turned out that the problem lies in adding sound to the UNMutableNotificationContent (FIRMessagingContextManagerService.m:165). In userInfo, the value for the key "gcm.notification.sound" is the string "default", and the UNMutableNotificationContent has the sound property of the UNNotificationSound type. I.e., the correct sound setting for UNMutableNotificationContent has to be done.

@charlotteliang charlotteliang self-assigned this Jun 3, 2021
@firebase firebase locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants