Re:Grocer - New Gem for Sending Apple Push Notifications in ...
by vanstee on Tuesday June 12, 2012 @07:01PM
(#4103405)
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 ...
by kyledrake on Tuesday June 12, 2012 @07:35PM
(#4103505)
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 ...
by vanstee on Tuesday June 12, 2012 @07:41PM
(#4103525)
Couldn't find that in the guide (reading feedback from the same socket). I might have missed it though.
And yep. We're using the enhanced protocol while opening another connection to the feedback service. I just followed this section of the docs.
http://developer.apple.com/library/mac/#documentation/Networ...
Re:Grocer - New Gem for Sending Apple Push Notifications in ...
by kyledrake on Tuesday June 12, 2012 @08:34PM
(#4103689)
Where do you call the feedback socket after sending a notification in the code? Is this something you do on your application's end? Sorry, last question I promise. Pull requests coming soon!
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...