Percebi que no iOS 11 beta 2, as notificações silenciosas não são entregues application:didReceiveRemoteNotification:fetchCompletionHandler
independentemente do estado do aplicativo (plano de fundo / primeiro plano).
Eu implementei o UIApplicationDelegete
método application:didReceiveRemoteNotification:fetchCompletionHandler
e envio o seguinte envio silencioso
{
"aps": {
"content-available": 1
},
"mydata": {
"foo": "bar"
}
}
mas o método delegado não é chamado no iOS 11.
Funciona bem em outras versões do iOS e a seção de documentação Configurando uma notificação silenciosa não menciona que qualquer outra coisa deve ser feita.
Isso é um bug no iOS 11 ou perdi algo novo no iOS 11?
Observe que não estou falando ou usando a UserNotification
estrutura que não deve ser necessária para o envio de notificações silenciosas.
Aqui está um projeto de exemplo que ilustra o problema (você precisará definir seu próprio ID de pacote configurável)
Quando você almoça o projeto de amostra e envia uma carga útil acima para o aplicativo, pode usar o console do macOS para verificar se o push é entregue corretamente ao dispositivo, mas não ao aplicativo.
ATUALIZAÇÃO 10.08
Parece que o comportamento é aleatório. Às vezes, após reiniciar o dispositivo, a carga útil é entregue corretamente, mas para de funcionar após algum tempo.
Como você pode ver na captura de tela a seguir, o envio marcado como 1 é entregue apenas ao dispositivo e o envio 2 (após a reinicialização do dispositivo) também é entregue ao aplicativo.
ATUALIZAÇÃO 14.08 - iOS 11 Beta 6
Ainda é o mesmo comportamento. Outra coisa que deve funcionar, mas não funciona, é o seguinte. Quando o esquema do aplicativo é definido como "Aguardar o lançamento do executável", um push silencioso deve ativar o aplicativo e iniciá-lo em segundo plano.
ATUALIZAÇÃO 21.08 - iOS 11 Beta 7
Ainda tem o mesmo comportamento e não as atualizações da Apple no relatório de bug.
ATUALIZAÇÃO 29.08 - iOS 11 Beta 8
Ainda é o mesmo problema. As etapas para reproduzir agora são as seguintes:
- No esquema do projeto Xcode, selecione "Aguardar o lançamento do executável"
- Adicione um ponto de interrupção no
didReceiveRemoteNotification: fetchCompletionHandler
- Inicie o aplicativo no dispositivo
- Envie o push silencioso acima
Esperado : o aplicativo é trazido do estado suspenso para o segundo plano e didReceiveRemoteNotification: fetchCompletionHandler
é chamado
Real : nada acontece
ATUALIZAÇÃO 06.09 - iOS 11 Beta 10
Eu ainda estou tendo o mesmo comportamento de buggy. O ticket da Apple foi atualizado com a seguinte resposta:
Relações com desenvolvedores da Apple 6 de setembro de 2017 às 22:42 A Engineering forneceu os seguintes comentários sobre esse problema:
Conseguimos executar o aplicativo de amostra e testar o comportamento. Não vimos nenhum problema quando testamos isso como descrito.
Não é garantido que os pushs cheguem ao aplicativo quando ele estiver em execução em segundo plano, e os logs aqui indicam que não acreditamos que o aplicativo esteja sendo usado o suficiente para iniciá-lo.
Nós nos vemos entregando empurrões de tempos em tempos, quando as condições são boas.
Acreditamos que isso está se comportando corretamente.
Atualização 11.09
Meu relatório de bug da Apple foi fechado e marcado como duplicado, o 33278611
qual permanece aberto
ATUALIZAÇÃO 13.09 - iOS 11 GM
Graças aos comentários de kam800 (veja abaixo), fiz mais testes e fiz essas observações:
Parece haver um novo daemon no iOS 11 dasd DuetActivitySchedulerDaemon
que descarta completamente o envio de dados ou atrasa a entrega de envio de dados:
Entrega adiada
Logs do console
default 13:11:47.177547 +0200 dasd DuetActivitySchedulerDaemon CANCELED: com.apple.pushLaunch.net.tequilaapps.daylight:C03A65 <private>! lifecycle com.apple.duetactivityscheduler
default 13:11:47.178186 +0200 dasd DuetActivitySchedulerDaemon Removing a launch request for application <private> by activity <private> default com.apple.duetactivityscheduler
default 12:49:04.426256 +0200 dasd DuetActivitySchedulerDaemon Advancing start date for <private> by 6.5 minutes to Wed Sep 13 12:55:31 2017 default com.apple.duetactivityscheduler
default 13:21:40.593012 +0200 dasd DuetActivitySchedulerDaemon Activity <private>: Optimal Score 0.6144 at <private> (Valid Until: <private>) scoring com.apple.duetactivityscheduler
default 13:21:40.594528 +0200 dasd DuetActivitySchedulerDaemon Setting timer (isWaking=1, activityRequiresWaking=0) between <private> and <private> for <private> default com.apple.duetactivityscheduler
Problemas de entrega adiada
- Quando a entrega de envio de dados é adiada e o aplicativo é iniciado, o envio de dados é entregue somente quando a data de entrega é alcançada, o que pode levar vários minutos no futuro. Isso anula completamente o objetivo de usar os push de dados para manter o conteúdo do novo aplicativo pronto para o próximo lançamento. Cito aqui mais uma vez a documentação da Apple:
"As notificações silenciosas melhoram a experiência do usuário, ajudando você a manter seu aplicativo atualizado, mesmo quando não está em execução".
- Quando dois pushs de dados são enviados para um aplicativo suspenso, eles são adiados pelo iOS 11 em vez de ativar o aplicativo diretamente. Quando o tempo de entrega é atingido, apenas o último envio de dados é entregue! Os pushes anteriores são perdidos e não são entregues pelo método delegado, resultando em uma perda de dados.
Entrega cancelada
Logs do console
default 13:35:05.347078 +0200 dasd DuetActivitySchedulerDaemon com.apple.pushLaunch.net.tequilaapps.daylight:C03A65:[
{name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Must Not Proceed, Score: 0.00}}
], FinalDecision: Must Not Proceed} scoring com.apple.duetactivityscheduler
Problemas de entrega cancelados
Bem, nesse caso, o envio de dados é completamente perdido e nunca é entregue no iOS 11 enquanto foi entregue corretamente no iOS 10.
ATUALIZAÇÃO 19.09 - iOS 11 GM
Também notei que, quando o aplicativo está em primeiro plano e a notificação não é entregue ao aplicativo, vejo os seguintes logs no console:
default 08:28:49.354824 +0200 apsd apsd <private>: Received message for enabled topic '<private>' onInterface: NonCellular with payload '<private>' with priority 10 for device token: NO courier-oversized com.apple.apsd
fault 08:33:18.128209 +0200 dasd Foundation <NSXPCConnection: 0x151eee460> connection from pid 55: Exception caught during decoding of received message, dropping incoming message.
Exception: Exception while decoding argument 0 (#2 of invocation):
Exception: value for key 'NS.objects' was of unexpected class 'NSNull'. Allowed classes are '{(
NSArray,
NSData,
NSString,
NSNumber,
NSDictionary,
NSUUID,
_DASActivity,
NSSet,
_DASFileProtection,
NSDate,
NWParameters,
NWEndpoint
)}'. general com.apple.foundation.xpc
"content-available": 1
e o aplicativo estiver em primeiro plano, o retorno de chamada não será acionado.