Есть ли техническая причина, по которой мы не должны включать текст сообщения в уведомления APN?

#ios #apple-push-notifications

Вопрос:

Мы создаем приложение обмена мгновенными сообщениями для устройств iOS и используем уведомления APN, чтобы информировать пользователя каждый раз, когда в одном из их чатов появляется новое сообщение. Читая документацию, Apple советует: «Поскольку доставка удаленных уведомлений не гарантируется, никогда не включайте в свою полезную нагрузку […] данные, которые могут быть получены другими способами».

Мне это кажется немного непоследовательным. Только потому, что данные могут быть получены другими способами, является ли это причиной не включать их в полезную нагрузку уведомления? Если мы включим тела сообщений чата в нашу полезную нагрузку уведомлений (где размер тела будет не больше, скажем, 1 КБ), мы сможем кэшировать сообщение и отображать его, как только пользователь откроет приложение, вместо того, чтобы приложению приходилось отправлять сообщение на сервер, что приводит к дополнительной задержке.

Конечно, уведомления APS могут приходить не по порядку, и доставка не гарантируется, поэтому мы будем использовать даты сообщений для заказа сообщений и звонить на сервер, чтобы получить любые сообщения, которые не были доставлены через APS. Но для сообщений, которые действительно проходили через точки доступа, я не понимаю, почему бы нам просто не включить в уведомление все тело сообщения.

В документации Apple приведен пример электронного письма, в котором текст письма не будет доставлен в теле APN, а будет загружен приложением отдельно. Однако электронные письма, как правило, намного больше, чем сообщения обмена мгновенными сообщениями, и могут иметь размер в несколько мегабайт. Наши тела обмена мгновенными сообщениями были бы намного меньше, так что это не очень хороший пример.

Я что-то упускаю в том, что есть техническая причина не включать такие небольшие тела сообщений обмена мгновенными сообщениями? Это заставляет меня задуматься, почему размер уведомлений может достигать 4 КБ, если вы не должны связывать такие вещи.

Ответ №1:

Ссылка, которую вы предоставили, взята из Архива документации, при ее открытии я вижу отказ от ответственности

Этот документ может не отражать лучшие практики для текущей разработки. Ссылки на загрузки и другие ресурсы могут быть недействительными. Для получения последней информации см. раздел Структура уведомлений пользователей.»

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

Комментарии:

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

2. Я думаю, что помимо лучших практик, которые охватывают основные сценарии, Apple никогда не упоминает, что можно делать с их API, имеющим бесконечное количество вариантов использования, с которыми могут столкнуться все разработчики. Я привык думать, что когда Apple чему-то не препятствует и когда это не противоречит здравому смыслу, тогда это нормально.

3. На корневой странице документации «Уведомления пользователей» вы можете найти пример кода. Если вы загрузите пример «Реализация Push-уведомлений о предупреждениях», вы можете найти комментарий в AppDelegate.swift, в котором описывается полезная нагрузка уведомления. Эта полезная нагрузка есть alert.body = "Avocado Bacon Burger on sale" , поэтому я думаю, что у Apple нет проблем с наличием такого тела и в вашей полезной нагрузке.