-
Notifications
You must be signed in to change notification settings - Fork 451
Frequently asked questions
The short (and frustratingly vague) answer is "some time after it is taken from the queue."
Because APNs servers never acknowledge successful notifications, it's hard for us to know much about a notification's state after we've sent it. APNs servers do acknowledge bad notifications, though. The one way we can find out what happened to a notification is by sending a bad notification to the server and waiting for the server to send a rejection. At that point, we know that all preceding notifications were accepted by the server and all subsequent notifications weren't processed.
When a push manager shuts down, it will close its connections by sending known-bad notifications to the server. When a connection closes, we know what happened to all of the notifications sent on that connection. If there are still messages left to send, the push manager will open a new connection, send everything it can, and flush with a known-bad notification. This process will repeat until all of the notifications that needed to be resent have been either accepted or rejected by the gateway.
The more upbeat view of the situation is that if a push manager takes a notification from the queue, it will make every effort to send it as soon as quickly as possible. Push managers won't take new notifications unless they have reason to believe the notification can be sent immediately (i.e. there's at least one live connection and there are no other notifications that need to be re-sent).
Yes. You're free to write your own classes that implement ApnsPushNotification (and also to subclass SimpleApnsPushNotification). When you do so, you can attach as much additional data as you'd like (though only the data in the push notification's payload will be sent to the APNs gateway).