No Connection? about libpusher

[lukeredpath]

There was definitely an issue with an older build because some idiot (ahem me) left the staging server details in and the real ones commented out. This was fixed two days ago here.

It looks like in your first snippet you are assigning the client directly to your instance variable; the client returned from [PTPusher pusherWithKey] is auto-released - are you forgetting to retain it?

[jwhitehorn]

You are correct, I am assigning the client to an instance variable. I am, however, using ARC, so there shouldn't be a worry in regards to the lack of retain. However, for safe measure, I just now changed it up so that those were @property (strong), and that did not seem to change the outcome.

You don't think that me using ARC has something to do with this, do you? I was under the impression that since you compiled your code as a library, then you could use ARC (or not) independent of if my projected used it...

[lukeredpath]

No, you're quite right, I forgot about ARC so I'm used to seeing potential memory issues where there wouldn't be with ARC.

One thing to test whether or not a connection is getting through to Pusher is to load up the debug console on the Pusher admin interface for your app ID and see if anything appears when you run your app.

Out of interest, could you try implementing – pusher:connectionDidDisconnect: as well?

[jwhitehorn]

I added the additional event handler, and that isn't called either :-S

I checked the Pusher website, and it shows 0 connections. So, I don't think it's even making it that far.

Stepping back and looking at the code base a whole, I realized that I am actually setting up my Pusher connection in a GCD thread. Temporarily removing that dispatch_async block and just running that in the UI thread causes libPusher to fire it's connectionDidConnect event.

To tell you the truth this was entirely unexpected. Is there a reason this would need to be performed in the UI thread?

[lukeredpath]

As things stand, the underlying socket relies in the run loop. This makes behaviour on a background thread unpredictable as it depends on what state the run loop is in on the background thread.

libPusher is designed to run on the main thread as the socket communication is asynchronous and doesn't need threading.

[lukeredpath]

I'll try and update the documentation to make this clear. This might change in the future as CocoaAsyncSocket also has a GCD implementation but I haven't had a chance to see how it compares to the run loop version.

[jwhitehorn]

Thank you very much for your time, and explaining what's going on. Knowing these facts I was able to refactor my code in such a way as to call performSelectorOnMainThread right when I'm ready to connect to Pusher.

This solves my problem of connecting to pusher, while still allowing the heavy lifting that my app requires prior to connecting to occur outside of the UI thread.

Thank you again, I couldn't have unraveled all of that without your assistance!