Closed jeacott1 closed 7 years ago
uhm, seems that because APNS support multiple 'connections' we don't track if it's the last try. Also successful push does not mean delivery, hopefully we'll have something with #52 :)
successful push for gcm means no failure response from gcm. why shouldnt it be the same behaviour for apns? the apns adapter assumes that if its sent something to the apns service its all good, despite any transmissionError.
yeah but APNS behaves differently from GCM, transmission to APNS doesn't mean it's gonna be delivered hence the feedback service.
Not sure how GCM handles it but from what I saw, it seems to be fairly transactional.
In any case, feel free to provide a fix for that issue.
agreed, but both return failures when they can. I'll see what I can do. javascript isn't fun.
The main difference is that we support multiple connections for APNS not for GCM IIRC. So we have to check for APNS and keep track of transient failures.
looks like apn v2 should make this easier, no more transmitted firing before transmittionError, just plain success/fail.
actually, #52 fixes the issue, and is significantly faster than the existing version while its at it, so roll it in asap please :)
Yes, because APNSv2 is transactional and not fire and forget
apns v2 will be parse of parse-server 2.5.1, which is currently being built. Closing.
GCM works fine in this regard, and properly reports success/failures, but apns never updates the tracker on fail. log:
corresponding _PushStatus ("numFailed" : 0)