2013-06-04 15 views
9

Se io mando una notifica a un dispositivo, e che il dispositivo è offline ottenere qualcosa di simile:Inviare la notifica GCM a un dispositivo collegato

Error: Unavailable

E devo inviare nuovamente.

La mia domanda è:

Sarà il server GCM tenere queste notifiche in una coda e automaticamente inviare nuovamente quando il dispositivo è in linea? O deve essere completamente gestito da me.

Perché se il server GCM sta per inviarli automaticamente (una volta che il dispositivo è online), fino a quando non invia effettivamente le notifiche, il mio server presume che siano già state inviate. Come tenere traccia del momento in cui le notifiche vengono reinviate correttamente?

Potrei contrassegnare sul mio server che le notifiche non vengono inviate guardando lo Unavailable error message ma non riesco a capire come contrassegnarle come inviate una volta che GCM ha inviato correttamente le notifiche.

Thank You

risposta

11

A/c per la documentazione --- Quando un server di messaggi 3rd-party un messaggio a GCM e riceve un ID di messaggio indietro, ciò non significa che il messaggio è stato già consegnato al dispositivo. Piuttosto, significa che è stato accettato per la consegna. Ciò che accade al messaggio dopo che è stato accettato dipende da molti fattori.

Se il dispositivo è collegato ma inattivo, il messaggio verrà comunque consegnato immediatamente a meno che il flag delay_while_idle sia impostato su true. In caso contrario, verrà memorizzato nei server GCM fino a quando il dispositivo non sarà attivo. Ed è qui che il flag collapse_key svolge un ruolo: se c'è già un messaggio con la stessa chiave di compressione (e ID di registrazione) memorizzato e in attesa di consegna, il vecchio messaggio verrà scartato e il nuovo messaggio prenderà il suo posto (cioè, il vecchio messaggio sarà crollato dal nuovo). Tuttavia, se la chiave di compressione non è impostata, sia i nuovi che i vecchi messaggi vengono archiviati per la consegna futura.

Nota: esiste un limite al numero di messaggi che è possibile memorizzare senza compressione. Questo limite è attualmente 100. Se viene raggiunto il limite, tutti i messaggi archiviati vengono scartati.

+0

Come sarà il mio server sa quando la notifica è finalmente inviata (con successo)? – user1537779

+0

Non credo che sia possibile ottenere tali informazioni dai server GCM. Ciò significa che dovrai fare affidamento su un altro metodo di comunicazione tra le app client che ricevono correttamente il tuo messaggio e il tuo server. La risposta che ottieni dai server GCM (come sai) ti consente semplicemente di sapere: successo: numero di messaggi che sono stati elaborati senza errori. o errore: numero di messaggi che non è stato possibile elaborare. –

+0

'Potrei contrassegnare sul mio server che le notifiche non vengono inviate osservando il messaggio di errore non disponibile ma non riesco a capire come contrassegnarle come inviate una volta che GCM ha inviato correttamente le notifiche' Potrei finire per inviare nuovamente le stesse notifiche se Non posso sapere se il server gcm li ha mandati qualche tempo dopo o no. – user1537779

2

Quello che ho fatto è stato quello di separare l'indicazione spinta dal payload. Nel mio messaggio GCM includo solo un URI nel payload e memorizzo il carico utile in una tabella di database accessibile tramite l'URI nel messaggio.

Quando il client riceve un messaggio, potrebbe ad es. simile a questa, con hateoas link stile:

{ 
    _links: { 
    message: { 
     rel: 'message', 
     href: 'https://my-server.com/push/<messageId>' 
    } 
    } 
} 

Il cliente va poi a GET il payload messaggio dal URI, a questo punto il server sa che è stato consegnato e può aggiornare di conseguenza. Anche il recupero del payload lo elimina.

Se la riconsegna GCM non è sufficientemente solida, ciò significa anche che il client può scegliere di recuperare manualmente tutti i messaggi in sospeso, ad es. quando viene ripristinata la connettività di rete dopo essere offline, con un endpoint che restituisce tutti i messaggi per un determinato ANDROID_ID o simile. Se poi più tardi il messaggio GCM è consegnato, il client otterrebbe un 404 per l'URI in quel messaggio e lo tratterà come un messaggio non operativo, ovvero un messaggio già gestito.

Se questo è eccessivo, un approccio leggero per ottenere solo la consapevolezza del server della consegna del messaggio è quello di avere un endpoint che ACK semplicemente la ricezione di un messaggio con un dato ID, come ad esempio

POST https://my-server.com/push/notifyReceived 

{ 
    messageId: <messageId> 
} 
+0

Questo è un approccio interessante, ma non risponde direttamente alla domanda. GCM tenta di riconsegnare? – Flimm

+1

Hai ragione. Forse era più adatto come commento, ma un po 'troppo lungo e speravo che potesse aiutare qualcuno. – JHH

Problemi correlati