Один push и два заказа: как проверить восстановление

Определите результат для клиента

Возьмите клиента с двумя действующими заказами. По первому меняется готовность, по второму — обещанное время. После перерыва в связи человек должен различить оба текущих состояния. Для приёмки заранее запишите, какие сведения и действия обязательны: номер заказа, обещание, причина изменения, необходимость ответа и доступный способ уточнения.

Счётчик отправок не отвечает на этот вопрос. В FCM полученный идентификатор означает принятие сообщения к доставке, а не получение устройством. Условия ожидания доставки.

Просите исполнителя показать итог на контрольных записях, а не только успешный ответ сервиса отправки. Укажите, где хранится подтверждённое состояние заказа и кто разбирает несовпадение. Получение одного сигнала само по себе ещё не проверяет полноту открытого списка.

Разделите очередь, обработку и экран

FCM может заменить ещё не доставленное collapsible-сообщение более новым. Порядок доставки не гарантирован. В Android общую группу задаёт collapse_key. Это механизм ожидающей передачи. Описание объединения сообщений.

Data-only содержит пользовательские пары данных, которые обрабатывает приложение. Сообщение notification может дополнительно содержать data, но это другой тип. В фоне данные смешанного сообщения обрабатываются после нажатия пользователем; на переднем плане доступны обе части. Типы FCM.

Уже показанная карточка — отдельный объект. Android обновляет уведомление повторным вызовом с тем же идентификатором; после удаления пользователем создаётся новое. Объединение в транспортной очереди не доказывает отзыв старой карточки с экрана. Обновление уведомления.

Проверьте два заказа одним сценарием

Далее — вымышленная модель приёмки, без отправки настоящих push. Клиент имеет R501 и R502. В начале приложение знает R501 версии 1 и R502 версии 4. Центральная запись затем содержит три изменения в указанном порядке.

Задаём одну Android-регистрацию, недоступную всё время M1–M3, и data-only с одним явно заданным ключом orders-changed. Все сообщения ещё полезны. При совпадении ключа и регистрации новое ожидающее сообщение заменяет прежнее: в модели остаётся M3. Доставка M3 не обещана.

Разработчик не должен переносить этот результат на смешанный payload, другие платформы или иную конфигурацию. Указанные ограничения входят в протокол проверки, а не считаются настройками конкретного приложения SABSUS.

Сверьте всю затронутую область

Плохая реализация после M3 обновляет только R501. Тогда первая карточка получает версию 3, а вторая остаётся на версии 4 вместо 5. Проверка одного последнего заказа даёт ложное ощущение успеха.

В предлагаемом тесте orders-changed означает повод запросить текущие доступные клиенту заказы. После сверки нужны R501 версии 3 и R502 версии 5. Та же проверка выполняется при открытии приложения без полученного push. Если запрос не завершился, старые данные нельзя выдавать за подтверждённый свежий результат.

Это требование к результату, а не обязательный способ передачи всего каталога. Команда может предложить полный список или согласованный механизм изменений с подтверждением полноты. При большом списке нужно пройти все относящиеся к проверке страницы. Одно совпавшее число строк недостаточно: потеря R502 может скрыться за чужой либо повторной записью.

Проверяющий фиксирует исходные версии, последовательность изменений, способ открытия и полученные значения. Для отрицательного случая намеренно возвращают только R501 из учебного источника: сценарий должен остаться непринятым. Нельзя закрывать его отметкой «ошибок сервера нет».

Сохраните действие, которое ещё требуется

Текущая карточка и обязательное действие клиента решают разные задачи. Если задержка R502 требует выбрать другое время, такое обращение должно оставаться видимым до предусмотренного завершения. Появление новой готовности R501 не является ответом клиента по R502.

В модели история содержит M1, M2 и M3, а текущих карточек две. Три события, два заказа и число увиденных сообщений — разные счётчики. Решите, какие изменения нужно сохранять в истории, и проверяйте именно этот перечень. Материал не задаёт юридический срок хранения или обязательность конкретного канала уведомления.

Доступ проверяют отдельно: другой клиент не должен получить R501 или R502 из-за общей темы обновления. Используйте учебные учётные записи и разрешённую среду. В протокол не включают настоящие адреса регистрации, пароли, платёжные данные или личную переписку.

Проверьте границы выбранного решения

В FCM Android одновременно сохраняется максимум четыре различных collapse key на регистрацию; при превышении неизвестно, какие останутся. Поэтому не принимайте неограниченный ключ на каждый заказ за решение. Notification-сообщения всегда объединяемы и игнорируют collapse_key.

Для теста с пятью группами нельзя заранее назначить четыре «обязательных выживших». Проверяйте восстановление нужных заказов независимо от этой догадки. Отдельно предъявите уже показанную старую карточку: изменение очереди ещё не подтверждает изменение её текста.

Проверка версий и исправление ранее отправленного обещания подробно разобраны в руководстве по статусным сообщениям. Здесь остаётся другой критерий: ни один из двух затронутых заказов не исчезает из контрольной сверки.