Grocer - New Gem for Sending Apple Push Notifications in Ruby
1–10 of 20 posts
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#2Awesome! This is great.
I'm also working on an APNS gem called Lead Zeppelin, which is similar in design, but adds a few things like a pool of connections (read: concurrent on threaded systems like JRuby and Rubinius): https://github.com/geoloqi/lead_zeppelin
There is some high quality code here, this is a great start. I think the error handling needs to be drilled down a bit, and there needs to be more logging. I'm definitely going to borrow some components of this.. the apns test server is really awesome! I'm happy that APNS support is improving in the Ruby community.
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#3Awesome! This is great. I'm also working on an APNS gem called Lead Zeppelin, which is similar in design, but adds a few things like a pool of connections (read: concurrent on threaded systems like JRuby and Rubinius): https://github.com/geoloqi/lead_zeppelin There is some high quality code here, this is a great start. I think the error handling needs to be drilled down a bit, and there needs to be more logging. I'm…
Great suggestions. It would be awesome if you contributed it to grocer as well :P. It's still in active development though so you may find some of these enhancements in grocer at some point in the near future. Thanks man!
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#4Hey, you do know that Apple requires developers to maintain persistent connections to their servers, right?
Checkout https://github.com/jnak/apnmachine Feature list: - persistent connection to APN Servers (as Apple recommends) - real-time notifications (no regular polling a la Resque) - super easy to use in Ruby and any languages (as easy as enqueuing a serialized JSON hash in Redis) - persist and queue messages when server is down - horizontal scalability and out-of-the-box load-balancing - fast daemons
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#5Awesome! This is great. I'm also working on an APNS gem called Lead Zeppelin, which is similar in design, but adds a few things like a pool of connections (read: concurrent on threaded systems like JRuby and Rubinius): https://github.com/geoloqi/lead_zeppelin There is some high quality code here, this is a great start. I think the error handling needs to be drilled down a bit, and there needs to be more logging. I'm…
Great suggestions. It would be awesome if you contributed it to grocer as well :P. It's still in active development though so you may find some of these enhancements in grocer at some point in the near future. Thanks man!
No problem, I would love to contribute! My account is kyledrake on Github.
Right now I'm experimenting with socket keepalive, which I think may be important to keeping socket connections open (per some discussion I found from an Apple dev). If my tests go well I'll send a pull request later tonight!
The one thing I haven't figured out yet is how to stop messages from being dropped after feedback comes in. It has a tendency to silently fail to send messages. My current solution is to check for errors before a write, and do a IO.select on the socket to wait for a read for an arbitrary amount of time. You might want to look at some of the weird stuff I had to do in here.. it's a problem I'd like to figure out how to deal with: https://github.com/geoloqi/lead_zeppelin/blob/master/lib/lea...
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#6Hey, you do know that Apple requires developers to maintain persistent connections to their servers, right? Checkout https://github.com/jnak/apnmachine Feature list: - persistent connection to APN Servers (as Apple recommends) - real-time notifications (no regular polling a la Resque) - super easy to use in Ruby and any languages (as easy as enqueuing a serialized JSON hash in Redis) - persist and queue messages when…
Nice! We keep a single connection open using the standalone gem.
But yeah you're right it would be an issue if you were connecting to Apple's servers in a resque worker for example, since the socket would be opened in a new child for each job. I bet you could get around this though by opening a socket in the parent and using it in each child process. Reconnecting might be a little trickier though.
apnmachine looks pretty sweet. I'll have to check it out if I need something like that in the future.
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#7Earlier quoted context omitted.
Great suggestions. It would be awesome if you contributed it to grocer as well :P. It's still in active development though so you may find some of these enhancements in grocer at some point in the near future. Thanks man!
No problem, I would love to contribute! My account is kyledrake on Github. Right now I'm experimenting with socket keepalive, which I think may be important to keeping socket connections open (per some discussion I found from an Apple dev). If my tests go well I'll send a pull request later tonight! The one thing I haven't figured out yet is how to stop messages from being dropped after feedback comes in. It has a te…
Sweet. Now accepting pull requests :)
Interesting. We haven't hit that issue yet.
Hmmm. We also haven't had any issues with feedback affecting our outgoing messages. Yeah we just check for messages from the feedback socket after sending a notification (as Apple's guide recommends) but we're not doing anything fancy like waiting for a response. Sounds cool though.
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#8Hey, you do know that Apple requires developers to maintain persistent connections to their servers, right? Checkout https://github.com/jnak/apnmachine Feature list: - persistent connection to APN Servers (as Apple recommends) - real-time notifications (no regular polling a la Resque) - super easy to use in Ruby and any languages (as easy as enqueuing a serialized JSON hash in Redis) - persist and queue messages when…
Nice! We keep a single connection open using the standalone gem. But yeah you're right it would be an issue if you were connecting to Apple's servers in a resque worker for example, since the socket would be opened in a new child for each job. I bet you could get around this though by opening a socket in the parent and using it in each child process. Reconnecting might be a little trickier though. apnmachine looks pr…
Don't know the standalone gem, I'll have to check that out.
I'll be glad to get some feedback on apnmachine :)
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#9Earlier quoted context omitted.
No problem, I would love to contribute! My account is kyledrake on Github. Right now I'm experimenting with socket keepalive, which I think may be important to keeping socket connections open (per some discussion I found from an Apple dev). If my tests go well I'll send a pull request later tonight! The one thing I haven't figured out yet is how to stop messages from being dropped after feedback comes in. It has a te…
Sweet. Now accepting pull requests :) Interesting. We haven't hit that issue yet. Hmmm. We also haven't had any issues with feedback affecting our outgoing messages. Yeah we just check for messages from the feedback socket after sending a notification (as Apple's guide recommends) but we're not doing anything fancy like waiting for a response. Sounds cool though.
I want to remove the IO.select because it slows things down unfortunately. I noticed you are using enhanced push, but also opening a feedback socket separately. I was under the impression that you were supposed to read feedback in-line with the enhanced protocol, but I may have gotten this wrong. Are you using the enhanced protocol -and- listening to the feedback socket? This is interesting, and may solve a problem I'm having, so I wanted to get your thoughts.
Re: Grocer - New Gem for Sending Apple Push Notifications in Ruby
#10Earlier quoted context omitted.
No problem, I would love to contribute! My account is kyledrake on Github. Right now I'm experimenting with socket keepalive, which I think may be important to keeping socket connections open (per some discussion I found from an Apple dev). If my tests go well I'll send a pull request later tonight! The one thing I haven't figured out yet is how to stop messages from being dropped after feedback comes in. It has a te…
Sweet. Now accepting pull requests :) Interesting. We haven't hit that issue yet. Hmmm. We also haven't had any issues with feedback affecting our outgoing messages. Yeah we just check for messages from the feedback socket after sending a notification (as Apple's guide recommends) but we're not doing anything fancy like waiting for a response. Sounds cool though.
[deleted]