[ ] Separate loading certificates from configuring the Client or Feedback service, and add support for *.p12 DER certificates as exported from the Apple keychain. #37
[ ] Separate the serialization and binary encoding of payloads from actual sending.
[ ] Provide (optional) validation that should reduce the chance of error responses from Apple.
[ ] Mock tests for when Apple does have an error response, #40.
[ ] Change ErrProcessing, etc to errors instead of strings. Error Response shouldn't need Command (8) or Status.
[x] Move away from using pointers for omitempty when serializing JSON #38
[ ] Handle retry logic differently for cases like revoked or invalid certificates (if those can be checked before connecting, that would be great too).
[ ] Allow closing the client #25, for example if the certificate expired and a new connection is needed (though in that case it may close due to an error).
[ ] Reevaluate how notifications are stored and resent. Currently there is a buffer of 50 messages, which may not be enough. Rather than a maximum, another option would be to assume success after a given time period (or some combination with a much higher maximum). Also, messages aren't requeued until the next Send (on develop).
There is also a cleanup thread running that constantly checks the oldest notification in the ‘Sent’ queue to see if it’s older than a few seconds and if so, it is assumed to have been successfully sent and is removed from the ‘Sent’ queue. - The Problem With Apples Push Notification Service
It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again. - Push Notification Throughput and Error Checking
Maybe storing/resending notifications needs to be extracted and optional so that in-memory isn't the only option.
[ ] Remove determineIdentifier and require ID to be set explicitly by the caller #19. Or provide an identifier generator that must be called explicitly rather than passing no ID.
[ ] Ensure caller is aware of Error responses even if it can't be mapped to a recently sent Notification (SessionError).
There are a number of things I would like to see:
(though in that case it may close due to an error).[ ] Reevaluate how notifications are stored and resent. Currently there is a buffer of 50 messages, which may not be enough. Rather than a maximum, another option would be to assume success after a given time period (or some combination with a much higher maximum). Also, messages aren't requeued until the next Send (on develop).
Maybe storing/resending notifications needs to be extracted and optional so that in-memory isn't the only option.