Если Oracle победит Google, то перед ним встанет «Голубой Гигант» — IBM с его собственной реализацией JVM. Не думаю, что такие жесткие битвы кому-то на руку.
Приведенный в примере клиент уведомлений сходит с ума, если устройству ограничен доступ к серверу уведомлений по какой-либо причине.
Например, если запускаться в корпоративной среде с выходом через WiFi и прокси, то так как прокси сервер на запросы по TCP подключению в ответ шлет хоть что-то, хотя бы 400 Bad Request, то выход из блокирующего read-а происходит и считается, что пришло уведомление. Стоит это учитывать и в боевом приложении проверять, что именно вернул read.
Сейчас тестирую на боевом приложении и никак не мог найти причину, почему некоторые устройства уходят в оффлайн минут на 20, хотя интернет у них есть. Думал, что всему виной какая-то ошибка на сервере. Посмотрю в вашем направлении про таймауты.
Прямо у Google-овцев в группах можно найти ответы вида: «а никаких гарантий о доставке и нет» и «время доставки гарантировать невозможно». В чем-то я их понимаю — у них сейчас зоопарк устройств с непонятно как измененными прошивками.
На самом деле даже в документации Apple никаких гарантий нет, зато есть упоминание, что не доставленное уведомление через некоторый период времени может быть удалено с сервера. Но чудесным образом ни одно уведомление еще не потерялось.
Например, если запускаться в корпоративной среде с выходом через WiFi и прокси, то так как прокси сервер на запросы по TCP подключению в ответ шлет хоть что-то, хотя бы 400 Bad Request, то выход из блокирующего read-а происходит и считается, что пришло уведомление. Стоит это учитывать и в боевом приложении проверять, что именно вернул read.
PS. Я не учел…
Этот метод и его применение можно найти в архиве тестового клиента.
Ссылку продублирую.
На самом деле даже в документации Apple никаких гарантий нет, зато есть упоминание, что не доставленное уведомление через некоторый период времени может быть удалено с сервера. Но чудесным образом ни одно уведомление еще не потерялось.