2016-12-08 2 views
1

Я работаю над проектом, в котором мы используем Firebase Cloud Messaging для push-уведомлений. Следующий JSON в настоящее время производится с помощью бэкэнд API и послал к ТСМ:Уведомление от FCM иногда отображается в лотке уведомлений iOS

{ 
    "priority": "normal", 
    "delay_while_idle": true, 
    "dry_run": false, 
    "time_to_live": 3600, 
    "notification": { 
    "body_loc_key": "MyCustomNotificationId" 
    }, 
    "data": { 
    // contains notification data 
    }, 
    "registration_ids": [ 

    ] 
} 

Это уведомление должно молчать, то есть оно должно быть получено только тогда, когда приложение IOS находится на переднем плане, однако иногда на некоторых устройствах это уведомление также находит свой путь к лотку уведомлений iOS, при этом приложение находится в фоновом режиме, как если бы там были параметры, которые будут отображаться там.

Я обнаружил, что атрибут body_loc_key должен присутствовать на устройствах iOS, иначе уведомление не будет нажимать на устройство, независимо от того, находится ли приложение на переднем плане или на заднем плане.

Проблема возникла на следующих устройствах:

  • Apple, iPhone 5,
  • Apple, iPhone 6,

с возможностью других быть затронуты также.

Есть ли другая конфигурация JSON, отправленная в FCM, которую вы использовали с успехом, когда уведомления отправляются только на устройство, когда приложение находится на переднем плане?

ответ

0

После того, как мы играли с полезной нагрузкой FCM за время сима, мы обнаружили, что проблема была в действительности атрибутом body_loc_key.

Для того чтобы уведомление молчать и по-прежнему направляется в яблочного устройства, полезная нагрузка должна соответствовать следующим критериям:

  • priority должен быть установлен в normal,
  • content_available должен быть установлен в true ,
  • notification атрибут должен содержать данные, но если он содержит атрибут body_loc_key, он должен быть установлен в пустую строку - "".

Рабочие примеры полезной нагрузки:

// Example one 
{ 
    "priority": "normal", 
    "delay_while_idle": true, 
    "dry_run": false, 
    "time_to_live": 3600, 
    "content_available": true, 
    "notification": { 
    "body_loc_key": "" 
    }, 
    "data": { 
    // contains notification data 
    }, 
    "registration_ids": [ 
    ] 
} 

// Example two 
// (note that body_loc_key has been replaced with badge) 
{ 
    "priority": "normal", 
    "delay_while_idle": true, 
    "dry_run": false, 
    "time_to_live": 3600, 
    "content_available": true, 
    "notification": { 
    "badge": 10 
    }, 
    "data": { 
    // contains notification data 
    }, 
    "registration_ids": [ 
    ] 
} 

Изменение body_loc_key в пустую строку в значительной степени исправили проблему.Кроме того, мы также обнаружили следующие о other атрибуты notification атрибута:

  • badge может присутствовать и обрабатывается, уведомление умалчивает,
  • title_loc_key не имеет никакого эффекта, уведомление умалчивает,
  • body_loc_args не действует, уведомление остается беззвучным.

Все три дополнения применяются к сценарию, в котором были соблюдены критерии прецедента (пустые body_loc_key, если/когда они есть, и т. Д.).

+0

Просьба дать обратную связь, если вы решите опросить ответ. Я представил фактическое решение проблемы, с которой я столкнулся, в отличие от других ответов, не знаю, в чем проблема. –

-1

Причина, почему ваше уведомление рассылается как дисплей-сообщение и не как немого-сообщение потому, что вы используете notification полезную нагрузку.
В частности вы используете body_loc_key.

Вы написали, что прочитали, что body_loc_key требуется для отправки сообщений с отключенным сообщением.
Это неправда. Не могли бы вы предоставить ссылку на страницу, где вы ее нашли?

+0

Когда служебная информация «уведомление» была пуста, уведомление не поступало на устройство. Основываясь на наших тестах, он должен содержать что-то. –

Смежные вопросы