-
Notifications
You must be signed in to change notification settings - Fork 451
Frequently asked questions (v0.4 and older)
Please note that, as of version 0.5, Pushy's design and API have changed significantly. Pushy 0.5 and newer use Apple's new HTTP/2-based protocol, and as a result don't have to deal with some of the ambiguities imposed by prior versions of the protocol. The questions below apply exclusively to Pushy 0.4 and older. All users are strongly encouraged to upgrade to Pushy 0.5.
My PushManager connects to the APNs gateway, but the gateway closes the connection immediately. Why is this happening?
The most likely cause for this problem is that you're using a sandbox certificate in the production APNs environment (or vice versa). The certificate is technically valid from a TLS perspective, so the connection succeeds, but the certificate doesn't have the subject the gateway is expecting, so the gateway closes the connection as soon as it notices the mismatched subject.
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).
I started a push manager, added a notification to the queue, and shut down the push manager. My push notification never got sent; why not?
In all likelihood, the push manager shut down before it ever opened a connection to the APNs server, so it never tried to send your notification. In this case, you'll find your notification still in the push manager's public queue. You'll want to make sure the notification is taken from the queue before you shut down.
If you're just trying to send a small batch of notifications, you might consider using a SynchronousQueue as the public queue for your push manager. If you use a SynchronousQueue, your code will block until the push manager has taken the notification from the queue (so make sure to start the push manager first!). This will guarantee that, by the time you shut down your push manager, the push manager will have tried to send your notification. Note that this approach is not without challenges (like any blocking code, you'll want to consider timeouts and interruption), and it's probably not what you want if you're sending lots of notifications over a longer period of time with a long-lived push manager.
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).