3 ms·

There already is apn_on_rails which I've used with success. It would be interesting to learn why this gem was written instead of using that one, it's been arou

• pgebheim 16y ago
  Reasons: - We wanted something simpler: apn_on_rails is more of a "complete" solution than what we needed, including models for keeping track of devices that are registered with the app, etc. We already had infrastructure for handling all that, but just needed a bit of code to connect to Apple and do the notifications and read feedback. - We needed to keep connections open. We send constant streams of hundreds-of-thousands of notifications per day. With this in mind it makes sense to keep persistent connections open to the service and stream data in. - Both apn_on_rails and the original APNs gem have broken support for reading from the feedback service. We had to support this fully.