# #android #firebase #flutter #firebase-cloud-messaging
Вопрос:
Сообщения данных:
Документы говорят:
Не складывается: каждое сообщение важно для клиентского приложения и должно быть доставлено. За исключением сообщений с уведомлениями, все сообщения по умолчанию не складываются.
это означает, что сообщения данных не складываются и считаются важными. Однако в документах также говорится:
Сообщения только с данными считаются устройствами с низким приоритетом, когда ваше приложение находится в фоновом режиме или завершено, и будут игнорироваться.
Итак, действительно ли они важны или нет, и если да, то почему их игнорируют, например, если приложение находится в фоновом режиме.
Уведомления:
Документы говорят:
За исключением сообщений с уведомлениями, все сообщения по умолчанию не складываются.
Я отправляю два сообщения с уведомлениями через составитель уведомлений Firebase и, будучи разборным, старое сообщение должно свернуться (или быть заменено последним), но я вижу, что оба уведомления отображаются как на Android, так и на iOS.
Итак, почему сообщения с уведомлениями считаются «складными»?
Ответ №1:
Очень интересный вопрос!
Похоже, что документы в некоторых местах сбивают с толку и несколько противоречивы.
Я немного покопался, и следующие основные моменты должны развеять некоторые ваши сомнения:
Что мы подразумеваем под складными сообщениями?
Официальное определение из документов:
Складное сообщение-это сообщение, которое может быть заменено новым сообщением, если оно еще не доставлено на устройство.
Давайте расширим приведенное выше определение некоторыми деталями:
Концепция складных сообщений применима только в том случае, если ваши сообщения поставлены в очередь и еще не доставлены получателю. (Причина для сообщений, находящихся в очереди может быть потому, что приемник может не доступ к интернету, и мобильный выключен, и т. д.) Это означает, что в случае сообщений, находящихся в очереди, если сообщения будут свернуты, вы можете получать только последние сообщения на приемник конце, когда они вернулись онлайн.
Давайте возьмем пример: подключение получателя к Интернету отключено, и мы отправляем три сообщения, A, B и C. Теперь, когда получатель включает свой Интернет, он получит только одно сообщение, C, если сообщения складываются.
Однако важно отметить, что если получатель уже получил сообщение, скажем, сообщение A, то при отправке B оно не заменит сообщение A, которое уже доставлено получателю.
Уведомления всегда складываются?
Не совсем так.
Когда мы читаем эту строку из документации, мы считаем, что сообщения об уведомлениях всегда складываются.
За исключением сообщений с уведомлениями, все сообщения по умолчанию не складываются.
Но когда я попытался отправить несколько сообщений с уведомлениями через Notification Composer с консоли Firebase (отключил Интернет на устройстве получателя перед отправкой), я обнаружил, что, возвращаясь в Сеть, я получаю все отправленные сообщения. Что приводит нас к убеждению, что уведомления не складываются!
Но это только половина истории!
Когда вы отправляете уведомление каким-либо другим способом, например с помощью FCM Post API, вы получаете только последнее сообщение из очереди. Это означает, что уведомления можно складывать!
Вывод: Уведомления не складываются при отправке через Композитор уведомлений, в остальных случаях они складываются. (В документах это нигде четко не указано)
Сообщения данных не складываются, а это значит, что они важны, верно?
Очевидный ответ, кажется, да! но здесь это неправильный ответ.
Важные сообщения следует отправлять в виде неразборчивых сообщений. Но неразборчивость не равнозначна важным сообщениям!
Причина?
У этого объяснения есть 2 стороны,
- Разделение разборных/неразборных сообщений определяется только для того, чтобы решить, важно ли для пользователя только последнее сообщение или все сообщения, отправленные до сих пор, важны для пользователя.
- Это не означает, что не складывающиеся сообщения будут доставляться с высоким приоритетом как важные сообщения. Вам все равно нужно учитывать приоритеты сообщений, которые зависят от правил конкретной платформы.
Таким образом, складывающийся/не складывающийся концепт приходит на ум, если сообщения могут быть доставлены получателю. Могут ли сообщения быть доставлены вовремя или нет-это совершенно другая область приоритетов сообщений, ограничений операционной системы и т. Д.
Комментарии:
1. Замечательное объяснение. Я думаю, что команде Firebase нужно нанять кого-то вроде вас для их документации. Но скажите мне, как вы узнали об этих концепциях, поскольку документы всегда сбивали/сбивают с толку.
2. Я также хотел бы добавить, что, когда я отправлял уведомления одно за другим через составитель уведомлений, пока устройство было в автономном режиме, я видел последнее уведомление только тогда, когда устройство подключилось к сети (протестировал его в обоих направлениях, используя «Отправить тестовое сообщение» и «Отправить обычное сообщение».
3. @iDecode, я рад, что ответ вам помог. Как я уже сказал, я сам немного покопался, читая разные ответы и документы, и пришел к пониманию этого. В случае отправки уведомлений через composer немного странно, что мы иногда наблюдаем разное поведение. Сегодня я попробовал пару раз сам, и иногда я вижу оба поведения (складное и не складное). У меня есть экранная запись сообщений об уведомлениях, которые не складываются при отправке из композитора уведомлений: drive.google.com/file/d/1LWxYnLKK1sKCY-KOzNQHmoNlzXcVP9E9/…