Могут ли старые жетоны GCM жить даже после удаления?

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

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

Нет, мы переустанавливаем, получаем токен B, и устройство подписывается на конкретный тип предупреждения 2, мы очень хорошо сообщаем токен B.

Теперь, поскольку мы не отправили сообщение к токену A между временем, когда приложение было удалено и переустановлено, мы все равно можем сообщать обоим токенам, и приложение получает их оба.

Если бы мы попытались использовать токен A, а приложение было удалено, мы могли бы очистить его от ответа Google.

Есть ли способ узнать, что токен A технически более недействителен?

Я предполагаю, что с помощью «токена» вы действительно ссылаетесь на идентификатор регистрации. Старые регистрационные идентификаторы могут оставаться активными некоторое время. Однако Google сообщает вам, что вам необходимо обновить свой регистр для конкретной комбинации устройств и приложений с помощью канонического идентификатора в ответе на отправленное сообщение.

Из официальной документации:

Как удаляется незарегистрированное приложение для клиента

Клиентское приложение может быть автоматически незарегистрировано после его удаления. Однако этот процесс не происходит немедленно. Что происходит в этом случае:

  1. Конечный пользователь удаляет клиентское приложение.
  2. Сервер приложений отправляет сообщение на сервер соединения GCM.
  3. Сервер соединения GCM отправляет сообщение клиенту GCM на устройстве.
  4. Клиент GCM на устройстве получает сообщение и обнаруживает, что клиентское приложение было удалено; Детали обнаружения зависят от платформы, на которой работает клиентское приложение.
  5. Клиент GCM на устройстве сообщает серверу подключения GCM, что клиентское приложение было удалено.
  6. Сервер соединения GCM отмечает маркер регистрации для удаления.
  7. Сервер приложений отправляет сообщение в GCM.
  8. GCM возвращает сообщение об ошибке NotRegistered на сервер приложений.
  9. Сервер приложений должен удалить токен регистрации.

Обратите внимание, что может потребоваться некоторое время, чтобы маркер регистрации был полностью удален из GCM. Таким образом, возможно, что сообщения, отправленные во время шага 7 выше, получают действительный идентификатор сообщения в качестве ответа, даже если сообщение не будет доставлено в клиентское приложение. В конце концов, токен регистрации будет удален, и сервер получит ошибку NotRegistered, без каких-либо дополнительных действий, требуемых с сервера приложений.

Однако, по-видимому, может случиться так, что вы все равно получите уведомление по старому идентификатору регистрации, так как пользователи заявляют в других вопросах:

  • Приложение получает дублирующее уведомление с использованием GCM после переустановки
  • Android GCM и несколько токенов
  • https://stackoverflow.com/questions/27845298/gcm-deleting-app-and-reinstalling-multiple-notifications
  • Отмена регистрации и повторная регистрация сообщений GCM приводит к тому, что два регистратора будут действительны. Это так, как предполагалось?

Для этой проблемы существует функция, называемая «канонические идентификаторы»:

Канонические идентификаторы

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

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

Если вы попытаетесь отправить сообщение с использованием старого регистрационного маркера, GCM обработает запрос как обычно, но он будет включать канонический идентификатор в поле registration_id ответа. Обязательно замените токен регистрации, хранящийся на вашем сервере, с помощью этого канонического идентификатора, поскольку в конечном итоге старый токен регистрации перестанет работать.