Уточнение Sinch относительно relayRemotePushNotificationPayload:

В документе указано, что [client relayLocalNotification:] должен быть защищен проверкой [client isStarted], но не упоминается в [client relayRemotePushNotificationPayload:] (я доставляю полезную нагрузку удаленного push-уведомления через свой собственный сокет, а не push-уведомление Apple).

Мои вопросы:

  • Будет ли [client relayRemotePushNotificationPayload:] вызывать start автоматически, или мне лучше проверить и буферизовать полезные данные, которые будут использоваться в сообщении делегата clientDidStart?
  • В журнале кажется, что полезные данные удаленного push-уведомления запрашиваются и генерируются несколько раз, когда удаленный пользователь не находится в сети. это по дизайну?
  • Безопасно ли вызывать [_client start] несколько раз?
  • Должен ли я вызывать [_client stop], когда мое приложение переходит в фоновый режим? (Я использую свой собственный сокет для доставки полезной нагрузки удаленных push-уведомлений)

ios sinch
person wangii    schedule 04.06.2014    source источник

Ответы (1)


arrow_upward
5
arrow_downward

1) [client relayRemotePushNotificationPayload:] будет внутренне вызывать start, когда ему будет передана полезная нагрузка, требующая запуска клиента (например, вызов).

2) Если у вас есть несколько экземпляров (например, вы вошли в систему на нескольких устройствах) для одного и того же пользователя, это ожидается, поскольку они должны иметь разные данные push.

3) Да, вызов start несколько раз безопасен.

4) Как правило, вы должны вызывать stop только тогда, когда приложение собирается завершить работу, вместо этого вы можете вызвать stopListeningOnActiveConnection, если вы не хотите, чтобы соединение работало в фоновом режиме (и поскольку вы реализовали свой собственный механизм пробуждения).

person frals    schedule 04.06.2014
comment
когда [client relayRemotePushNotificationPayload:] вызовет start, будет вызван метод делегата clientDidStart:, верно? Спасибо! - person wangii; 04.06.2014
comment
@wangii да, метод делегата будет вызван - person cahlbin; 04.06.2014